On-Premises Detection & Monitoring

Hands-on project with Active Directory, Linux, and Splunk :-)

Introduction

Aloha! In this project, I’ll walk you through how I established an on-premises domain environment equipped with Active Directory, simulated a brute-force attack with Kali Linux, and utilized Splunk to detect and dissect the attack’s telemetry.

• Step 1: Virtual machine installation and setup (VirtualBox, Windows 10, Kali Linux, Windows Server 22, Ubuntu Server for Splunk)
• Step 2: Sysmon and Splunk Universal Forwarder configuration on Windows target machine and Windows server
• Step 3: Establish Active Directory on Windows server, promote domain controller, and create new users using PowerShell
• Step 4: Modify Windows target machine to join newly created domain
• Step 5: Brute force attack with Kali Linux and data review in Splunk

Figure 1. Project Diagram

Step 1: VM Installation and Setup

There will be a total of four virtual machines in this lab and they will be hosted in Oracle’s VirtualBox. In order for the virtual machines to be on the same network and still have internet access, I set the network settings for each VM to NAT network with an IP address of 192.168.10.0/24.

Figure 2. NAT Network

VM #1 (Target Machine)

I downloaded the Windows 10 ISO image on my home pc, created the first virtual machine on VirtualBox, and went through the Windows installation process on the target machine.

Figure 3. Virtualization & Windows 10 installation

VM #2 (Windows Server)

Similar to the target machine, I downloaded the Windows Server 2022 ISO image on my home pc, created a virtual machine, and went through the installation process.

Figure 4. Windows Server 2022 installation

VM #3 (Attacker Machine)

Virtual machine #3 will have Kali Linux and will be used as the attacker machine.

Figure 5. Kali Linux

VM #4 (Splunk Server)

For the last virtual machine, I used an Ubuntu server to host Splunk. Compared to the other VMs, the hardware on this particular system was more robust to import data and run searches. The base memory and number of processors are doubled to accommodate Splunk’s operations. Once the Ubuntu server finished installing, the following command was ran to make sure everything was up to date:

sudo apt-get update && sudo apt-get upgrade -y

Figure 6. Ubuntu Server Installation

Next, I set a static IP address for the server to match the project diagram in Figure 1 (192.168.10.10/24). In order to do so, I ran the following commands:

sudo nano /etc/netplan/50-cloud-init.yaml

sudo netplan apply

Figure 7. Static IP

Then, I downloaded Splunk Enterprise Security on my home pc. When the download was complete, I went back to VM #4 to install guest add-ons for VirtualBox with the following commands:

sudo apt-get install virtualbox-guest-additions-iso

sudo apt-get install virtualbox-guest-utils

In order to add Splunk to the Ubuntu server, I created a shared folder between the virtual machine and VirtualBox. I took the following path from the taskbar: Devices -> Shared Folders -> Shared Folder Settings -> add share.

Figure 8. Shared Folder

Subsequently, I added my user, ad-project, to the vboxsf group to access shared folders. Then, I created a new directory called “share” to mount the shared folder onto the directory. The “mount” command instructs the operating system to make a file system available for use at a specified location. Afterwards, I moved to the “share” directory and started the download for the Splunk Installer.

sudo adduser ad-project vboxsf

mkdir share

sudo mount -t vboxsf -o uid=1000,gid=1000 AD-project share/

sudo dpkg -i splunk-9.3.0–51ccf43db5bd-linux-2.6-amd64.deb

Figure 9. Splunk Installer Download

Splunk is located at /opt/splunk and I noticed that all the users and groups belong to splunk (which is a good thing because it limits the permissions to that user). I needed to change to the user, “splunk”, to run the installer.

sudo -u splunk bash

./splunk start

Figure 10. Splunk Download

To make sure Splunk starts up with the user “splunk” every time the virtual machine reboots, I entered the following command:

sudo ./splunk enable boot-start -user splunk

Step 2: Sysmon and Splunk Universal Forwarder Configuration on Windows Target Machine and Windows Server

In order to collect data and send it over to the Splunk Server, I installed Splunk Universal Forwarder and Sysmon on the target machine and Windows server.

Splunk Universal Forwarder

