Windows Active Directory Threat Detection
(In Progress)

September 2026

An image of the Wazuh SIEM Server, Windows Active Directory Server, and client running the Wazuh dashboard — The Wazuh SIEM Server, Windows Active Directory Server, and domain joined client running the Wazuh dashboard.

Summary

The project involves building a Windows Active Directory threat-detection lab using VirtualBox, consisting of a Windows Server domain controller, Windows 11 domain-joined client, Ubuntu-based Wazuh SIEM, and Kali Linux attacker VM. After configuring the domain, networking, Wazuh agents, and static IPs, several attack simulations were conducted, including Nmap reconnaissance, an RDP brute-force attempt, and suspicious encoded PowerShell activity involving an EICAR test file. Wazuh successfully captured and enabled investigation of the brute-force and PowerShell activity through endpoint logs, while the Nmap scans highlighted a limitation of host-based SIEM monitoring because network-level reconnaissance is better detected with a network intrusion detection system such as Suricata.

Environment Setup

The environment uses Oracle VirtualBox to setup a local Active Directory network. It consists of the Windows Server for Active Directory, Windows 11 Pro as the client to join the domain for Active Directory, Ubuntu Server for the Wazuh SIEM that manages security-related telemetry, monitor system activity, and generate alerts based on events occurring on agents, and Kali Linux to simulate attacks to the agents.

The environment consists of four virtual machines:

Host	Role	IP	OS
DC01	Domain Controller (Agent)	192.168.56.10	Windows Server 2025 Standard
CLIENT01	Domain Joined Endpoint (Agent)	192.168.56.20	Windows 11 Pro 25H2
siem01	Wazuh SIEM	192.168.56.30	Ubuntu Server 24.04 LTS
kali	Attacker (simulated threat)	192.168.56.104	Kali Linux 2025.4

Configuring Windows Server Active Directory

For the initial deployment of Windows Server 2025, I selected the Standard (Desktop Experience) installation option. This configuration provides a graphical user interface (GUI), which can simplify system administration and security configuration tasks. Although server environments are commonly managed through command-line interfaces, the GUI was useful for this initial configuration and validation phase.

An image of selecting the Windows server image — Selecting the Windows Server 2025 Standard (Desktop Experience) image.

The Windows Server installation process was straightforward and followed the standard operating system deployment procedure. Once the installation was completed, I focused on validating the network configuration established through the Host-only Adapter in VirtualBox. The objective was to confirm that the isolated virtual network was functioning as expected and that communication between the virtual machines could be established. To validate connectivity, I started the Kali Linux virtual machine, which was configured with the same Host-only Adapter. I then accessed Windows Defender Firewall with Advanced Security on the Windows Server through the GUI and configured an inbound firewall rule to permit ICMP echo requests. This allowed the Kali Linux VM to send ping requests to the Windows Server. This validation confirmed that the Host-only network was operational and that the Windows Server firewall was enforcing network access according to the configured rules.

An image of Windows Server Virtual Machine with the Windows Defender Firewall with Advanced Security application open — Windows Server VM with the Windows Defender Firewall with Advanced Security application open and configuring an inbound firewall rule to permit ICMP echo requests.

An image of Kali Linux VM pinging the Windows Server successfully after firewall setting change — Kali Linux VM pinging the Windows Server successfully after firewall setting change. (before Windows Server was assigned static IP)

After confirming successful ICMP connectivity between the Kali Linux virtual machine and the Windows Server virtual machine, I proceeded with configuring the Windows Server as a Domain Controller using Active Directory Domain Services (AD DS). The objective of this configuration was to establish a centralized identity and authentication infrastructure within the lab environment. Using Server Manager, I selected Add Roles and Features and installed the Active Directory Domain Services (AD DS) role along with the associated AD DS and AD LDS Tools.

An image of installing Active Directory Domain Services on the Windows Server — Installing Active Directory Domain Services on the Windows Server.

