Module 20 · AD Trust Relationships Deep Dive — Forest, External, Shortcut

Manish Garg
Manish Garg Associate of (ISC)² · RingSafe
May 13, 2026
5 min read
Read as
100% Free

No signup. No paywall. No catch. One of our 10 most-requested practitioner modules — published in full so anyone can learn for free. We earn through consulting, not by gating knowledge.

See all 10 free modules →

Why this module exists. AD trusts are the plumbing of federation between domains and forests — and almost every late-stage AD compromise involves moving across a trust the defender did not know existed or did not know the security properties of. This module is the practitioner-level taxonomy of trust types (parent-child, tree-root, shortcut, external, forest, realm), their default security properties, and the modern attack patterns that abuse each.

Why this module exists. AD has six distinct trust types. Each has different transitivity, SID Filtering defaults, Kerberos behaviour, and attacker-reachable abuse pattern. The median Indian-bank AD environment we audit has at least one trust whose properties the owning team cannot explain. This module is the missing reference.

The six trust types — at a glance

Type When created Transitive? SID Filter default
Parent-child Automatic when child domain added to forest Yes OFF
Tree-root Automatic when new tree added to existing forest Yes OFF
Shortcut Manual; optimises auth path in large forests Yes OFF
External Manual; domain ↔ domain across forests No ON
Forest Manual; forest ↔ forest, all domains Yes (within forest) ON
Realm Manual; AD ↔ non-AD Kerberos realm (MIT/Heimdal) Configurable N/A

Parent-child and tree-root — the unfiltered intra-forest danger

Both are created automatically when you add a child domain or a new tree. They are transitive (so Kerberos referrals work across multiple hops), and SID Filtering is OFF by default. This is the canonical attack surface for SID History injection (see Module 19): Domain Admin in any child → Enterprise Admin of the forest via a Golden Ticket with the parent’s privileged SID injected.

The “if you have DA somewhere, you have EA everywhere” rule is a consequence of these unfiltered intra-forest trusts. The defender has two answers: either consolidate domains so there is only one (the empty-root or single-domain forest model), or treat every child domain’s DAs as Tier 0 of the whole forest. The second answer is operationally simpler; the first is structurally cleaner.

Shortcut trusts — the forgotten attack surface

Shortcut trusts exist to bypass the referral chain in large forests. domainA.corp talking to domainE.corp via the forest root normally takes 4 referrals; a shortcut trust between A and E lets it happen in 1. They are intra-forest, transitive, and SID-Filtering-off.

Attackers love them because they are usually undocumented. The original AD admin set them up for performance reasons in 2014; nobody remembered they existed. A modern BloodHound scan exposes them as edges; the defender’s own asset map does not. Hunt for shortcut trusts before an attacker enumerates them:

# PowerShell on a DC
nltest /domain_trusts /all_trusts /v

# Look for entries with "TrustAttributes" containing TRUST_ATTRIBUTE_WITHIN_FOREST
# AND a direct (non-root) connection — those are shortcuts.

External trusts — domain-to-domain, SID-filtered by default

External trusts connect a single domain in one forest to a single domain in another forest. They are non-transitive (auth does not propagate to other domains in either forest), and SID Filtering is ON by default. This is the safer trust type — but with two failure modes:

  • SID Filtering disabled for legacy compatibility. The classic netdom trust /quarantine:no case. Indian banks integrating with 2008-era partner forests carry this configuration.
  • Trust direction. An outbound trust where you trust them is the higher-risk direction. The risk is in what you let in, not what you let them see.

Forest trusts — the most-used inter-forest plumbing

Forest trusts connect two entire forests. Transitive within each forest (so any domain in forest A can auth to any domain in forest B). SID Filtering is ON. They are the standard for M&A integration, vendor integration, and the “dev forest ↔ prod forest” segregation pattern.

The Trust Properties dialog has a Selective Authentication tab. Enabling Selective Auth means principals in the trusted forest can authenticate only to specific resources you explicitly grant. Without it, every authenticated principal across the trust can list shares, query AD via LDAP, and (depending on ACLs) read SYSVOL. For an inter-forest trust to a partner you do not fully trust, Selective Authentication should be on by default.

Realm trusts — AD to MIT/Heimdal Kerberos

Realm trusts let an AD forest accept Kerberos tickets from a Unix/Linux Kerberos realm (or vice versa). Less common but appear in mixed-OS environments — Indian financial-services with mainframe Kerberos integration, ISP-class infrastructure with MIT Kerberos identity. They have unique attack patterns because the foreign KDC’s signing key is not under your control. If the partner realm is compromised, attackers can mint tickets your AD will trust.

Attack pattern: enumerating trusts and pivoting

The first thing an attacker with a foothold does is enumerate trusts. The tooling:

# PowerView (well-known)
Get-DomainTrust
Get-DomainTrustMapping        # recursive enumeration across reachable trusts

# Bare LDAP (works from any domain user)
Get-ADTrust -Filter *

# BloodHound CE collects all trust data automatically in its Domain edges.
# After import, run the "Find Shortest Path from Domain Users to Domain Admins"
# query across the entire trust topology — surfaces cross-trust paths
# in seconds.

The most common pivot pattern: foothold in a low-trust child → enumerate trusts → identify shortcut to a higher-trust domain → SID History injection or direct Kerberos referral → Tier 0 of the parent forest.

Detection

  • Maintain a known good trust inventory. Any new entry — even legitimate — should require a documented change. Diff weekly.
  • Event 4716 on a DC: “Trusted domain information was modified.” High-signal — trust modifications are rare in steady-state estates.
  • Event 4768 on a DC with cross-realm referral: the requesting principal is from a foreign domain. Volume baseline lets you spot anomaly.
  • BloodHound regular runs find newly-introduced shortcut trusts before users do.

Defender’s audit checklist

  1. Enumerate every trust. Categorise by type, direction, transitivity, SID Filtering state, Selective Authentication state.
  2. For every trust where SID Filtering is OFF or Selective Auth is off, document the business reason. Trust without a documented business reason should be candidate for removal.
  3. Treat the forest as the security boundary, not the domain. Tier-0 hardening applies to every DA in every child domain.
  4. Run BloodHound monthly against the entire forest + trusted forests. Track new edges.
  5. For external partner trusts, prefer Selective Authentication over open access. The operational cost is meeting requests; the security benefit is enormous.

Key takeaways

  • Six trust types: parent-child, tree-root, shortcut, external, forest, realm.
  • Intra-forest trusts (parent-child, tree-root, shortcut) are SID-Filtering-off by default — the forest is the security boundary.
  • External and forest trusts are SID-Filtering-on but check for legacy netdom /quarantine:no exceptions.
  • Shortcut trusts are the most-forgotten attack surface — BloodHound is the simplest way to find them.
  • Selective Authentication is the cheap big win for any inter-forest partner trust.
Need a real pentest?

Get a VAPT scoping call

Senior practitioner-led VAPT — not a checklist run by juniors. CVSS-scored findings, free retest, attestation letter. India's SMBs and SaaS teams.

Book VAPT scoping call Replies in 4 working hrs · India-only · Senior consultants