Mapping an AD lab: from enumeration to domain admin
A small Active Directory lab I built to practise. This is the thinking behind each phase, not a copy-paste guide. Names, credentials and the final path are blurred.
Scope: my own isolated lab. One domain controller, two workstations, a handful of users, deliberately misconfigured.
1. Enumerate before you touch anything
Most of the work is reading, not attacking. Before any credential test, I mapped what the domain would tell me: users, groups, computers, shares and who is allowed to do what.
- Which accounts exist and which are privileged.
- Which shares are readable and what is sitting in them.
- Where group memberships and permissions chain together.
2. Look for the weak link, not the clever exploit
In real environments the way in is usually a habit: an old script with a stored password, a service account nobody rotates, a group that has more rights than it needs. My lab was the same.
# note from the lab journal found: credentials in a readable share -> svc_backup : ******** owner: IT scripts folder
3. Follow the relationships
One low-privileged account is rarely enough on its own. Graphing the domain showed how that account connected to others through group membership and delegated rights. The path to domain admin was three hops long.
4. Prove it, then stop
Once I could show control of the domain, I documented it and stopped. The goal of a test is evidence and a fix list, not damage.
Final path: share → service account → group rights → DA
The fix list (the part that matters)
- Never store credentials in scripts or shares. Use a vault.
- Give service accounts long, rotated passwords and only the rights they need.
- Review group memberships and delegated permissions regularly.
- Alert on unusual directory queries and logons from service accounts.
What I took away
Active Directory is a web of trust. Breaking it is mostly about patience and reading, and defending it is mostly about hygiene. Both sides benefit from mapping it first.