Search/ GitHub
PW-012HygieneTrusts, management planes and other systems

Trust between forests with weak SID filtering

A trust to another forest or domain doesn't filter security identifiers, so a breach on the other side can become a breach here.

Category
Hygiene
Severity
High.
Typical owner
AD / identity team
Data needed
Trust data, which every collector reads from the domain.
MITRE ATT&CKT1134.005
Most useful toDefensive engineersIdentity and access engineersAuditors
On this page

In plain language

A trust lets users from another forest or domain access your resources. SID filtering makes sure they arrive only with the identities they hold there, and can't claim membership of your admin groups by smuggling extra security identifiers (SIDs) into their logon.

With filtering off, whoever compromises the other forest can forge their way into yours, so your security becomes only as good as theirs. Filtering is on by default and is usually turned off for a migration that ended long ago.

What Pathwarden flags

This trust between forests filters security identifiers (SIDs) only weakly: a forest trust with SID history enabled (TREAT_AS_EXTERNAL, trustAttributes bit 0x40), or an external trust that is not quarantined. Authentication coming from the trusted domain may carry SIDs of your domain in an account's SID history, and your domain honors those with a RID of 1000 or above. It still drops the built-in and privileged SIDs: every RID under 1000 (Administrator 500, krbtgt 502, Domain Admins 512, Schema Admins 518, Enterprise Admins 519), Enterprise Domain Controllers (S-1-5-9) and the built-in SIDs (S-1-5-32-*, Everyone, NT Authority).

How attackers use it

An attacker who compromises the trusted domain can forge a Kerberos ticket whose SID history carries the SID of an account or group of your domain with a RID of 1000 or above, and your domain grants what that SID holds (Access Token Manipulation: SID-History Injection, MITRE ATT&CK T1134.005). Domain Admins and Enterprise Admins can't be forged this way, but groups and accounts you created can: Exchange Windows Permissions, an Entra Connect (MSOL_) account, a custom admin group. Only rights the forged SID holds directly or through domain-local groups apply; its global and universal group memberships are not expanded. Where such a SID controls Tier Zero, a breach there is a breach here.

Inside one forest (parent and child domains) none of this filtering applies: whoever controls one domain controls the forest, which Pathwarden shows as forest takeover, not PW-012.

No public lab test of a real non-quarantined external trust exists; what passes is taken from the protocol specification (MS-PAC 4.1.2.2) and the forest trust lab work cited below.

Find it with Pathwarden

Data needed: Trust data, which every collector reads from the domain.

In the web UI or the HTML report, open the Findings tab and expand PW-012: each finding shows who can use it (its exposure), the attack path drawn out, the affected objects, and the fix. The remediation path tells you whether a single plan step closes it. On the command line:

Shell
# every finding of this rule, with its path and fix
pathwarden findings -i .\collect --rule PW-012
# the step-by-step guide on this page, offline
pathwarden guide PW-012
# after the fix: collect again, then check it is gone
pathwarden retest -i .\collect-after --rule PW-012

Exit codes make retest easy to script: 0 Fixed, 1 Still open, 3 Can't tell. See findings lifecycle and retest.

Before you change anything

  • SID history is usually let through on purpose during a migration, so migrated accounts keep access through their old SIDs in sIDHistory. Confirm with the AD team whether a migration is still running.
  • Find users who still depend on SID history: Get-ADUser -Filter * -Properties SIDHistory | Where-Object SIDHistory. Re-permission their resources with their new SIDs before tightening the filter.
  • Quarantining an external trust also filters SIDs from other domains in the trusted forest. Plan for access that crosses those domains.

How to fix it

Run on a domain controller of the trusting domain (the domain that grants access), as a Domain Admin. <TrustingDomain> is the domain the finding's fix names (usually the first in its title; for a record the collector saw as inbound, the second).

  1. Open an elevated command prompt.
  2. For a forest trust, turn SID history off across it so the forest boundary filters again: netdom trust <TrustingDomain> /domain:<TrustedDomain> /enablesidhistory:no. Do not quarantine a forest trust: Microsoft says quarantine "should not be applied to forest trust relationships".
  3. For an external trust, quarantine it: netdom trust <TrustingDomain> /domain:<TrustedDomain> /quarantine:yes

Option B: Finish the migration, clean up SID history, then filter

  1. Re-permission resources that still rely on old SIDs.
  2. Clear sIDHistory from migrated accounts.
  3. Apply Option A.

PowerShell

PowerShell
Import-Module ActiveDirectory

# Inspect the trust (TrustAttributes 0x40 = SID history enabled on a forest trust;
# SIDFilteringQuarantined = quarantine on an external trust)
Get-ADTrust -Filter "Target -eq '<TrustedDomain>'" |
    Select-Object Name, Direction, TrustType, TrustAttributes, SIDFilteringQuarantined, SIDFilteringForestAware

# Find accounts that still carry SID history
Get-ADUser -Filter * -Properties SIDHistory | Where-Object { $_.SIDHistory } |
    Select-Object SamAccountName, SIDHistory

# Forest trust: turn SID history off (elevated prompt, DC of the trusting domain)
netdom trust <TrustingDomain> /domain:<TrustedDomain> /enablesidhistory:no

# External trust: quarantine it (elevated prompt, DC of the trusting domain)
netdom trust <TrustingDomain> /domain:<TrustedDomain> /quarantine:yes

Verify the fix

  • Forest trust: netdom trust <TrustingDomain> /domain:<TrustedDomain> /enablesidhistory reports that SID history is disabled, and (Get-ADTrust -Filter "Target -eq '<TrustedDomain>'").TrustAttributes -band 0x40 is 0.
  • External trust: netdom trust <TrustingDomain> /domain:<TrustedDomain> /quarantine reports that SID filtering is enabled.

Collect again (or use Retest on the finding) and confirm the finding ID is gone.

Roll back

  • Forest trust: netdom trust <TrustingDomain> /domain:<TrustedDomain> /enablesidhistory:yes.
  • External trust: netdom trust <TrustingDomain> /domain:<TrustedDomain> /quarantine:no.

Either restores the previous behavior. Do this only temporarily, and accept the finding as a risk in Settings, with a review date.

References

  1. Microsoft: netdom trustlearn.microsoft.com
  2. MS-PAC 4.1.2.2, SID filtering and claims transformationlearn.microsoft.com
  3. Dirk-jan Mollema, Active Directory forest trusts part one, how does SID filtering workdirkjanm.io
  4. SpecterOps (2025), Good fences make good neighbors, new AD trusts attack paths in BloodHoundspecterops.io
  5. BloodHound, SpoofSIDHistory edgebloodhound.specterops.io
  6. SpecterOps BloodHound docs: HasSIDHistorybloodhound.specterops.io
  7. MITRE ATT&CK T1134.005: Access Token Manipulation: SID-History Injectionattack.mitre.org

↑↓ to moveEnter to openEsc to close