Active Directory Pentest Lab – Red & Blue Team Homelab on Proxmox
This is my home cybersecurity lab, and the project that takes up most of my evenings. I took a refurbished Lenovo ThinkStation P720 and I'm turning it into a small company network that lives entirely inside one machine. Then I attack it, and I try to catch myself doing it.
I write up every step as I go, mistakes included, so anyone who wants to build a similar Active Directory lab at home can follow along on their own hardware.
What the lab will look like when it's finished
The lab simulates a company that has just bought another one. The first, corp.lab, has a domain controller, eight Windows 11 workstations and a file server. The second, acquired.lab, is a separate Active Directory forest with its own domain controller, joined to the first by a two-way trust. In real life a merger like that is a gift for attackers, which is exactly why I wanted one.
Eight simulated employees use the workstations all day, browsing the intranet, opening documents and copying files to shared folders. Without them the network would be silent, and spotting an attacker on a silent network doesn't prove much.
There are also a few traps: decoy accounts and a fake file server that nobody has any reason to touch. If something touches them, it's almost certainly an attacker, and an alert goes off.
Next door there's GOAD, a separate set of vulnerable Windows machines just for attack practice, and a small isolated honeynet with honeypots open to the internet. About twenty virtual machines in all, on one host with 48 threads and 128 GB of RAM, which I can switch on and reach from anywhere over WireGuard.
Red team and blue team on the same network
On the attacking side there's a Kali machine on its own VLAN, used for the kind of Active Directory attacks a real pentest goes through: enumeration, Kerberoasting, abusing the trust between the two forests.
On the defending side there's a small SOC, kept outside the lab's ranges on its own network, behind its own firewall, so nothing I break or wipe in the lab can reach it. Wazuh collects the logs, Sysmon runs on every Windows machine and Suricata watches a copy of all the lab traffic. That way I see every attack from both ends: what I did as the attacker, and what actually showed up in the logs.
Why the main domain starts clean
Most Active Directory labs are full of holes from day one. That's fine for practising attacks, but a detection rule written on a network that's always noisy can't be trusted. So corp.lab is built as clean as the tooling allows, and I keep a snapshot of that clean state.
Every exercise follows the same routine. I break one thing on purpose, attack it, check what the SOC caught, write a rule for it, roll the lab back to the snapshot and make sure the rule stays quiet. One weakness at a time, so I always know which alert came from which action.
I write up every step as I go, mistakes included, so anyone who wants to build a similar Active Directory lab at home can follow along on their own hardware.
What the lab will look like when it's finished
The lab simulates a company that has just bought another one. The first, corp.lab, has a domain controller, eight Windows 11 workstations and a file server. The second, acquired.lab, is a separate Active Directory forest with its own domain controller, joined to the first by a two-way trust. In real life a merger like that is a gift for attackers, which is exactly why I wanted one.
Eight simulated employees use the workstations all day, browsing the intranet, opening documents and copying files to shared folders. Without them the network would be silent, and spotting an attacker on a silent network doesn't prove much.
There are also a few traps: decoy accounts and a fake file server that nobody has any reason to touch. If something touches them, it's almost certainly an attacker, and an alert goes off.
Next door there's GOAD, a separate set of vulnerable Windows machines just for attack practice, and a small isolated honeynet with honeypots open to the internet. About twenty virtual machines in all, on one host with 48 threads and 128 GB of RAM, which I can switch on and reach from anywhere over WireGuard.
Red team and blue team on the same network
On the attacking side there's a Kali machine on its own VLAN, used for the kind of Active Directory attacks a real pentest goes through: enumeration, Kerberoasting, abusing the trust between the two forests.
On the defending side there's a small SOC, kept outside the lab's ranges on its own network, behind its own firewall, so nothing I break or wipe in the lab can reach it. Wazuh collects the logs, Sysmon runs on every Windows machine and Suricata watches a copy of all the lab traffic. That way I see every attack from both ends: what I did as the attacker, and what actually showed up in the logs.
Why the main domain starts clean
Most Active Directory labs are full of holes from day one. That's fine for practising attacks, but a detection rule written on a network that's always noisy can't be trusted. So corp.lab is built as clean as the tooling allows, and I keep a snapshot of that clean state.
Every exercise follows the same routine. I break one thing on purpose, attack it, check what the SOC caught, write a rule for it, roll the lab back to the snapshot and make sure the rule stays quiet. One weakness at a time, so I always know which alert came from which action.
- $ catAcceptance testing a refurbished ThinkStation P720
- $ catSwitching off Intel AMT, and the firmware note that was wrong
- $ catProxmox by way of Ludus, and a Wake-on-LAN the firmware rules out
- $ catFour Ludus templates and a throwaway range on a host that could not reboot
- $ catA SOC network beside Ludus, and a firewall script changed by its review
- $ catA SIEM and a sensor outside Ludus, and a test site that no longer resolves
- $ catIPv6 off, a bigger heap, and a SIEM restored without a network card
- $ catA domain behind its firewall, and a sensor that could not keep up
- $ catA second forest, and the one reboot that had to land on the new machine
- $ catEleven agents, and a password kept off every command line
- $ catUsers for two forests, and a firewall rule that was not enough
- $ catA baseline snapshot, and what the blueprint really holds