First, I set a static IP address for the target machine to match the project diagram in Figure 1 (192.168.10.100). The following path was taken to do so: Network & Internet settings on the taskbar -> change adapter options -> adapter properties -> TCP/IPv4 properties.

Figure 11. Static IP for target-pc

Next, I started the Splunk Universal Forwarder set up. The splunk server will be the receiving indexer so I set its IP (192.168.10.10) to match. When receiving events, Splunk’s default port is 9997.

Figure 12. Splunk Universal Forwarder Setup

After installation, I configured the “inputs.conf” file to instruct the Splunk forwarder on which events I wanted to send over to the Splunk server. I knew that the original file (C:\ProgramFiles\SplunkUniversalForwarder\etc\system\default) should not be edited because it’s used as a failsafe, so I made a new “inputs.conf” file in the local directory (C:\Program Files\SplunkUniversalForwarder\etc\system\local).

Figure 13. inputs.conf

The contents of the inputs.conf file instruct the Splunk Forwarder to push events related to application, security, system and Sysmon to the Splunk server. After saving the file in the local directory, I restarted the Splunk Forwarder service in order for the updates to take effect.

[WinEventLog://Application]
index = endpoint
disabled = false

[WinEventLog://Security]
index = endpoint
disabled = false

[WinEventLog://System]
index = endpoint
disabled = false

[WinEventLog://Microsoft-Windows-Sysmon/Operational]
index = endpoint
disabled = false
renderXml = true
source = XmlWinEventLog:Microsoft-Windows-Sysmon/Operational

The Splunk server can be reached at 192.168.10.10:8000 (Splunk listens on port 8000). I created a new index called “endpoint” on the Splunk web portal to match the inputs.conf file. Those events will now be sent to that index. To make sure that the Splunk server receives the data, I configured the settings so that it listens on port 9997.

Figure 14. Splunk Index and Receiving

After properly configuring Splunk Universal Forwarder on both the target machine and Windows server, I now have 2 hosts and 4 source types on my dashboard.

Figure 15. Splunk Enterprise Dashboard

Sysmon

For the Sysmon configuration, I used Olaf Hartong’s sysmon-modular. I downloaded the sysmonconfig.xml file and proceeded with the installation process on Windows PowerShell.

Figure 16. Sysmon Installation

Step 3: Establish Active Directory on Windows Server and Promote to a Domain Controller

Active Directory (AD) is a directory service developed by Microsoft that allows administrators to manage permissions and access network resources. In order to run AD, a Windows Server must install the “Active Directory Domain Services” role and be promoted to a domain controller. The latter will give users the ability to perform authentication using Kerberos.

Active Directory

First, I opened up the Server Manager dashboard and took the following path to install Active Directory Domain Services (AD DS): Manage -> add roles and features -> role-based or feature-based installation -> Active Directory Domain Services.

Figure 17. Active Directory Domain Services

Domain Controller

Next, I promoted the server to a domain controller and opted to add a new forest for the deployment operation because I am creating a new domain. Figure 18 displays the paths used to store our database files (NTDS.dit).

This particular file acts as the primary database for Microsoft’s AD DS and organizes all the information related to objects in the domain, including users, groups, computers, and more. Potential threat actors target domain controllers because they have access to everything along with the NTDS.dit file which has everything related to AD, including password hashes.

Figure 18. Domain Controller and NTDS.DIT

Creating New Users

There are several ways to create new users in Active Directory. The two methods I used were Active Directory Users and Computers (ADUC) and PowerShell. Figure 19 displays how I created a new organizational unit and and added a new user within the organizational unit.

Figure 19. New Organizational Unit and User

The second method I used is more ideal for bulk account creation. The .ps1 script shown below is what I ran to create hundreds of new users within a new organizational unit. The first set of lines indicates the file that contains the names and establishes the password for all the user accounts to use. The next set of lines takes the plaintext password and creates a password object for PowerShell to use as a secure password. The last set is a for-each loop that creates new users in Active Directory.

1. $PASSWORD_FOR_USERS = "Password$1"
2. $USER_FIRST_LAST_LIST = Get-Content .\names.txt
3. 
4. $password = ConvertTo-SecureString $PASSWORD_FOR_USERS -AsPlainText -Force
5. New-ADOrganizationalUnit -Name USERS -ProtectedFromAccidentalDeletion $false
6.
7. foreach ($n in $USER_FIRST_LAST_LIST) {
8.   $first = $n.Split(" ")[0].ToLower()
9.   $last = $n.Split(" ")[1].ToLower()
10.  $username = "$($first.Substring(0,1))$($last)".ToLower()
11.  Write-Host "Creating user: $($username)" -BackgroundColor Black -ForegroundColor White
12.    
13.  New-AdUser -AccountPassword $password `
14.            -GivenName $first `
15.            -Surname $last `
16.            -DisplayName $username `
17.            -Name $username `
18.            -EmployeeID $username `
19.            -PasswordNeverExpires $true `
20.            -Path "ou=USERS,$(([ADSI]`"").distinguishedName)" `
21.            -Enabled $true
22. }

Step 4: Modify Windows Target Machine to Join Newly Created Domain

Before changing the domain of my target machine, I modified the preferred DNS server to point towards the newly created domain controller, which is being hosted at 192.168.10.7. After confirming the change, the target machine was able to resolve the newly established domain, “ad-project.local”. To verify the addition of the target machine to the domain controller, I navigated to the ADUC and confirmed that the target-pc was added under the “Computers” folder.

Figure 20. Connecting target machine to Domain Controller

Step 5: Brute Force Attack With Kali Linux and Data Review in Splunk

Before starting the attack, I enabled Remote Desktop Protocol (RDP) on the target machine which allows remote access to the computer from another device via a network connection.

Figure 21. RDP Configuration on target-pc

Brute-Force Attack

According to Lockheed Martin’s Cyber Kill Chain, the first step of a cyberattack is reconnaissance. A successful brute-force attack often uses some form of dictionary with commonly used passwords. For this attack, I utilized a popular word list within Kali Linux’s standard installation, rockyou.txt. This specific list has over over 14 million unique passwords but for this scenario, I knew the password that is being used on the user accounts. I copied the first 20 passwords from the wordlist along with our super secure password on the bottom.

Figure 22. Passwords List

Crowbar is a brute force tool that supports OpenVPN, RDP, SSH Private Keys, and VNC Keys. After a successful attack, the tool will disclose the IP address, port number, and username/password of the target machine. Since the IP address of the target-pc is known and I only wanted to attack that specific machine, a CIDR notation of /32 was used. I ran the following command to simulate a brute-force attack on my target machine in which the user “tsmith” is logged into:

crowbar -b rdp -u tsmith -C passwords.txt -s 192.168.10.100/32

• -b: defines the service to target (rdp)
• -u: defines the specific account to attack (tsmith)
• -C: defines the password list to pull from (passwords.txt)
• -s: defines the target machine’s source IP (192.168.10.100/32)

Figure 23. Successful Brute-Force Attack

Splunk Detection and Dissection

The attack was a success! Next, I confirmed the attack on Splunk. The event code states that there were twenty events with the log ID of “4625” and one event with the log ID of “4624”. The former event is attributed to a failed log-on attempt and the latter refers to a successful log-on attempt.

Looking deeper, I noticed that the “4625" events were happening at the same time which is a clear indication of a brute-force attack. Furthermore, I confirmed that the attack came from my virtual machine with Kali Linux with the IP address of 192.168.10.250.

Figure 24. EventCode 4625

Overall, this attack targeted Active Directory’s authentication mechanisms and provided valuable insights into the vulnerabilities associated with weak or compromised credentials. Splunk showcased the importance of real-time security monitoring and incident response in defending against such attacks.

Conclusion

In this project, I successfully demonstrated the process of setting up a secure on-premises domain environment, integrating Active Directory, simulating a brute-force attack using Kali Linux, and leveraging Splunk to effectively monitor, detect, and analyze the attack’s telemetry.

This hands-on experience deepened my understanding of Windows environments, network security, attack methods, and the critical role of SIEM tools like Splunk. Ultimately, this project highlights the need for proactive security measures and robust monitoring to maintain the integrity of organizational systems.

Thanks for reading :-)