The role installation completed successfully, after which Server Manager prompted me to proceed with the Active Directory Domain Services deployment configuration. Within the Active Directory Domain Services Configuration Wizard, I selected the option to Add a new forest. I then configured the Root domain name as lab.local, establishing the domain namespace for the lab environment. I continued through the remaining configuration options and completed the deployment process. The AD DS installation completed successfully, and the Windows Server virtual machine automatically restarted to finalize the Domain Controller configuration. At this point, the Windows Server was configured as the first Domain Controller for the lab.local domain, providing the foundation for centralized authentication, identity management, and subsequent security monitoring within the lab environment.

An image of configured root domain name as lab.local — Configured root domain name as lab.local.

An image of Active Directory Domain Services installed sucessfully and restarting — Active Directory Domain Services installed sucessfully and restarting.

After the restart, I had access to the Active Directory Users and Computers Tool. Which enabled me to create new users in my Active Directory Domain that I could log in to from my client. I create a test user called "John Smith."

An image of the Active Directory Users and Computers tool in the Server Manager tools menu. — Active Directory Users and Computers tool in the Server Manager tools menu.

An image of the Active Directory Users and Computers tool. — Active Directory Users and Computers tool open.

An image of creating a user in the Active Directory Users and Computers tool. — Creating a user in the Active Directory Users and Computers tool.

After confirming I could create a user in the Active Directory Users and Computers tool, I began creating users and organizational units for the users to be in to gain familiarity with the tool and creating users and assigning then to organizational units.

An image of adding more users in Active Directory Users and Computers tool. — Adding more users in Active Directory Users and Computers tool.

An image of creating an organizational unit in the Active Directory Users and Computers tool. — Creating an organizational unit in the Active Directory Users and Computers tool.

An image of the created users moved to created organizational unit. — Created users moved to created organizational unit.

An image of domain joined client moved to created organizational unit. — Domain joined client moved to created organizational unit.

Creating the Windows 11 Client

During installation of the Windows 11 Client, I needed to create a local admin account however, the Windows 11 out of box experience was restricting me to only being able to continue by making an online account. I circumvented this by pressing the key combination "Shift + F10" to launch a command prompt window in the OOBE. With this command prompt window, I was able to execute the command "start ms-cxh:localonly" which spawned a "Microsoft Account" window that allowed me to create a local account.

An image of command prompt used to create a local account in the Windows 11 Out of Box Experience — Command prompt used to create a local account in the Windows 11 Out of Box Experience.

An image of creating a local account in the Windows 11 Out of Box Experience — Creating a local account in the Windows 11 Out of Box Experience.

Assigning static IP addresses to the environment

I wanted to assign static IP address to prevent the random variable of dynamic IP addresses so that the DC is always X, the client is always Y, the Wazuh manager is always Z. On the Windows Server and Windows 11 virtual machines this is a similar process. I went into the Network Connections section of the Control Panel on Windows and selected the 2nd ethernet adapter and went into properties. From the properties menu, I was able to change the ethernet adapter from "Obtain an IP address automatically" to "Use the following IP address."

An image of properties of Host only Ethernet adapter of DC01 — Properties of Host only Ethernet adapter of DC01.

I repeated this process on the Windows 11 Client virtual machine and confirmed that both machines had the assigned static IP addresses by using the command "ipconfig".

An image of Windows Terminal running the command ipconfig — Windows Terminal running the command ipconfig.

During installation of the Ubuntu Server, the host only network adapter shows up. I was able to change the dynamic IP address to a static IP address by chaning from Automatic (DHCP) to Manual at the Network configuration screen of the installation wizard.

An image of Oracle VirtualBox's network settings for the Ubuntu Server — Oracle VirtualBox's network settings for the Ubuntu Server SIEM.

An image of Changing from Automatic (DHCP) to Manual on Ubuntu Server network configuration — Changing from Automatic (DHCP) to Manual on Ubuntu Server network configuration.

