About The AD Lab

E Corp AD Detection Lab

A deliberately vulnerable Active Directory environment, themed after Mr. Robot, built to practice the full attack-to-detection loop. Every attack in this lab is run by hand, the telemetry it generates is captured, and a detection is written and tuned against it in Wazuh.

The point of this lab is not the attacks. The point is catching them.

Lab use only. This domain ships with weak passwords and intentional misconfigurations. It is built to be attacked in an isolated environment. Do not run any of this on a network that touches real assets.

On the build scripts

The OU structure and user population in Setup/ were generated with the help of an AI assistant to save time on boilerplate, the same way you might use BadBlood or a New-ADUser loop.

The story

E Corp is the target. fsociety are the attackers, so they have no domain accounts; they break in from outside. The attacks below walk a single coherent kill chain, the same climb the show is about: start with one low-level employee account and end up owning the entire domain.

# Password spray a shared employee password        (foothold)
$password = "Welcome123!"
$users = Get-ADUser -Filter "Enabled -eq $true" | Select-Object -ExpandProperty SamAccountName

$users | ForEach-Object { Test-ADCredential -Username $_ -Password $password }

# roast service accounts offline           (more creds)
Get-ADUser -Filter "ServicePrincipalName -like '*'" | Select-Object -ExpandProperty ServicePrincipalName

# abuse a delegated ACL           (Helpdesk -> Wellick)
$acl = Get-Acl

The attacks (current phase: DC-only)

This phase covers the full initial-access-to-domain-dominance chain using only a domain controller and a central Wazuh manager, no workstations required. Each attack has its own writeup on my website, hunterweygandt.com, and each ships with a custom Wazuh detection rule, because the stock ruleset does not flag any of these by default.

Numbering follows the full kill-chain plan; slices 4 (LLMNR/NBT-NS poisoning) and 6 (pass-the-hash) are network- and workstation-based and are planned for a later phase (see Roadmap).

What each detection demonstrates

• Single-event rules (1, 2) match one anomalous event: an RC4 service ticket, or a pre-auth-disabled TGT request.
• Stateful correlation (3) fires on a pattern no single event reveals, a burst of failed logons across many accounts from one source, using Wazuh's frequency and timeframe logic.
• Context-scoped rules (5) avoid alert fatigue by firing only on changes to _privileged_ groups, not every routine group change.
• Exclusion-based rules (7) separate the attack from legitimate lookalike traffic, alerting on directory replication only when it comes from a non-DC account, since real domain controllers replicate constantly.

Detection stack

Wazuh agents on the DC read the Windows Security and Sysmon event channels locally and ship them to a central manager. Wazuh is agent-based, not a network sniffer, so it sees host events regardless of network topology. Every detection in this phase is host-based and lands cleanly through the agent.

A recurring theme: the stock Wazuh ruleset does not detect any of these attacks out of the box. It labels the underlying events as low-severity noise. Each part's real work is tracing the event end to end (generated on the DC, shipped by the agent, then buried at the rule layer) and writing the custom rule that surfaces it. DCSync is the sharpest example, its 4662 events arrive at the manager but produce no default alert, so one of the most severe AD attacks is invisible until a custom rule is built.

Build order

1. Setup/01-Install-DomainController.ps1 on a clean Windows Server. Promotes the ecorp.local forest, reboots automatically.
2. Setup/02-Build-Environment.ps1 as ECORP\Administrator after reboot. Creates the OUs, users, groups, service accounts, and audit policy.
3. Deploy a Wazuh agent to the DC, confirm events land in the dashboard.
4. Add the custom rules from the writeups to /var/ossec/etc/rules/local_rules.xml.
5. Work each slice: plant the misconfiguration, run the attack, confirm the detection fires, document.

Repository layout

Vulnerable-AD-DC-Project---Hunter-Weygandt/
        ├── README.md
        ├── Setup/
        │   ├── 01-Install-DomainController.ps1   (forest promotion)
        │   └── 02-Build-Environment.ps1          (population + audit policy)
        ├── Logs/
        │   ├── ACL Abuse - Wazuh Log
        │   ├── ASREP - Wazuh Log
        │   ├── DCSync - Wazuh Log
        │   ├── Kerberoasting - Wazuh Log
        │   └── Password Spraying - Wazuh Log
        └── Wazuh Rules/
            ├── ACL Abuse Rule
            ├── ASREP Rule
            ├── DCSync Rule
            ├── Kerberoasting Rule
            └── Password Spraying Rule

        hunterweygandt.com/posts/vulnerable-ad-lab/
        ├── about
        ├── building-the-lab
        ├── acl-abuse
        ├── asrep
        ├── dcsync
        ├── kerberoasting
        └── password-spray

Roadmap

A later phase adds workstation and network-based attacks, which require standing up domain-joined endpoints and network sensors:

• LLMNR/NBT-NS poisoning (Responder), detected with Suricata/Zeek
• Pass-the-hash lateral movement, detected via cross-host logon telemetry
• Network isolation (segmenting the lab) as a prerequisite for the poisoning work