What I built#
A self-contained Active Directory forest that exists purely to be attacked: a Windows Server domain controller, a member server, and a Windows workstation, all on an isolated VLAN with no route to anything I care about. Every technique I read about in a writeup, I can actually run here first.
Why#
Practising AD attacks against Hack The Box is fine, but the boxes are solved puzzles — you know a vulnerability is there because the box exists. A lab you misconfigured yourself teaches the other direction: what a real environment looks like before anyone has found the hole, and which of your own defaults are the hole.
The constraint that shaped everything was isolation. These machines are deliberately weak, so the one non-negotiable is that nothing they run can reach the rest of the house.
The build#
Three VMs on the Proxmox cluster, all pinned to a dedicated VLAN that pfSense does not route anywhere else:
- DC01 — domain controller, DNS, the forest root
- SRV01 — a member server running a couple of services with SPNs, so there is something to Kerberoast
- WS01 — a Windows 10 workstation, the “user” foothold
Add photos of the Proxmox console and the pfSense VLAN config here:
Making it realistically bad#
A clean AD install is nearly impossible to attack, which is the point — real environments accrete weaknesses over years. I seeded a few on purpose:
- a service account with a weak password and an SPN (Kerberoasting)
- a second account with pre-authentication disabled (AS-REP roasting)
- a nested group membership that grants more than it looks like it does
- a share with permissions a little too generous
What broke#
DNS, as it always does with AD. The workstation wouldn’t join the domain until I pointed it at the DC for DNS rather than the pfSense resolver — AD is almost entirely DNS underneath, and a domain join fails in confusing ways when name resolution is even slightly wrong.
What I would do differently#
Snapshot before seeding the weaknesses, not after. The first time through I attacked the range, changed things, and then couldn’t cleanly get back to a known state. Now there’s a “pristine but vulnerable” snapshot on all three VMs, so a full reset is thirty seconds instead of a rebuild.