visitor@hunterweygandt:~$ cat building-the-lab.html|

Building The AD Lab

Vulnerable Active Directory Lab · 2026

← Back to the other documents

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, one or two domain-joined Windows 11 workstations, and a Wazuh manager collecting events. 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, not 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 the attacks in this phase of the lab are all host-based: Kerberoasting, AS-REP roasting, password spray, ACL abuse, and DCSync all leave their evidence in Windows event logs on the DC. An agent reading those logs sees everything, regardless of where the host sits on the network, so a domain controller and a central manager are all that's needed to detect the full initial-access-to-domain-dominance chain.

Network-level attacks (for example LLMNR/NBT-NS poisoning) are a planned future phase and are detected differently, with a network sensor such as Suricata or Zeek watching the traffic rather than a host agent.

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. Every attack in the current DC-only set is quiet: none of them reach out and touch other machines, so they're all safe to run on a flat network in a homelab. Network-poisoning attacks would be the exception, but those belong to a later workstation-based phase.

So isolation was gating the whole project for no benefit at this stage. The call was to build flat, get the foundation and detections working for the host-based attacks, and treat network isolation as a separate, documented step for when the workstation phase begins. Build the thing, then harden it.

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 current attacks need:

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's the 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, 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:

So the full chain reads: compromise a helpdesk account, abuse a delegated right to control Wellick, escalate to Domain Admins, then DCSync the domain and own Price. One coherent narrative from a single sprayed password to total domain compromise.

← Back to the other documents