The Active Directory Attack Chain: From Foothold to Domain Admin

Most real internal penetration tests aren't really about any single exploit — they're about Active Directory. Compromise one workstation, land one set of low-privileged domain credentials, and AD's own trust relationships usually do the rest of the work for you. This guide walks the path that keeps showing up: enumerate what a credential can see, extract more credential material from it, and use each new credential to reach a little further, until something reaches a domain controller with replication rights. None of the individual steps are exotic; the chain is what makes AD compromise feel almost inevitable once you have any foothold at all.

Diagram of the Active Directory attack chain: a low-privileged credential leads to enumeration, which branches into Kerberoasting/AS-REP roasting and dumping NTLM hashes, both feeding into reusing the credential elsewhere, which produces a new foothold that either loops back to enumeration or, once it holds DCSync rights, reaches Domain Admin — The chain isn't strictly linear — every new foothold usually means going back to enumeration before pushing further.

Enumeration comes first

Before attacking anything, work out what the domain actually looks like. NetExec is the practical starting point — spray or validate a credential across the whole subnet, then pull user lists, group membership, and share access over LDAP and SMB with that same credential. For a fuller picture of the relationships between users, groups, and computers — who has admin rights on what, whose session is sitting on which machine, what path of group memberships leads to Domain Admins — BloodHound is the standard tool: an ingestor (bloodhound-python, runnable from a Linux attack box with just a domain credential, no agent needed) collects the graph data, and BloodHound's own interface finds the shortest attacker path through it. Treat enumeration as the phase you return to after every new credential, not a one-time step — a new account can see a different slice of the domain than the one before it.

Kerberoasting

Any domain user can request a Kerberos service ticket (a TGS) for any service principal name (SPN) registered in the domain — that part of Kerberos is by design, not a bug. The ticket is encrypted with a hash derived from the service account's own password. If that account's password is weak, an attacker with any valid low-privileged domain credential can request the ticket, take it offline, and crack it — with zero interaction with the service account itself, and often zero alerting, since requesting a TGS is completely normal Kerberos traffic.

GetUserSPNs.py DOMAIN/user:password -dc-ip 10.10.10.5 -request

This pulls every account in the domain with a registered SPN and requests a ticket for each, outputting a crackable hash per account. Feed it to Hashcat (-m 13100) or John. Service accounts are Kerberoasting's favorite target for a specific reason: they're often created once, given a long, complex-looking name, and then never touched again — including the password, which frequently predates the org's current password policy entirely.

AS-REP roasting

A related but distinct bug: Kerberos pre-authentication normally requires proving you know a password before the KDC hands you anything encrypted with it. If an account has "Do not require Kerberos preauthentication" set — a real, sometimes-legitimate setting for compatibility with older systems, but frequently just a misconfiguration — anyone can request that account's AS-REP with no credential at all, and it comes back encrypted with a hash of that account's password. Same offline-cracking endgame as Kerberoasting, but requiring nothing but a valid username, not a password:

GetNPUsers.py DOMAIN/ -usersfile users.txt -no-pass -dc-ip 10.10.10.5

Worth enumerating for this specifically rather than assuming it only matters if you already have a credential — an AS-REP-roastable account can be a domain's actual initial foothold.

Pass-the-hash and pass-the-ticket

Windows never needs your plaintext password for NTLM authentication — only the NTLM hash. Once secretsdump.py or NetExec hands you a local admin's NTLM hash, you can authenticate as that account anywhere the hash is valid, without ever knowing or cracking the underlying password:

psexec.py -hashes :NTHASH DOMAIN/administrator@10.10.10.15

If the target only trusts Kerberos, "overpass-the-hash" gets you there anyway — use the NTLM hash to request a real Kerberos TGT (getTGT.py -hashes :NTHASH DOMAIN/user), then authenticate with that ticket instead of a password or a raw hash. And once you have a ticket — captured, forged, or requested legitimately — pass-the-ticket lets you present it directly (export KRB5CCNAME=ticket.ccache) rather than re-authenticating from scratch. The pattern across all three: Windows and Kerberos both accept several different forms of "proof of identity," and any one of them is enough once you have it.

DCSync

The endgame. Domain controllers replicate directory data — including password hashes — between each other constantly, using a small set of replication permissions (DS-Replication-Get-Changes and DS-Replication-Get-Changes-All) that most domains grant to Domain Admins and a handful of built-in accounts, and sometimes, through ACL misconfiguration, to accounts that were never meant to have them. If an account you control holds those rights, you can ask any domain controller to "replicate" the entire domain's credential database to you directly — no code execution on the DC required, because you're using AD's own replication protocol exactly as designed:

secretsdump.py DOMAIN/user:password@10.10.10.5 -just-dc

This is why ACL misconfigurations matter as much as password weaknesses in AD — a single overly generous permission grant can hand out DCSync rights years after whoever configured it forgot it was there.

Common mistakes

Treating enumeration as a one-time step. Every new credential can see a different slice of the domain. Re-run enumeration after every meaningful escalation, not just at the start.
Kerberoasting or AS-REP roasting every account and cracking blindly. Prioritize accounts whose names suggest service or legacy status (svc_, sql_, old naming conventions) — they crack at a much higher rate than the domain average.
Forgetting DCSync rights don't require Domain Admin membership. ACL abuse can grant replication rights to an account nobody would flag as privileged by group membership alone — this is exactly what BloodHound's path-finding is built to surface.
Skipping local privilege escalation because you already have a domain foothold. A local admin credential on one workstation via the Windows privesc checklist is often the fastest route to the next domain credential — the two phases feed each other constantly, not just once.

Next step

Confirm local access on any host you land on with the Windows privesc checklist — a local admin credential is frequently what starts this whole chain. See NetExec, BloodHound, secretsdump.py, and Impacket for the specific commands behind every step here. Once you're holding domain admin-equivalent access, see Maintaining Access for the discipline of tracking — and being able to revert — exactly what that access lets you do.