Skip to content
Hermes Codex

Active Directory Trust Fundamentals

Concept

Section titled “Concept”

A trust relationship is a logical and cryptographic agreement established between two Windows domains (or between an Active Directory forest and an external Kerberos realm).

It is anchored in two architectural pillars:

  1. The Trusted Domain Object (TDO): An Active Directory object of class trustedDomain stored in the domain partition (CN=System,DC=domain,DC=local), defining trust attributes (remote domain name, remote SID, direction, transitivity, security filtering flags).
  2. The Shared Secret (Trust Secret): A symmetric shared password (negotiated during trust establishment and periodically renewed by the PDC Emulator role) represented by an inter-domain trust computer account (Inter-Domain Trust Account).

Why It Matters in DFIR

Section titled “Why It Matters in DFIR”

In multi-domain intrusions:

  • Inter-Domain Lateral Movement Vector: An attacker who compromises a DC in Domain A can extract the shared trust secret and forge inter-realm Kerberos tickets to access assets in Domain B.
  • Stealthy Trust Key Persistence: If an attacker harvests the trust account password, resetting the local krbtgt account twice will not invalidate forged inter-realm tickets crafted with the trust key.
  • Cross-Domain Telemetry Interpretation: During cross-domain access, the source KDC issues a referral TGT rather than a direct TGS. Detecting these specific requests in Event ID 4769 logs is crucial for reconstructing attacker pivot paths.

How It Works

Section titled “How It Works”

The Trust Secret Mechanism

Section titled “The Trust Secret Mechanism”

When a two-way trust is established between Domain A (CORP) and Domain B (DEV):

  1. Two trust accounts are provisioned:
    • In Domain A: account DEV$ (type TRUST_ACCOUNT, UserAccountControl 0x800 / SERVER_TRUST_ACCOUNT).
    • In Domain B: account CORP$.
  2. Both accounts share an identical, randomly generated symmetric password.
  3. When user alice@DEV accesses cifs/fileserver.CORP:
    • Alice requests a TGS from her local KDC (DEV).
    • KDC DEV identifies that the target SPN resides in CORP.
    • KDC DEV encrypts an Inter-Realm TGT using the shared trust account key (CORP$).
    • Alice presents this Inter-Realm TGT to the KDC of CORP.
    • KDC CORP decrypts the ticket using its matching DEV$ account key, validates the identity, applies SID filtering rules, and issues the final TGS for fileserver.CORP.
[Alice@DEV]
    │ 1. Request TGS for fileserver.CORP
    ▼
[KDC DEV] ──── Encrypts Inter-Realm TGT with Trust Key (DEV$ / CORP$)
    │
    ▼ 2. Presents Inter-Realm TGT
[KDC CORP] ─── Decrypts with Trust Key, evaluates SIDs & issues TGS
    │
    ▼ 3. Presents TGS
[fileserver.CORP] ─── Grants access according to local DACL

What Is Possible

Section titled “What Is Possible”
  • Extracting Trust Secrets from NTDS: An adversary with Domain Admin privileges on a DC can use tools like secretsdump or mimikatz lsadump::trust to extract NTLM and AES keys of trust accounts.
  • Forging Inter-Realm Golden Tickets: With the trust key, an attacker can craft forged referral tickets injecting arbitrary SIDs (subject to SID Filtering policies).
  • Verifying Cryptographic Trust Health: Administrators and investigators can validate trust status and password synchronization via netdom trust <Domain> /verify.

What Is Not Possible

Section titled “What Is Not Possible”
  • Traversing Trusts Without Network Path to KDCs: Kerberos cross-realm ticket exchange requires direct network access from the client to both the local and remote KDCs.
  • Forging Inter-Domain Tickets Using Local krbtgt Keys: The local krbtgt hash only encrypts tickets within the local domain. Crossing the trust boundary strictly requires the inter-domain trust key.
  • Operating a Trust with Desynchronized Secrets: If trust passwords desynchronize, cross-domain authentication fails with STATUS_TRUST_FAILURE (0xC000018B).

Common DFIR Confusions

Section titled “Common DFIR Confusions”
Frequent ConfusionVerifiable Forensic Reality
”We reset the krbtgt account twice; all attacker tickets are revoked.”Double krbtgt rotation does not reset inter-domain trust keys. Adversaries possessing trust keys can still forge referral tickets.
”A trust relationship automatically grants administrative access.”A trust provides authentication pathways. Authorization requires explicit local DACL assignment.
”Trust communications generate separate VPN or tunnel traffic.”Trusts utilize standard Active Directory RPC and Kerberos ports (88, 389, 445, 135, 49152-65535).

Concrete Forensic Example

Section titled “Concrete Forensic Example”

In a banking network, a regional branch domain (branch.bank.local) connects to headquarters (hq.bank.local) via a two-way external trust.

  1. The attacker compromises a branch domain controller.
  2. They run mimikatz lsadump::trust /patch and harvest the RC4 key for the HQ$ trust account.
  3. The attacker crafts a forged inter-realm ticket using this key targeting a payment gateway in hq.bank.local.
  4. Detection Artefact: On the HQ DC, Event ID 4769 logs a TGS request for ServiceName: krbtgt/HQ.BANK.LOCAL presented by a foreign security principal validated via trust account BRANCH$.

Key Forensic Artefacts

Section titled “Key Forensic Artefacts”
  1. Active Directory Database (ntds.dit):
    • trustedDomain objects: attributes trustPartner, trustDirection, trustType, trustAttributes.
    • Trust computer accounts: sAMAccountType = 0x30000002 (TRUST_ACCOUNT).
  2. Windows Registry (LSA Secrets):
    • Keys under HKLM\SECURITY\Policy\Secrets\G\$\${GUID} holding cached trust passwords.
  3. Security Event Logs:
    • Event ID 4769 (DC): TGS requests with ServiceName corresponding to remote domain trust accounts.
    • Event ID 4624 (Target Server): Network logon (Type 3) with remote domain in TargetDomainName.
    • Event ID 4625 (DC): Logon failures showing 0xC000018B (STATUS_TRUST_FAILURE).

Investigation Methods

Section titled “Investigation Methods”
  1. Enumerate All Active Trust Objects: Run Get-ADTrust -Filter * | Format-List Name, Direction, TrustType, IntraForest, Target.
  2. Audit Modification Timestamps of TDO Objects: Examine whenChanged on trustedDomain objects in CN=System,DC=domain,DC=local to detect rogue trust establishment.
  3. Identify Trust Computer Accounts: Query computer accounts with SERVER_TRUST_ACCOUNT flag set in userAccountControl.

Investigative Tooling

Section titled “Investigative Tooling”
  • Nltest & Netdom:
    Terminal window
    nltest /domain_trusts
    netdom trust <LocalDomain> /Domain:<RemoteDomain> /verify
  • PowerView:
    Terminal window
    Get-DomainTrust
    Get-DomainTrustMapping
  • BloodHound: Visual exploration of cross-domain trust links and attack paths.

Key Takeaways

Section titled “Key Takeaways”
  • Active Directory trusts rely on a symmetric shared secret between domain authorities.
  • DC compromise enables extraction of trust keys and subsequent inter-realm ticket forging.
  • Incident recovery requires rotating all inter-domain trust account passwords alongside krbtgt.

References & Further Reading

Section titled “References & Further Reading”