An image of setting static IP on Ubuntu Server network configuration — Setting static IP on Ubuntu Server network configuration.

Domain joining the Windows 11 client

There is a settings panel under "Advanced system settings" that allows you to join a domain with a Windows 11 client. However, as you can see from the screenshots below I was unable to join a domain because I was using Windows 11 Home Edition.

An image of the Windows 11 settings application on the About section showing the Windows edition. — Windows 11 settings in the About section of the System settings showing the Windows edition.

An image of Windows 11 Home cannot join domain — Windows 11 Home cannot join domain.

This meant that I needed to change my Windows 11 edition from Home to Pro in order to gain the ability to join a domain. I discovered through searching online that you can change your Windows 11 Edition without having to reinstall Windows by executing a command as Administrator in PowerShell. Once the command completed, I restarted my virtual machine and when checking "winver" it states my operating system is "Windows 11 Pro." Changing the Windows edition enabled me join the lab.local domain after signing into a user I created in the Active Directory.

An image of Windows Terminal command changing Windows Edition — Changing the Windows Edition by executing a command in Powershell using Windows Terminal as Administrator.

An image of About Windows showing Windows Edition is Windows 11 Pro — About Windows now showing Windows Edition is Windows 11 Pro instead of Windows 11 Home.

An image of joining domain on Windows 11 client — Joining domain on Windows 11 client.

An image of Windows 11 client successfully joining the lab.local Active Directory Domain — Windows 11 client successfully joined the lab.local Active Directory Domain.

Setting up the Ubuntu Server for Wazuh SIEM

The Ubuntu Server operating system was installed as the foundation for the Wazuh SIEM environment. During the initial system configuration, the hostname was assigned as "siem01" to provide a clear and consistent identifier for the SIEM server. The initial administrative username was configured as "liam". This was later changed to "admin" to better align with a professional or organizational environment, where system accounts should use role-based or function-based naming conventions rather than personal identifiers. This approach improves administrative clarity and helps distinguish the account's purpose within the infrastructure.

Initial profile configuration on the Ubuntu Server.

An image of installing Ubuntu Server — Installing Ubuntu Server.

After fully going through the installation wizard, the installation completed successfully and I rebooted into the Ubuntu Server. After logging in, I created a new user named "admin" and gave the "admin" user sudo privileges. I then logged out of the "liam" user and logged into the "admin" user and then I deleted all files related to the user "liam" using a command.

An image of adding the admin user to the Ubuntu Server — Adding the "admin" user to replace the "liam" user on the Ubuntu Server.

Now that the Ubuntu Server is successfully installed and has an appropriate "admin" user, I was ready to install the Wazuh SIEM software on the Ubuntu Server. I installed the Wazuh server, the Wazuh indexer, and the Wazuh dashboard using the Wazuh installation assistant script. Once the installation was completed, the script output a username and password that I could input into the Wazuh dashboard to sign in.

An image of installing Wazuh SIEM on the Ubuntu Server — Installing Wazuh SIEM on the Ubuntu Server.

An image of successful installation of Wazuh SIEM on the Ubuntu Server showing credentials to login to Wazuh dashboard — Successful installation of Wazuh SIEM on the Ubuntu Server showing credentials to login to Wazuh dashboard.

After signing into the Wazuh web interface, I began the process of enrolling the Domain Controller/Windows Server and Client virtual machines as Wazuh agents. I started with the Domain Controller/Windows Server VM. The Wazuh interface simplifies the agent enrollment process by requiring the IP address of the Wazuh SIEM server and a designated agent name. Once the required information was provided, Wazuh generated the necessary installation and enrollment commands, which could then be copied and executed in an elevated PowerShell session on the Windows Server.

