5 Active Directory Attack Paths We Find in Every Engagement

Why Active Directory Is Always the Target

Active Directory (AD) is the backbone of enterprise identity. It controls who can log in, what they can access, and how services authenticate. That centrality makes it the highest-value target in almost every internal penetration test.

The attack paths described below aren't theoretical - they're patterns that surface repeatedly in real-world engagements. Each section covers how the attack works, what it looks like from the defender's perspective, and concrete steps to remediate.

1. Kerberoasting

The Attack

Kerberoasting exploits a design feature of Kerberos authentication. Any domain user can request a Ticket Granting Service (TGS) ticket for any service account that has a Service Principal Name (SPN) set. The ticket is encrypted with the service account's password hash - meaning an attacker can request it and crack it offline without triggering account lockout.

# Using Rubeus from a domain-joined machine
	Rubeus.exe kerberoast /outfile:tgs_tickets.kirbi

	# Or with Impacket from Linux
	impacket-GetUserSPNs -request -dc-ip 10.10.10.1 CORP.LOCAL/jsmith:Password1

The attack works because:

• No special privileges are required - any authenticated domain user can request TGS tickets
• The cracking happens offline - no failed login attempts, no lockout triggers
• Service accounts often have weak or old passwords that haven't been rotated in years

What Defenders See

In Event Logs, Kerberoasting generates Event ID 4769 (Kerberos Service Ticket Operations) with an encryption type of 0x17 (RC4-HMAC). Legitimate Kerberos traffic typically uses AES encryption (0x12 or 0x11). A spike in RC4 ticket requests from a single user is a strong signal.

Event ID: 4769
	Service Name: sqlservice
	Client Address: 10.10.10.50
	Ticket Encryption Type: 0x17   ← RC4 = suspicious

Remediation

2. DCSync

The Attack

DCSync abuses the directory replication protocol that domain controllers use to synchronize data. An attacker with Replicating Directory Changes and Replicating Directory Changes All permissions can impersonate a domain controller and request password hashes for any account - including krbtgt (which enables Golden Ticket attacks).

# Using Mimikatz
	lsadump::dcsync /domain:corp.local /user:krbtgt

	# Using Impacket
	impacket-secretsdump -just-dc corp.local/admin:P@ssw0rd@10.10.10.1

This is often the pivot point from "domain admin" to "complete and permanent domain compromise." Once an attacker has the krbtgt hash, they can forge Kerberos tickets for any user indefinitely - even after passwords are changed.

What Defenders See

DCSync generates Event ID 4662 (An operation was performed on an object) with specific access rights GUIDs:

Event ID: 4662
	Operation Type: Object Access
	Access Mask: 0x100
	Properties: {1131f6aa-9c07-11d1-f79f-00c04fc2dcd2}   ← Replicating Directory Changes
	             {1131f6ad-9c07-11d1-f79f-00c04fc2dcd2}   ← Replicating Directory Changes All
	Subject: NOT a domain controller

The key signal: replication requests coming from a machine that is not a domain controller.

Remediation

3. Unconstrained Delegation

The Attack

When a server is configured for unconstrained delegation, it can impersonate any user who authenticates to it. Technically, the server stores a copy of the user's TGT (Ticket Granting Ticket) in memory. An attacker who compromises a server with unconstrained delegation can extract these cached TGTs and use them to authenticate as those users - including domain admins.

# Find servers with unconstrained delegation
	Get-ADComputer -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation

	# Extract cached TGTs with Rubeus
	Rubeus.exe triage
	Rubeus.exe dump /luid:0x3e7 /nowrap

The attack becomes devastating when combined with the Printer Bug (SpoolService): an attacker can force a domain controller to authenticate to the compromised server, caching the DC's machine account TGT - effectively granting domain compromise.

# Force DC to authenticate via Printer Bug
	SpoolSample.exe DC01.corp.local COMPROMISED-SRV.corp.local

What Defenders See

• Event ID 4624 (logon) on the delegated server with logon type 3 from unexpected high-value accounts
• TGT requests from non-standard hosts visible in DC logs
• Unusual LDAP queries enumerating the TrustedForDelegation attribute

