Building the Vulnerable Active Directory Lab

This is the design doc for the E Corp AD detection lab. It covers what the environment is, how it's instrumented, and the decisions behind it.

What's in the environment

A single Windows Server domain controller running the ecorp.local forest, two domain-joined Windows 11 workstations (WS01, WS02), a Kali attacker box, and a Wazuh manager collecting events. OPNsense serves as the firewall and VLAN gateway, segmenting the lab onto VLAN 60 (10.60.60.0/24) with a single pinhole back to Wazuh for continued agent reporting. The domain is populated with around two dozen accounts across an Employees, Executives, Technology, and ServiceAccounts OU structure, plus the groups that define the privilege-escalation path.

Why agents AND a network sensor

Wazuh is agent-based. An agent runs on each Windows host, reads the Security and Sysmon event channels locally, and ships them to the manager over an outbound connection it initiates itself. This matters because six of the seven attacks in this lab are host-based: Kerberoasting, AS-REP roasting, password spray, ACL abuse, pass-the-hash, and DCSync all leave their evidence in Windows event logs on the DC or a workstation. An agent reading those logs sees everything, regardless of where the host sits on the network.

The exception is LLMNR/NBT-NS poisoning, which is a network-level attack. The poisoned name-resolution exchange happens on the wire, not in any Windows event log, so host agents are blind to it. The detection for that slice used tcpdump on the isolated lab segment to capture the poisoning as a pcap file.

Why flat first, isolation later

The first instinct was to build everything behind a segmented VLAN with tight firewall rules before touching anything else. That turned out to be the wrong order. Six of the seven attacks are quiet: they don't reach out and touch other machines, so they're safe to run on a flat network in a homelab. Only LLMNR poisoning is genuinely unsafe on a flat network, because Responder will poison real hosts and capture real credentials.

So isolation was gating the whole project for the sake of one attack. The call was to build flat, get the foundation and detections working for the six safe attacks, and treat network isolation as a separate, documented step that unlocks the LLMNR slice when it's ready. Build the thing, then harden it.

The isolation was built as the final phase: VLAN 60 on OPNsense with DHCP handing out the DC as DNS, a single firewall pinhole to Wazuh (TCP 1514-1515), and an RFC1918 block on everything else. The DC, workstations, and Kali were migrated onto the isolated segment, and the LLMNR attack ran safely within it. The full isolation build and the issues it surfaced are documented in the LLMNR writeup.

Audit policy

None of the detections work if the events don't exist, and by default most of them don't. The build script enables exactly the audit subcategories the attacks need:

• Kerberos Service Ticket Operations → 4769 (Kerberoasting)
• Kerberos Authentication Service → 4768 (AS-REP roasting)
• Credential Validation → 4776 (NTLM auth during spray)
• Logon / Logoff → 4624 / 4625 (password spray, pass-the-hash)
• Directory Service Access → 4662 (DCSync)
• Directory Service Changes → 5136 (ACL abuse, DCSync rights grant)
• Security Group Management → 4728 / 4732 (privileged group changes)

One lesson learned: the build script sets audit policy on the DC only. The pass-the-hash detection (4624 type 3 on a workstation) requires audit policy on the endpoints too, not just the domain controller. In production this would be pushed via GPO to all machines.

Staged vulnerabilities, one piece at a time

The build script creates clean infrastructure. It deliberately does not plant most of the vulnerabilities. The only weakness baked in is the shared employee password, because that one is just part of creating the users and it shows how password spraying works in the wild.

Everything else gets planted one piece at a time: register the SPN for Kerberoasting, disable pre-auth for AS-REP, set the dangerous ACL, create the shared local admin for pass-the-hash, and so on. The reason is detection clarity. If all the misconfigurations exist at once, the telemetry overlaps and it's hard to tell which event came from which attack. Planting one, attacking it, capturing its specific events, and writing it up before moving to the next keeps each detection clean.

The escalation path

The accounts aren't named at random. The privilege path is cast so the BloodHound graph tells the show's story:

• Angela Moss and Bill Harper sit in Helpdesk, low privilege, the foothold.
• Tyrell Wellick is the Tier-1 admin one rung up.
• The ACL piece gives Helpdesk control over Wellick's group, which leads toward Domain Admins.
• Pass-the-hash spreads laterally across workstations using a reused local admin hash, quietly, without touching the domain controller.
• Phillip Price, the CEO, is the symbolic crown jewel that DCSync ultimately exposes.

So the full chain reads: compromise a helpdesk account, poison name resolution to steal hashes off the wire, abuse a delegated right to control Wellick, escalate to Domain Admins, move laterally via hash reuse, then DCSync the domain and own Price. One coherent narrative from a single sprayed password to total domain compromise.