During the initial deployment, the Windows Server did not successfully register with the Wazuh manager. I repeated the agent enrollment process and restarted the Windows Server VM. Following these troubleshooting steps, the Windows Server successfully appeared in the list of active agents within the Wazuh web interface. The initial registration issue may have been related to the Windows Server version being used. Although the version was supported by Wazuh, the Wazuh documentation and recommendations indicated that an earlier Windows Server version was preferable for use as a Wazuh agent. This version difference may have contributed to the initial enrollment failure. Once the agent enrollment process succeeded with the Windows Server, I repeated the agent enrollment process for the Windows 11 Client and successfully added it as an agent.

An image of adding the Domain Controller/Windows Server as a Wazuh agent — Adding the Domain Controller/Windows Server as a Wazuh agent.

An image of executing commands in PowerShell as admin to add the Domain Controller/Windows Server as a Wazuh agent — Executing commands in PowerShell as admin to add the Domain Controller/Windows Server as a Wazuh agent.

An image of the Wazuh interface showing the agent list — Wazuh interface showing Windows Server and Windows 11 virtual machines in the agent list.

This completes the environment setup as I already had a Kali Linux virtual machine which means I can move on to doing attack simulations against the DC and Client.

Attack Simulations

The first attack I'll simulate is network reconnaissance using Nmap from my Kali Linux virtual machine. The goal of this was to identify live hosts on the subnet and enumerate the services running on them, similar to how an attacker would begin mapping out a target network before attempting to compromise it.

I started with a host discovery scan against the entire subnet using the command nmap -sn 192.168.56.0/24 to identify which hosts on the network were alive. This confirmed that DC01, CLIENT01, and siem01 all responded. From there, I ran a more detailed service and version scan against DC01 specifically using nmap -sV -p- 192.168.56.10, which revealed the services you'd expect to see on a domain controller — LDAP (389), Kerberos (88), and SMB (445) among others. I repeated this scan against CLIENT01 as well to see what services were exposed on the domain-joined endpoint.

Nmap host discovery and service enumeration results showing the live hosts and exposed services in the lab network — Nmap reconnaissance showing the live hosts discovered on the subnet and the services exposed by the lab systems.

RDP Brute-Force Attack

The next attack I performed was a brute-force login attempt against RDP, targeting a domain account rather than a local one. Before I could run this attack, I needed to make sure RDP was actually enabled on CLIENT01 and that my test account had permission to use it. By default, only members of the Remote Desktop Users group (or local admins) can log in over RDP, so I had to manually add my test user, "Walter White," to the Remote Desktop Users group on CLIENT01. When adding the user through the group membership dialog, I had to use "Check Names" to confirm the object resolved correctly, since the dialog accepts a few different formats (UPN, sAMAccountName, or display name).

Windows Remote Desktop Users group showing the Walter White domain account added to CLIENT01 — The Walter White domain account added to the Remote Desktop Users group on CLIENT01 to permit RDP authentication.

With that permission in place, I moved to my Kali Linux VM and used Hydra to perform the brute-force attempt. I built a small wordlist containing a handful of incorrect passwords with the correct one placed near the end, to simulate an attacker working through a list without knowing the real password in advance. The command I used was:

hydra -l walter.white -P wordlist.txt rdp://192.168.56.20

Hydra output showing a successful RDP brute-force authentication against the Walter White account — Hydra successfully authenticating to RDP after discovering the correct password in the test wordlist.

I used the sAMAccountName (walter.white) rather than the full UPN (walter.white@lab.local), since Hydra's RDP module is built on FreeRDP and tends to authenticate more reliably against the short logon name format. The attack successfully authenticated once it reached the correct password in the list, confirming the brute-force was successful.

Suspicious PowerShell Activity

The final attack I performed was simulating suspicious PowerShell activity, specifically an encoded command that downloads a payload from an external host — a common technique used by attackers to evade basic detection and obscure what a command is actually doing. I hosted an EICAR test file (a standard, harmless file used to safely test antivirus/detection without using real malware) on my Kali Linux VM and served it over a simple web server. From CLIENT01, I ran a PowerShell command that was base64-encoded and, when decoded, downloaded the EICAR file from my Kali VM and executed it locally. This simulates the common "download cradle" pattern where a short PowerShell one-liner is used to pull down a second-stage payload rather than including the malicious content directly in the command itself.