Remediation

4. NTLM Relay

The Attack

NTLM relay captures an authentication attempt from one machine and replays it against a different target. The attacker doesn't crack the password - they relay the live authentication in real time. This works because NTLM doesn't bind authentication to a specific service or server.

Common coercion methods to force authentication:

• LLMNR/NBT-NS poisoning - respond to multicast name queries on the local network
• MITM6 - poison IPv6 DNS to redirect WPAD/proxy authentication
• PetitPotam - abuse the EFS RPC to force machine account authentication

# Capture and relay with Impacket
	impacket-ntlmrelayx -tf targets.txt -smb2support

	# Poison LLMNR/NBT-NS with Responder
	responder -I eth0 -rdwv

If relayed to a machine where the victim has local admin rights, the attacker gets code execution. If relayed to LDAP on a domain controller, they can modify AD objects - including adding themselves to privileged groups.

What Defenders See

• Event ID 4624 logon type 3 from unexpected source IPs
• NTLM authentication events (Event ID 4776) where the workstation name doesn't match the source IP
• Multicast traffic on ports 5355 (LLMNR) and 137 (NBT-NS)

Remediation

5. Credential Spraying

The Attack

Credential spraying is the inverse of brute-forcing: instead of trying many passwords against one account, the attacker tries one password against many accounts. This avoids triggering account lockout (which typically fires after 3-5 failed attempts per account).

# Using Spray with a common password
	spray.sh -smb 10.10.10.1 users.txt 'Summer2025!'

	# Using CrackMapExec
	crackmapexec smb 10.10.10.1 -u users.txt -p 'Summer2025!' --continue-on-success

The passwords tested are predictable: Season+Year!, CompanyName1!, Welcome1, Password1. Organizations with weak password policies and no MFA are vulnerable.

A single valid credential is often all an attacker needs to begin Kerberoasting, enumerating shares, or accessing internal applications.

What Defenders See

• Event ID 4771 (Kerberos Pre-Authentication Failed) across many accounts from a small number of source IPs
• Event ID 4776 (NTLM credential validation) with failure codes
• A pattern of exactly N-1 failures per account (just below lockout threshold)

# Detection pattern: same source IP, many distinct accounts, same time window
	Source IP: 10.10.10.50
	Accounts attempted: 847
	Time window: 12 minutes
	Failures per account: 1-2 (below lockout threshold of 3)

Remediation

Building a Detection Strategy

These five attack paths share common detection patterns. A layered monitoring approach covers them all:

Tier 1 - Event Log Monitoring:

• 4769 with RC4 encryption (Kerberoasting)
• 4662 with replication GUIDs from non-DCs (DCSync)
• 4624/4776 anomalies (relay, spray, delegation abuse)
• 4771 correlation across accounts (spray)

Tier 2 - Network Detection:

• LLMNR/NBT-NS multicast traffic (relay setup)
• SMB traffic without signing (relay-capable)
• Unusual Kerberos ticket volumes from single hosts

Tier 3 - Configuration Auditing:

• Quarterly SPN and delegation review
• Password age audit on service accounts
• Replication permission audit
• GPO compliance for signing and LLMNR settings

Key Takeaways

1. All five attacks start with a normal domain user. The first credential is the hardest to get - after that, AD often gives attackers a path to domain admin.

2. Configuration weaknesses compound. Kerberoasting gives you a service account password. That account might have delegation rights. That delegation server might be relay-capable. Each weakness accelerates the next.

3. Detection beats prevention alone. You can't patch Kerberoasting - it's a protocol feature. But you can detect it with high confidence and respond before the attacker escalates.

4. Audit before you test. Run the PowerShell queries in this post against your own domain. If you find unconstrained delegation on non-DCs, exposed SPNs with old passwords, or missing SMB signing - fix them before a red team (or a real attacker) finds them first.

These attack paths come out of real engagements, not slides. More hands-on security walkthroughs on the BytesCop blog.