The Active Directory Kill Chain: How Attackers Move from Foothold to Domain Admin

Every Active Directory compromise follows a predictable pattern. The tools change, the specific techniques evolve, but the fundamental kill chain remains the same. As a penetration tester, I walk this path on every engagement. As a defender, understanding each stage of this chain gives you the opportunity to detect and disrupt the attack before it reaches its conclusion.

I want to walk you through the full AD kill chain as I experience it during a typical internal penetration test, and at each stage, explain exactly what defensive controls would have stopped or detected me.

Stage 1: Initial Access and Reconnaissance

The kill chain begins when I connect to the internal network. My first actions are passive: I listen for broadcast traffic using Responder in analyze mode, I identify the domain name and domain controller IPs from DNS and DHCP responses, and I map the network topology from ARP traffic. Within minutes, I have a picture of the environment without sending a single malicious packet.

With even a low-privileged domain account -- often obtained through LLMNR/NBT-NS poisoning or from a compromised workstation -- I begin active reconnaissance. I query LDAP for users, groups, computers, GPOs, trusts, and organizational units. I run BloodHound's SharpHound collector to map every relationship and permission in the domain. This gives me a complete graph of attack paths from my current position to Domain Admin.

Defensive controls: Disable LLMNR and NBT-NS via GPO to prevent name resolution poisoning. Deploy network access control (802.1X) to prevent unauthorized devices from connecting. Monitor for unusual LDAP query patterns -- SharpHound generates a distinctive burst of LDAP queries that can be detected by volume and pattern. Implement canary accounts that generate alerts when queried by BloodHound.

Stage 2: Credential Harvesting

With domain reconnaissance complete, I target credentials. My primary techniques at this stage are Kerberoasting, NTLM relay, and password spraying. Kerberoasting lets me request service tickets and crack them offline. NTLM relay lets me capture and forward authentication. Password spraying lets me guess common passwords across many accounts.

I also check for AS-REP Roastable accounts, LAPS passwords readable by my current user, passwords stored in Group Policy Preferences (a legacy issue that still appears regularly), and credentials in SYSVOL scripts. Each of these techniques exploits a different misconfiguration, and most environments are vulnerable to at least two of them.

Defensive controls: Deploy gMSAs to eliminate Kerberoasting targets. Enforce SMB and LDAP signing to block relay attacks. Implement account lockout policies that are strict enough to limit spraying but not so aggressive that they enable denial of service. Remove passwords from GPP files and SYSVOL scripts. Monitor Event ID 4769 for RC4 ticket requests and Event ID 4625 for distributed authentication failures.

Stage 3: Lateral Movement

Once I have credentials, I move laterally across the environment. If I have local admin hashes, I use pass-the-hash to access other workstations and servers. If I have plaintext passwords or Kerberos tickets, I use standard tools like PsExec, WMI, or PowerShell remoting. My goal is to find machines where higher-privileged users have active sessions or cached credentials.

In environments without LAPS, lateral movement is trivial. One local admin hash lets me access every machine in the domain. Even with LAPS, if there is no tiered administration model, I search for machines where Domain Admins have logged in recently. Each hop gets me closer to a Tier 0 asset.

Defensive controls: Deploy LAPS to make every local admin password unique. Implement tiered administration to prevent high-privilege credentials from appearing on low-tier systems. Enable Windows Credential Guard to protect NTLM hashes and Kerberos tickets in memory. Add privileged accounts to the Protected Users group to prevent NTLM hash caching. Monitor for lateral movement patterns: Event ID 4624 logon type 3 from unusual source IPs, PsExec service installations (Event ID 7045), and WMI process creation events.

Stage 4: Privilege Escalation

Privilege escalation in AD usually means getting from a regular domain user to Domain Admin. The paths I use most frequently include compromising an over-privileged service account through Kerberoasting, finding cached Domain Admin credentials on a compromised server, exploiting ACL misconfigurations that give me write access to privileged objects, and abusing Kerberos delegation to impersonate privileged users.

BloodHound is invaluable here. It reveals escalation paths that no manual analysis would find: nested group memberships that chain together, GenericAll permissions on user objects that let me reset passwords, WriteDacl on groups that let me add myself, and ownership of GPOs that let me push malicious policies.

Defensive controls: Run BloodHound for defense proactively to find and eliminate escalation paths before attackers do. Audit ACLs on all privileged objects (Domain Admins group, domain controllers, AdminSDHolder container). Remove unnecessary delegation configurations. Apply the principle of least privilege rigorously -- service accounts should have only the specific permissions they need, not Domain Admin rights.

Stage 5: Domain Dominance

Once I have Domain Admin access, I establish persistence and demonstrate full impact. I perform a DCSync attack to replicate all password hashes from the domain. I can create Golden Tickets for persistent access. I access the NTDS.dit database on domain controllers. At this point, every account in the domain is compromised, and recovery requires assuming every credential has been stolen.

Defensive controls: Monitor for DCSync attacks by watching Event ID 4662 for replication requests from non-DC sources. Alert on new members added to Domain Admins and other Tier 0 groups (Event ID 4728, 4732, 4756). Rotate the KRBTGT password every 180 days to limit Golden Ticket lifetimes. Maintain offline backups of Active Directory that cannot be modified by a compromised Domain Admin.

Breaking the Chain

The kill chain is only as strong as its weakest link, but from the defender's perspective, you should aim to break it at every stage. Defense in depth means that even if one control fails, the next one catches the attacker. No single control stops everything, but the combination of proper signing enforcement, gMSAs, LAPS, tiered administration, and active monitoring makes each step dramatically harder.

I encourage every organization to map their own kill chain. Start from an assumed compromise of a single workstation and trace the paths an attacker could take to Domain Admin. Use BloodHound to identify those paths, then systematically close them. The goal is not to make compromise impossible but to make it slow enough and noisy enough that your detection systems catch it before it reaches domain dominance.