Creating payload executable from the Kali Linux virtual machine.

Encoded PowerShell command downloading the EICAR test file from the Kali Linux virtual machine — Encoded PowerShell activity on CLIENT01 downloading the EICAR test file from the Kali Linux VM.

Investigation

With all three attacks completed, I moved into investigating what Wazuh actually captured for each one, using the Threat Hunting and Discover views in the Wazuh dashboard.

Investigating the Recon

I started by checking whether the Nmap scans had generated any alerts. Despite checking Threat Hunting and later Discover, I found nothing related to the scans. After researching this gap, I determined the reason: Wazuh is a host-based SIEM, meaning it relies on agents installed on endpoints to generate and forward log data. A network-level port scan like Nmap doesn't necessarily trigger anything on the host itself to log, since the scan is observed at the network level rather than by a process on the machine. Detecting this type of activity natively would require a network intrusion detection system (NIDS), such as Suricata that is integrated with Wazuh, which was outside the scope of what I wanted to add to this lab.

Wazuh Threat Hunting view showing no alerts generated from the Nmap reconnaissance scan — Wazuh Threat Hunting showing the absence of alerts generated by the network-level Nmap reconnaissance scan.

As part of exploring this gap further, I looked into whether Sysmon could provide partial visibility. What I found was logging of Event ID 22 (DNS Query) on the client. I installed Sysmon on CLIENT01 using a community configuration file and confirmed it was logging locally through Event Viewer. I then updated the Wazuh agent's ossec.conf to forward the Sysmon operational log channel to the SIEM.

Installing Sysmon from Microsoft and the SwiftonSecurity Sysmon config from GitHub on CLIENT01 — Downloading Sysmon from Microsoft and the SwiftOnSecurity Sysmon config from GitHub on CLIENT01.

Installing the SwiftOnSecurity Sysmon config on CLIENT01.

Sysmon Event ID 22 DNS query event displayed in Windows Event Viewer on CLIENT01 — Sysmon Event ID 22 DNS Query events being logged locally on CLIENT01.

To view these events in the dashboard, I also had to enable event archiving on the Wazuh manager (logall and logall_json in the manager's ossec.conf), since by default Wazuh only indexes events that match an existing alert rule, and create a new index pattern for wazuh-archives-* since raw/unmatched events aren't stored in the default alerts index. This let me confirm Sysmon events were reaching the dashboard, though it reinforced the same underlying limitation — host-based logging alone isn't well-suited to detecting a network-level scanning pattern, which is best addressed with a dedicated NIDS rather than endpoint telemetry.

Wazuh Discover view showing Sysmon events forwarded from CLIENT01 — Sysmon events successfully forwarded to Wazuh.

Investigating the Brute-Force

Checking the brute-force attempt was more straightforward. Filtering Threat Hunting for authentication-related events, I located a cluster of failed logon events (Event ID 4625) against the "Walter White" account, all occurring within a short window and originating from my Kali VM's IP address — a clear signature of a brute-force attempt rather than a normal failed login.

Wazuh Threat Hunting showing multiple Windows Event ID 4625 failed logon events from the Kali Linux IP address — Wazuh Threat Hunting identifying the cluster of failed RDP logon attempts associated with the brute-force attack.

Investigating the PowerShell/EICAR Activity

For the PowerShell activity, I checked both the PowerShell-related events and any antivirus/detection logs forwarded from the client. The EICAR file download and execution were both visible in the logs, confirming that Wazuh picked up on the activity once it reached the endpoint.

Wazuh dashboard showing PowerShell and antivirus events associated with the EICAR test file activity — Wazuh detecting the suspicious PowerShell activity and EICAR test file execution on CLIENT01.

Windows Active Directory Threat Detection(In Progress)