The Active Directory Kill Chain: From Foothold to NTDS.dit

Most Active Directory compromises are not one clever exploit — they are a chain of small, individually unremarkable steps that add up to total domain control. This post walks the Active Directory kill chain the way an authorized penetration test does: from an unauthenticated foothold on the internal network through enumeration, privilege escalation, and lateral movement, ending at the point where every password in the domain falls out of NTDS.dit. Each stage is paired with the detection and the fix, because the point of running the chain is to break it.

Authorized use only. Everything here belongs inside a signed statement of work with explicit scope, or in a lab you own. The techniques are loud and high-impact; running them against a domain you do not control is unauthorized access and is prosecutable.

Key Takeaways

• The Active Directory kill chain is a path, not a single exploit — foothold, enumeration, escalation, lateral movement, and domain dominance — and every hop is a place to break it.
• Initial footholds usually come from network poisoning, NTLM relay, or password spraying rather than a software vulnerability.
• BloodHound turns enumeration into a graph that shows the literal shortest path to Domain Admins, which is why defenders should run it too.
• Kerberoasting, AS-REP roasting, ADCS abuse, and ACL abuse are the common escalation routes that lead to replication rights.
• The payoff stage — DCSync or an NTDS.dit dump — is detectable through Event ID 4662 replication access, and its blast radius is limited by admin tiering and long passwords.

Environment

• A lab Active Directory domain on Windows Server 2022 with a couple of member servers and workstations — GOAD (Game of Active Directory) is the standard vulnerable build for this.
• A Linux testing host with Impacket, NetExec (the maintained successor to CrackMapExec), Responder, BloodHound, and Certipy.
• Hashcat 6.2 for offline cracking of captured and roasted hashes.
• A SIEM or at least centralized Windows event collection, so each stage can be observed from the defender's side.

The Problem

Active Directory is built to make authentication frictionless across an entire organization, and that same design is what an attacker rides. Default protocols trust the local network, credentials get cached on every machine a user touches, and the relationships between accounts, groups, and permissions form an enormous graph that almost nobody fully maps. A penetration tester does not need a zero-day; they need one weak password and the patience to follow the graph.

The honest reason to study the full chain rather than a single technique is that defenders tend to fixate on the last step. People harden the domain controller and forget that the attacker spent three days getting there through a service account, a relayed hash, and a cached admin token. If you only watch the finale, you miss every chance to stop the show earlier. So this walkthrough follows the whole path and marks the exits.

The Solution

Stage 1 — Foothold without a vulnerability

The first domain credential rarely comes from an exploit. On most internal networks it comes from broken default protocols. Responder answers LLMNR, NBT-NS, and mDNS name-resolution requests that Windows broadcasts when DNS fails, capturing NetNTLMv2 hashes from any host that tries to reach a mistyped or stale name. Those crack offline with hashcat -m 5600, or — better for the attacker — get relayed straight to another host with ntlmrelayx.py when SMB signing is not enforced. The other reliable entry is a quiet password spray:

nxc smb 10.0.0.0/24 -u users.txt -p 'Spring2026!' --continue-on-success

Detect and fix: disable LLMNR and NBT-NS via Group Policy, enforce SMB signing everywhere (which kills the relay), and watch for bursts of Event ID 4625 failed logons across many accounts from one source — the password-spray signature covered in Entra ID password spray detection, which applies on-premises just as much.

Stage 2 — Map the domain with BloodHound

One low-privilege account is enough to read most of Active Directory. SharpHound or bloodhound-python collects users, groups, ACLs, sessions, trusts, and delegations, and BloodHound renders it as a graph you can query. The decisive query is "shortest path to Domain Admins," but the genuinely useful ones for a tester are "who has DCSync rights," "where are Domain Admins logged on," and "which accounts are kerberoastable." This is the step that converts guesswork into a route.

bloodhound-python -d corp.local -u jsmith -p 'Spring2026!' -c All -ns 10.0.0.10

Detect and fix: SharpHound collection generates a large, fast burst of LDAP and SMB queries from a single workstation — anomalous LDAP volume is a real signal if you are collecting it. The durable fix is to run BloodHound yourself on a schedule and remediate the paths it finds, especially the unexpected ACL edges, before an attacker enumerates them.

Stage 3 — Escalate toward replication rights

With the graph in hand, escalation follows whatever edge is cheapest. The recurring ones:

• Kerberoasting — request TGS tickets for service accounts (GetUserSPNs.py -request) and crack them offline with hashcat -m 13100. Service accounts are frequently over-privileged with stale passwords, which is exactly why detecting the request matters; see Detecting Kerberoasting with Windows Event ID 4769.
• AS-REP roasting — for accounts with Kerberos pre-authentication disabled, crack the returned material with hashcat -m 18200.
• ADCS abuse — misconfigured certificate templates (the ESC1 through ESC8 family) let a low-priv user enroll a certificate as a privileged account. Certipy has made this one of the most common domain-takeover routes in current testing.
• ACL abuse — a GenericAll, WriteDACL, or WriteOwner edge on a group or the domain object lets you grant yourself membership or replication rights directly.

Detect and fix: the common thread is weak service-account passwords and loose delegation. Move services to group-managed service accounts (gMSA) with long random passwords, enforce a 25+ character minimum on any account with a SPN, audit certificate templates with Certipy's own audit mode, and review who holds dangerous ACLs on high-value objects.

Stage 4 — Lateral movement and credential harvesting

