Insecure Domain and Forest Trusts

Description

Domain and forest trusts connect separate AD environments and can expand the blast radius of a compromise. Misconfigured trusts (e.g., disabled SID filtering, overly broad transitive trusts, or lack of selective authentication) allow attackers in a lower‑tier or partner domain to escalate into more privileged domains, including the forest root. Trusts that grant over‑privileged groups or service accounts access across forests can effectively bypass intended network segmentation and tiering.

Examples

Enumerate Trusts and Their Properties

List trusts from a domain‑joined host:

Get-ADTrust -Filter * | Select-Object Name,Direction,ForestTransitive,SelectiveAuthentication,SIDFilteringQuarantined

Look for external or forest trusts where SIDFilteringQuarantined is disabled or SelectiveAuthentication is False, especially toward higher‑privilege forests.

Review Cross-Forest Privileged Groups

Identify groups granted access from or to trusted forests:

Get-ADGroup -Filter * -Properties MemberOf |
  Where-Object { $_.Name -like '*Admins*' -or $_.Name -like '*Operators*' } |
  Select-Object Name,DistinguishedName,MemberOf

Combine this with trust information to see where “foreign” admins can act in your environment.

Check for SIDHistory and Legacy Migration Artifacts

Trusts used during domain migrations often leave SIDHistory on accounts:

Get-ADUser -Filter { SIDHistory -like "*" } -Properties SIDHistory |
  Select-Object SamAccountName,SIDHistory

Excessive or unneeded SIDHistory entries, combined with weak trust configuration, can allow privilege escalation from legacy domains.

Remediation

  1. Apply least privilege to trusts
    • Only create trusts where strictly required; prefer one‑way inbound trusts from less‑trusted to more‑trusted environments.
    • Limit cross‑forest administrative groups and remove broad “*Admins” style access wherever possible.
  2. Enable protections on trusts
    • Ensure SID filtering is enabled for external and forest trusts unless there is a compelling, documented reason not to.
    • Use selective authentication so that only explicitly authorised accounts can access resources across the trust.
  3. Clean up migration and legacy artifacts
    • Audit and remove unnecessary SIDHistory entries after migrations.
    • Decommission and remove trusts that are no longer needed; monitor for new or modified trust objects.