Almost every company I want to work for runs Active Directory, and almost every real investigation touches it. You cannot learn AD defense from slides. You learn it by building a domain, breaking it the way attackers do, and reading the logs it leaves behind. This is how my AD lab is built, the attacks I practise against it, and the defenses I check afterward. The domain side of my lab feeds the same Wazuh manager as everything else in my home SOC lab, and the DC runs as a virtual machine on purpose, since a domain controller does not belong in a container, as I found while building the Docker version of the lab.
The Build, at a High Level
One Windows Server 2022 VM becomes the domain controller. Static IP first, because a DC that changes address breaks everything downstream. Then the AD DS role and promotion:
powershell
Install-WindowsFeature AD-Domain-Services -IncludeManagementTools
Install-ADDSForest -DomainName "lab.local" -InstallDns
DNS installs alongside AD because the domain depends on it. After the reboot I have a working domain and exactly one account worth anything, which is not a lab yet. The part that turns it into a lab is the population work:
- Organizational units and users. A small company worth of accounts: a couple of admins, regular users in departments, and service accounts, because attacks target all three differently.
- A workstation VM joined to the domain, so logons, group policy and lateral movement behave the way they do at a real job.
- A deliberately weak service account with an SPN set, the standing invitation for Kerberoasting practice.
- Audit policy turned up through group policy. Advanced Audit Policy for logon and logoff, account management, and process creation, plus the setting that puts the command line into event 4688. A default DC logs less than you think. My event IDs post covers the exact events this policy produces and why each one matters.
- The Wazuh agent on the DC, forwarding the Security log to the manager, so domain events land in the same dashboard as the rest of the lab.
I also keep an Entra ID tenant from my identity study work, set up separately from the on premises domain. Comparing how the same identity ideas, accounts, groups, roles, MFA, look in Entra ID versus classic AD is its own lesson, and it is the direction every hybrid workplace I apply to is heading.
The Attacks I Practise
Kerberoasting is the main event, and it has its own full writeup: Kerberoasting my lab DC. Request a service ticket for the weak account, take the ticket offline, crack at leisure. Nothing about it touches the network in a way that looks like an attack, which is exactly why it is worth practising.
Password spraying against domain accounts, one common password across many users, slowly. Run from the Kali box and watched from the DC side, where events 4625 and 4776 tell the story. This is the simulation that taught me threshold based detection has a hole shaped like patience, covered in my simulation results.
Enumeration with built in tools. Before any attack tool comes out, I walk the domain with what Windows already ships:
powershell
net user /domain
net group "Domain Admins" /domain
Get-ADUser -Filter 'ServicePrincipalName -like "*"' -Properties ServicePrincipalName
That last command is the defender's view of Kerberoasting risk: every account an attacker can roast, listed in one output. Running the attacker tools first and the audit commands second is the wrong order for a defender. The lab lets me practise both directions.
Account creation and group changes as persistence practice: make a user, add it to Administrators, then go find events 4720 and 4732 in the SIEM and time how long the hunt takes. Detection you have never timed is detection you are guessing about.
The Defenses I Check
Every attack run ends with the same defensive checklist:
- Kerberos encryption. Service accounts set to AES only. RC4 tickets, encryption type 0x17 in event 4769, are the Kerberoasting tell, and removing RC4 removes the easy version of the attack.
- Service account passwords. Long, random, rotated. A 25 character password makes the cracked ticket worthless in practice. Managed service accounts exist for exactly this and the lab is where I learned why.
- SPN hygiene. Audit who has SPNs and whether they still need them. Every stale SPN on a weak account is an open door with a sign on it.
- Log coverage. Confirm the DC's Security log actually reached Wazuh for the whole attack window. Twice in this lab the answer was no, once from an agent that had stopped, once from my own audit policy gap. Both times the attack had succeeded silently until I checked by hand.
- Admin account separation. Daily work on a standard account, admin accounts used only for admin work, so a stolen daily password is not a domain compromise.
What Building It Taught Me
Reading about AD, you think in features. Running AD, you think in logs and failure modes. The domain is not the diagram. The domain is the 4769 events at 2 in the morning, the group policy that did not apply because of one wrong OU, the agent that stopped forwarding on the day of your best simulation. Employers do not need me to recite what a domain controller is. They need someone who has watched one misbehave and found the evidence. That is what this lab is for.
Next: adding a second DC for replication, because replication traffic is one more thing attackers abuse and I have not practised defending it yet.