Escalation rarely jumps straight to Domain Admin; it usually means becoming local admin somewhere a more privileged user has a session. From there the attacker harvests credentials and reuses them. Dumping LSASS on a member server yields cached NTLM hashes and Kerberos tickets, and those move laterally without ever being cracked:

# Pass-the-hash with a harvested NT hash, no plaintext required
nxc smb fileserver01 -u administrator -H  -x "whoami"

This is the stage where the LSASS hardening story matters: Credential Guard and LSA protection make the memory dump fail, which I cover in the post on hardening LSASS with Credential Guard and LSA protection. The goal of all this movement is to land on, or capture a token from, an account that can talk to the domain controller as a replication partner.

Detect and fix: watch for Event ID 4624 type 3 logons and 4648 explicit-credential use that map to lateral patterns, deploy a tuned Sysmon configuration to catch LSASS process access, and rotate unique local administrator passwords with Windows LAPS so a single cracked local-admin hash does not unlock the whole fleet. Admin tiering — never using Domain Admin to log on to ordinary endpoints — is what removes the cached privileged token the attacker is hunting for.

Stage 5 — Domain dominance and the NTDS.dit dump

The chain ends where domain dominance begins. With replication rights, a DCSync request pulls every NT hash in the domain without touching the controller's disk:

secretsdump.py 'corp.local/da_user@dc01' -just-dc

Alternatively, on a shell on the DC, an Install-From-Media snapshot via ntdsutil exports ntds.dit and the SYSTEM hive for offline extraction. Either way the output is the full set of unsalted NT hashes, which crack quickly with hashcat -m 1000 — the mechanics, and why the missing salt makes them crack so fast, are the subject of the companion post on dumping NTDS.dit and cracking Active Directory password hashes. The krbtgt hash in that dump also enables a Golden Ticket for long-term persistence.

Every account's NT hash pulled out of the domain's ntds.dit. There is no salt, so identical passwords produce identical hashes and the whole domain becomes a single offline cracking job.

A weak seasonal password recovered from its NT hash in seconds, while a long random one in the same run does not fall. Length, not complexity, is what survives an unsalted, fast hash.

Detect and fix: audit Directory Service Access and alert on Event ID 4662 referencing the replication GUID 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2 from anything that is not a domain controller computer account. Limit who holds Get-Changes and Get-Changes-All, keep the Domain Admin tier tiny and clean, and put privileged accounts in the Protected Users group. Microsoft's Defender for Identity credential-access alerts map directly onto this stage. Worth knowing: on a current domain controller Defender already blocks the ntdsutil IFM route on its own, before you engineer any detection of your own.

On a current domain controller, Defender blocks the ntdsutil IFM dump outright, flagged as Trojan:Win32/SuspShadowAccess.DA — a useful backstop, though an attacker who has reached this stage can disable it first.

Frequently Asked Questions

What is the Active Directory kill chain?

It is the sequence of stages an attacker moves through to compromise an AD domain: gaining a foothold, enumerating the environment, escalating privileges, moving laterally, and finally achieving domain dominance. Framing it as a chain matters because each stage is an independent opportunity to detect and stop the intrusion, not just the final domain-controller step.

Why is BloodHound useful for defenders, not just attackers?

BloodHound maps the same attack paths whether you are attacking or defending. Running it yourself reveals the unexpected ACL edges, kerberoastable accounts, and shortest paths to Domain Admins that an attacker would find, so you can remediate them first. Defensive use is one of the highest-value AD hardening exercises available.

How do attackers get the first credential without an exploit?

Most internal footholds come from protocol abuse rather than software vulnerabilities — poisoning LLMNR/NBT-NS with Responder to capture NetNTLMv2 hashes, relaying those hashes where SMB signing is off, or spraying a common password across the domain. Disabling legacy name resolution and enforcing SMB signing removes the easiest of these entries.

Where in the chain should I focus detection?

Everywhere, but the highest-value single signal is the Event ID 4662 replication access at the domain-dominance stage, because it catches DCSync regardless of how the attacker reached that point. Pair it with password-spray detection at the foothold stage and Kerberoasting detection at the escalation stage for layered coverage.

Is it safe to run these tools in production during a test?

Only within an agreed scope and rules of engagement. DCSync, LSASS dumping, and Golden Tickets are high-impact and noisy; coordinate timing with the blue team so their response is part of the test rather than an incident, and practice the full chain in a lab such as GOAD before ever touching a client environment.

Conclusion

The Active Directory kill chain looks intimidating as a whole, but its power is also its weakness: it is a chain. An attacker has to clear every link — foothold, map, escalate, move, dominate — while a defender only has to break one convincingly. The reason penetration testers walk the entire path is to show the client which links are weakest, and the deliverable is never "we dumped the hashes." It is the graph showing the exact route, with a concrete fix at every hop.

Work the chain backward when you harden: protect the domain controllers and replication rights, then tier admin so cached tokens are not lying around, then fix the service accounts and ACLs that grant escalation, then close the protocols that hand out the first foothold. Do that and the next test stalls somewhere in the middle of the graph — which is exactly where you want it to stall.

Related Posts

• Detecting Kerberoasting with Windows Event ID 4769 — the detection for the most common escalation link in the chain.
• Managing Windows LAPS with Microsoft Intune — breaks the local-admin password reuse that powers lateral movement.
• Essential Windows Event IDs for Security Monitoring — the events that surface each stage of the chain.

Editorial note: posts on this blog are drafted with AI assistance and then reviewed, edited, and tested against a real environment before publishing. Commands, output, and screenshots come from systems I actually ran the work on.