~/tutorials / active-directory-concepts-with-goad
Active Directory Concepts in a GOAD Lab
Build the Game of Active Directory lab and learn the trust relationships, Kerberos tickets, and misconfigurations that drive internal assessments.
Lab only. Practice these techniques on your own machines or on platforms that explicitly authorize testing. Informational and educational use only.
Nearly every corporate network runs Active Directory, and most internal assessments end the same way: a chain of small misconfigurations leading to domain-wide control. You cannot learn this on production. You need a lab built to be broken, and GOAD (Game of Active Directory) by Orange Cyberdefense is the best free one.
GOAD is intentionally vulnerable. Run it on an isolated host-only or internal network, never bridged to your home or work LAN, and never expose it to the internet.
What GOAD gives you
GOAD deploys several Windows servers across multiple domains and a forest trust, pre-seeded with realistic misconfigurations. It uses Vagrant and Ansible to provision on VirtualBox, VMware, or Proxmox. The full lab wants roughly 24 GB of RAM and 100 GB of disk. A smaller variant, GOAD-Light, runs on less.
Follow the project’s own install documentation for your hypervisor. Snapshot every VM once provisioning finishes so you can reset in minutes.
The objects that matter
| Object | Why testers and defenders care |
|---|---|
| Users and groups | Group membership decides privilege. Nested groups hide it. |
| Computers | Each has a machine account with its own credentials. |
| Service accounts | Often over-privileged and rarely rotated. |
| Group Policy | Pushes settings, scripts, and sometimes credentials to machines. |
| ACLs on objects | “Who can reset whose password” is where most attack paths live. |
| Trusts | Let users in one domain access another. A weak trust links two blast radii. |
The key insight is that AD compromise is mostly about relationships, not exploits. An account that can modify a group that can log in to a server where an admin has a session is a path, even if every piece looks harmless on its own.
Seeing the graph
BloodHound collects these relationships and draws them as a graph. Run its collector from a domain-joined lab machine, import the data, and ask questions like “shortest path from this user to Domain Admins.”
Defenders should run BloodHound on their own environment for exactly the same reason: every path it finds is a path to cut. Removing a single unnecessary ACL often breaks dozens of attack paths at once.
Kerberos in one picture
Kerberos authenticates users with tickets instead of sending passwords around:
- You prove your identity to the domain controller and receive a Ticket Granting Ticket (TGT).
- When you want a service, you present the TGT and receive a service ticket for that service.
- You present the service ticket to the service.
Two well-known weaknesses come from this design, and GOAD includes both so you can study them:
- Kerberoasting. Service tickets are encrypted with the service account’s password hash. Any domain user can request one and attempt to crack it offline. Weak service account passwords fall quickly.
- AS-REP roasting. Accounts with Kerberos pre-authentication disabled hand out crackable material to anyone who asks.
Defending what you learn
For every weakness you study in GOAD, learn the fix and the detection:
| Weakness | Fix | Detection |
|---|---|---|
| Kerberoasting | Long random passwords, Group Managed Service Accounts, AES only | Event 4769 with RC4 encryption type, unusual volume per user |
| AS-REP roasting | Require pre-authentication on every account | Event 4768 for accounts without pre-auth |
| Excessive ACLs | Review with BloodHound, remove unneeded rights | Event 5136 on sensitive object changes |
| Local admin reuse | Windows LAPS | Logons with the same local account across many hosts |
| NTLM relay | SMB signing, LDAP signing and channel binding, disable NTLM where possible | NTLM authentication from unexpected sources |
Turn on advanced audit policies in your GOAD domain, forward logs to a free SIEM, and watch what each technique produces.
Going further
- The GOAD project’s own write-ups walk through its intended paths.
- Hack The Box Pro Labs and TryHackMe AD rooms offer guided practice on hosted infrastructure.
- Microsoft’s own AD security best practices documentation is dense but authoritative.
Takeaway
Think in graphs. The question is never “is this one setting bad” but “what does this setting connect to.” Learn to answer it in a lab, then help real organizations cut the paths.