Forests, Trees, and Domains: Who Trusts Whom and Why?

Golden Rule of Active Directory Trusts

In any trust relationship between Domain A and Domain B:

• The Trusting Domain is the one hosting the resources.
• The Trusted Domain is the one hosting the users (accounts).

Authentication and access flow in the direction OPPOSITE to the trust direction arrow.

Concept

Inside an Active Directory forest, trusts are not manually provisioned one by one: they are automatically established, two-way, and transitive upon the addition of any child domain or new domain tree:

1. Parent-Child Trust: Automatically provisioned between a parent domain and its immediate child domain.
2. Tree-Root Trust: Automatically established between the forest root domain and the root domain of a new domain tree within the same forest.
3. Automatic Transitivity: If Domain A trusts Domain B, and Domain B trusts Domain C, Domain A implicitly and transitively trusts Domain C.

---

Why It Matters in DFIR

Trust architectures determine how threat actors pivot between enterprise domains:

• Implicit Lateral Movement Paths: Attackers do not need to establish new trusts. Once a foothold is secured in an auxiliary domain, network RPC services (SMB 445, Kerberos 88, LDAP 389) allow querying and traversing DCs across domains.
• Directional Trust Confusion: Investigators frequently invert trust directions during triage. If Finance.corp trusts Plant.corp, users in Plant.corp can authenticate to Finance.corp assets, NOT the reverse!
• Universal Privileged Groups: The Enterprise Admins group physically exists only in the forest root domain, but it is automatically added by default to the local Administrators (RID 544) group of every domain across the entire forest.

---

How It Works

Intra-Forest Trust Flow Topology

                       ┌────────────────────────────┐
                       │     Forest Root Domain     │
                       │        corp.local          │
                       │ (Contains Enterprise Adm)  │
                       └─────────────┬──────────────┘
                                     │
           ▲                         │ Two-way               ▲
           │ Authentication Flow     │ Transitive            │ Authentication Flow
           │                         ▼                       │
    ┌──────┴──────────────┐                   ┌──────────────┴──────┐
    │     Child Domain    │                   │     Child Domain    │
    │   emea.corp.local   │◄─────────────────►│   apac.corp.local   │
    └─────────────────────┘    Transitivity   └─────────────────────┘
                                 Implicit

1. Intra-Forest Transitivity: A user in apac.corp.local accessing a file share in emea.corp.local requires no direct point-to-point trust: the APAC DC issues a referral to the root DC, which issues a referral to the EMEA DC.
2. Inter-Domain Trust Accounts: Each trust is represented in ntds.dit by an internal machine account ending with $ (e.g., EMEA$ on the root DC, and CORP$ on the EMEA DC). Its password is synchronized between DCs of both domains and rotated automatically every 30 days.

---

What Is Possible

• Full Forest Traversal via Inter-Realm Kerberos Tickets: Legitimate users and adversaries can request cross-domain TGS tickets for any resource across the forest.
• Forest-Wide Domination via Enterprise Admins: Enterprise Admins possess administrative authority over all domain controllers and member servers across all domains in the forest.
• Unrestricted SID Injection Intra-Forest: By default, intra-forest trusts do not filter forest-internal SIDs present in the sIDHistory attribute.

---

What Is Not Possible

• Disabling Transitivity Within a Forest: You cannot selectively disable transitivity between domains of the same forest without breaking forest integrity.
• Creating an Enterprise Admins Group in a Child Domain: This group only exists in the root domain (S-1-5-21-ROOT-519). Child domains only possess Domain Admins.
• Automatic Resource Access Without DACLs: Trusts enable authentication. Access to specific shares or files still requires DACL permissions or group nesting.

---

Common DFIR Confusions

Frequent Confusion	Verifiable Forensic Reality
”Domain A trusts Domain B, therefore Domain A controls Domain B.”	Classic inversion: Domain A trusting Domain B means Domain B users can access Domain A resources.
”Parent domain accounts can read all data in child domains by default.”	Only groups explicitly nested (like Enterprise Admins) have rights. Standard parent users have zero access without DACL entries.
”External trusts behave just like forest trusts.”	External trusts are non-transitive by default and strictly enforce SID Filtering.

---

Concrete Forensic Example

An adversary compromises a deployment server in a development child domain (dev.corp.local):

1. Target goal: sensitive source code in prod.corp.local.
2. The attacker uses BloodHound to map authentication paths: dev.corp.local $ ightarrow$ corp.local (root) $ ightarrow$ prod.corp.local.
3. They discover that a development security group (DEV-Ops) was nested into the local Administrators group of a build server in prod.corp.local.
4. The attacker impersonates a member of DEV-Ops and traverses from DEV to PROD using Kerberos referrals without needing root Domain Admin credentials.

---

Key Forensic Artefacts

1. Trusted Domain Objects (TDO):
   • Objects of class trustedDomain stored in CN=System,DC=domain,DC=local.
   • Attributes: trustDirection (1=Inbound, 2=Outbound, 3=Bidirectional), trustType (2=Upx / Active Directory), trustAttributes (TRUST_ATTRIBUTE_WITHIN_FOREST = 0x20).
2. Security Event Logs (Source & Target DCs):
   • Event ID 4769: TGS requests for the inter-domain trust account (e.g., krbtgt/CORP.LOCAL).
   • Event ID 4624 (Logon Type 3): On target servers, displaying the source domain in TargetDomainName.

---

Investigation Methods

1. List All Trust Relationships for the Subject Domain: Execute nltest /domain_trusts /v or PowerShell Get-ADTrust -Filter *.
2. Identify Inter-Domain Trust Accounts: Inspect inter-domain trust computer accounts (Get-ADComputer -Filter 'OperatingSystem -like "*Trust*"').
3. Audit Cross-Domain Group Nesting: Identify global groups from external or child domains added to local Domain Local groups.

---

Investigative Tooling

• Nltest & Netdom:

  nltest /domain_trusts /v
  netdom trust <LocalDomain> /Domain:<RemoteDomain> /verify

• PowerShell AD Module:

  Get-ADTrust -Filter * | Select-Object Name, Direction, TrustType, IntraForest, SIDFilteringForestAware

---

Key Takeaways

• Trust direction is the opposite of access direction: Resource domain $ ightarrow$ trusts $ ightarrow$ Account domain.
• Intra-forest trusts are two-way and transitive by default.
• Trusts provide authentication pathways; authorization is determined by local DACLs and group memberships.

---

References & Further Reading

• Microsoft Learn: How Domain and Forest Trusts Work
• Card 11 — Multi-Domain, Trees, and Forests in Active Directory
• Card 13 — Active Directory Trust Fundamentals
• Card 15 — Trust Direction and Transitivity: Traps and Realities