The goal of this project was to create a basic Active Directory (AD) environment, simulate attacks from Kali Linux, and configure Splunk to collect and analyze telemetry from target machines.
- Windows 10 Client: Splunk Universal Forwarder + Sysmon
- Windows Server: Active Directory Domain Services (ADDS) + Splunk Forwarder + Sysmon
- Ubuntu Server: Splunk Enterprise (SIEM)
- Kali Linux: Attack platform
- Setting up Active Directory Domain Services (ADDS)
- Installing and configuring Splunk on Ubuntu Server
- Forwarding logs from endpoints to a SIEM
- Configuring Sysmon for enhanced telemetry
- Analyzing and interpreting network logs
- Recognizing common attacker techniques
- Conducting brute force attacks for testing SIEM detection
- VirtualBox – VM creation and NAT network setup
- Active Directory Domain Services (ADDS) – Domain and user account creation
- Splunk Enterprise – Log ingestion and analysis
- Sysmon – Windows system monitoring
- Crowbar – Brute force attack tool
- Atomic Red Team (ART) – MITRE ATT&CK simulation framework
- Install Windows Server 2022 and configure it as a Domain Controller.
- Join a Windows 10 client to the Active Directory domain.
- Create users, groups, and organizational units within Active Directory.
- Install Splunk Universal Forwarders on both VMs.
- Forward logs (Security, System, Application) to Splunk.
- Build dashboards in Splunk to visualize AD activity.
- Simulate basic attack scenarios (e.g., brute force, privilege escalation).
- Capture and analyze events in Splunk.
- Configure alerts in Splunk based on suspicious activity.
- Document manual review and response actions.
Figure 1 – Lab Network Topology: Four VirtualBox VMs — Splunk Server, Active Directory, Windows 10 Client, and Kali Linux — connected via NAT for attack simulation and log analysis.
Figure 2 - Splunk Server Network Configuration: Static IP set on Splunk server as per network diagram. Default gatway configured for NAT network. Google DNS used as no DNS server setup for this lab.
Figure 3 – Splunk Server IP Verification: Output from ip -a confirming the Splunk server is using the static IP address 192.168.10.10/24 as configured.
Figure 4 – Splunk Web Interface Access: Successful connection to the Splunk Enterprise GUI from the Windows 10 client machine, confirming network and service availability.
Figure 5 – Active Directory Server Configuration: Properties of ADDC01 showing it is joined to the ADProject.local domain with the correct static IP address 192.168.10.7.
Figure 6 - AD Group 1: IT OU created and user added into AD.
Figure 7 - AD Group 2: HR OU created and user added into AD.
Figure 8 - input.conf: New variant of inputs.conf created for Splunk index (Client Machine). The Splunk Universal Forwader will push the events listed in this file over to the Splunk server. This was also setup on the DC as you will see with Figure 13 where two hosts appear in the Splunk logs.
Figure 9 - input.conf location change: Defualt location for inputs.conf is C:\Program Files\SplunkUniversalForwarder\etc\system\default which needs to stay as is. A new inputs.conf file was created in C:\Program Files\SplunkUniversalForwarder\etc\local which Splunk will look to. Note that anytime the inputs.conf file is changed the Universal Forward service needs to be restarted.
Figure 10 - Splunk Forwarder: Within the SplunkForwarder service the Log On tab needs to be changed to use Local System Account otherwise it will not have all the required permissions.
Figure 11 - endpoint index created: In Figure 8 the inputs.conf file has the index listed as endpoint. This has to be created within Splunk otherwise the logs will not show.
Figure 12 - Setting up receiving port in Splunk: By default the port for receiving logs is 9997 and this is what is used in this lab.
Figure 13 - Confirming hosts visile in Splunk: Both the DC and the client are forwarding logs into Splunk.
Figure 14 - Enabling RDP on client machine: By enabling RDP this will help with the next steps where the brute force attack comes into play.
Figure 15 - Crowbar: Beginning to use Crowbar and generating passwords file for brute force attack
Figure 16 - Password file: This is the example password file that will be used for the
Figure 17 - JNeutron logs: Searching specifically for JNeutron user logs
Figure 18 - Failed login attemps: Event ID referencing failed login attempts
Figure 19 - Splunk logs for failed login attempts: Telemetry for failed login attempts
Figure 20 - Brute Force Splunk logs: Kali machine used to brute force the password with Crowbar. Spunk logs verify the attempts showing 'Unknown username or bad password' and logs show the IP of the Kali machine which is where these attempts are originating from.
Figure 21 - Installing Atomic Red Team: Installed Atomic Red Team via PowerShell using the official script from Red Canary. Included NuGet provider setup and confirms successful installation of Invoke-AtomicTest for executing atomic tests.
Figure 22 - : T1136.001: Demonstrates multiple methods of local account creation using Command Prompt, PowerShell, and .NET, aligned with MITRE ATT&CK T1136.001. Includes both standard and administrator account creation, highlighting detection challenges across techniques.
Figure 23 - Local account detection: The Splunk logs now show creation of the new account. This would help in real life scenarios by alerting to a potential breach in a network.
- Successfully built a working AD environment with Splunk monitoring
- Simulated real-world brute force and persistence attacks
- Verified detection of attacker activity via SIEM
- Gained hands-on experience with both defensive and offensive security tools