BIPI
BIPI

Trust Relationship Abuse: Cross-Forest Compromise Patterns

Cybersecurity

Forest trusts were designed when the security boundary was the forest. Modern attacks treat trusts as one more BloodHound edge. We cover SID history abuse, cross-forest golden tickets, and selective authentication.

By Arjun Raghavan, Security & Systems Lead, BIPI · December 4, 2024 · 8 min read

#active-directory#forest-trust#pentest

Microsoft documentation says the forest is the security boundary. Microsoft documentation also says SID filtering is on by default for new external trusts. Production domains contain trusts created in 2008 with SID filtering disabled because the AD admin at the time needed to migrate users with SID history. Trust relationships are the single most under-audited surface in AD because most teams forget they exist.

How attackers find this

BloodHound CE collects trust relationships and renders them as graph edges. SharpHound -c Trusts pulls the trust topology, and the resulting graph shows which trust types exist (parent-child, tree-root, external, forest) and which direction they go.

  • Enumerate trusts with PowerShell: Get-ADTrust -Filter * | Select Name, Direction, ForestTransitive, SIDFilteringForestAware, SIDFilteringQuarantined.
  • trustdump and impacket's lookupsid.py target the foreign domain through the trust to enumerate users and groups without direct authentication.
  • If SID filtering is disabled, a Golden Ticket from forest A with the SID of an Enterprise Admin from forest B (added via the ExtraSids field) authenticates as that EA in forest B. Mimikatz: kerberos::golden /user:Administrator /domain:forestA /sid:S-1-5-21-A /sids:S-1-5-21-B-519 /krbtgt:hash /ticket:cross.kirbi.
  • Foreign Security Principals: when forest B grants permissions to a forest A user, AD creates an FSP object in forest B's CN=ForeignSecurityPrincipals,DC=B,... Hunting these in BloodHound shows where cross-forest privileges live.
  • RBCD (Resource-Based Constrained Delegation) across trusts where the trust supports SIDless delegation. Less common but seen in tightly integrated forests.

On a recent assessment, we compromised a development forest's krbtgt, then used a Golden Ticket with the production forest's Enterprise Admin SID (extracted from the trust attributes) to authenticate to the production forest's domain controller. The customer believed the dev forest was sandboxed. SID filtering had been disabled in 2014 by an admin who is no longer at the company.

What defenders see

Cross-forest authentication produces specific Kerberos ticket events that look different from same-forest activity.

  • 4769 events on a domain controller where the TargetUserName comes from a foreign domain SID range and the ServiceName is high-value (cifs/dc, ldap/dc) are cross-forest TGS requests. Inventory expected ones, alert on the rest.
  • 4768 with a TargetUserName that does not exist in the local domain but resolves through a trust referral indicates cross-forest authentication. Sudden spikes are the Golden Ticket relay signature.
  • 5136 changes to trustedDomain objects (trust attribute modifications) outside change windows. An attacker enabling sidHistory on an existing trust shows up here.
  • Microsoft Defender for Identity (MDI) has built-in cross-forest detections including suspicious additions to sensitive groups via SID history. Deploy MDI sensors on every DC, including the ones in trusted forests.

Remediation

Trust hardening is structural and slow. The settings exist; the work is auditing the inventory and changing the settings without breaking applications.

  1. For every external and forest trust, verify SID filtering is enabled: netdom trust trusting.domain /domain:trusted.domain /quarantine:Yes for external trusts and /enablesidhistory:No for forest trusts. Check both directions.
  2. Enable Selective Authentication on trusts that do not need full transitive auth. This requires applying allowedToAuthenticate ACEs on resources that foreign accounts should be able to access. More work, much smaller blast radius.
  3. Audit the contents of CN=ForeignSecurityPrincipals,DC=domain,DC=local. Each FSP represents a foreign account with permissions in your forest. Verify each one is still needed.
  4. Apply the tier model across trusts. Tier-0 of forest A should never be reachable from tier-1 of forest B. Authentication Policy Silos enforce this if forest functional level supports it.
  5. Treat krbtgt rotation as cross-forest aware. After a suspected compromise of forest A, also rotate the inter-forest trust password (netdom trust /resetonewaytrust) because trust authentication uses a separate key that is not affected by krbtgt rotation alone.
  6. Decommission trusts that no longer have a business owner. The single most effective hardening step is removing the trust entirely. We have closed dozens of trusts whose original purpose was a 2012 acquisition that has since been fully integrated.

The mature outcome is a documented trust inventory with named owners, SID filtering enabled everywhere, and Selective Authentication on cross-org trusts. Most domains are five years away from this. The first step is the inventory. Most teams discover they have trusts they did not know about.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.