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:nocase. 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
- Enumerate every trust. Categorise by type, direction, transitivity, SID Filtering state, Selective Authentication state.
- 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.
- Treat the forest as the security boundary, not the domain. Tier-0 hardening applies to every DA in every child domain.
- Run BloodHound monthly against the entire forest + trusted forests. Track new edges.
- 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:noexceptions. - 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.
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.