Active Directory Forest Trust Security: SID Filtering, Selective Authentication, and M&A Trust Hardening
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Active Directory forest trusts established during M&A integrations or partner access arrangements are among the most commonly misconfigured and least regularly reviewed attack surfaces in enterprise environments. A trust configured during an acquisition five years ago with SID filtering disabled and no selective authentication may still be active long after the business justification for it has expired.
The technical risks are well-established: an attacker who compromises any domain in a trusted forest with SID filtering disabled can escalate to Domain Admin in the trusting forest using SID history injection. The practical risk is that most organizations cannot enumerate their existing trusts without checking Active Directory directly, and have not reviewed the security configuration of those trusts since they were created.
Trust audit: finding and assessing existing trusts
Before remediating trust misconfigurations, you need a complete picture of every trust relationship in the environment and its current security settings. The netdom command-line tool is the primary instrument for this audit, letting you enumerate all trusts and verify SID filtering status per trust without requiring GUI access to each domain controller. This section covers the enumeration commands, the fields to record for each trust, and how to prioritize remediation based on the combination of trust type, filtering status, and active business justification.
Enumerate all trusts and verify SID filtering status before any remediation
Run netdom query trust /domain:YOURDOMAIN on a domain controller to list all trusts visible from that domain, then for each trusted domain run netdom trust YOURDOMAIN /domain:TRUSTED_DOMAIN /quarantine to check the SID filtering status. Quarantine:Yes means SID filtering is enabled (secure). Quarantine:No means SID filtering is disabled — investigate why and whether there is a current business requirement. For each trust, document the direction (incoming, outgoing, bidirectional), the type (forest, external, shortcut, realm), when it was created, what business purpose it serves, and who owns it. This inventory is the baseline for remediation prioritization: bidirectional forest trusts with SID filtering disabled and no selective authentication are the highest-risk items.
Enable selective authentication on all external-organization trusts as an immediate control
Selective authentication can be enabled on an existing trust without disrupting existing access if you first grant Allow to authenticate on each resource that legitimate users from the trusted forest should be able to reach. The sequence: identify which servers users from the trusted forest currently access (by reviewing Security Event Log 4769 cross-forest authentication events), grant Allow to authenticate on those server computer objects for the specific groups from the trusted forest that need access, then enable selective authentication on the trust. Test with a pilot user from the trusted forest before enabling broadly. This change limits the trust's reach from the entire forest to only the explicitly authorized resources, containing the blast radius of a trusted forest compromise.
Monitoring: detecting cross-forest trust abuse
Trust abuse generates distinctive patterns in the Windows Security Event Log that differ from normal authentication activity because the Account Domain field in Kerberos events reveals the originating forest. Security teams should configure SIEM rules targeting Event IDs 4769 and 4765 filtered by cross-forest context, rather than relying solely on GuardDuty or Defender for Identity to surface these findings. This section covers the specific event IDs, the filter conditions that distinguish cross-forest abuse from routine authentication, and the alert thresholds that balance detection coverage against false positive volume.
Monitor Event ID 4769 for cross-forest service ticket requests targeting sensitive resources
Kerberos TGS requests (Event ID 4769) from accounts in a trusted forest to resources in your forest appear in the Security Event Log on your domain controllers with the Account Domain field showing the trusted domain name. Configure SIEM alerts for Event ID 4769 where the Account Domain field matches a trusted external forest and the Service Name field matches any high-value resource (domain controllers, file servers with sensitive data, administration systems). Unusual patterns — a service ticket requested for a resource the account has never accessed, requests at unusual hours, or requests for high-value resources from a low-privilege account — indicate potential trust abuse or reconnaissance.
Alert on Event ID 4765 for SID history modifications as a high-severity indicator
Windows logs Event ID 4765 (SID history was added to an account) when the SIDHistory attribute of an account is modified. In normal operations, SID history is populated only during domain migrations by authorized migration tools. An Event ID 4765 logged outside of an active, authorized migration project indicates that an attacker with Domain Admin privileges in the trusted forest is staging a cross-forest privilege escalation attack. Configure this event as a critical alert in your SIEM with immediate response required. Defender for Identity detects this pattern and generates the Suspected Golden Ticket usage or Directory Services Replication attack alerts when SID history is abused for cross-forest access.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
The bottom line
Active Directory forest trusts are a persistent and often overlooked attack surface. The security baseline requires SID filtering enabled on all cross-organization trusts (netdom confirms quarantine:Yes), selective authentication enforced to limit trust access to explicitly authorized resources, an inventory of all trusts with business justification and planned review dates, and SIEM alerting on cross-forest authentication anomalies and SID history modification events. Trusts with no current business justification should be removed: a decommissioned trust eliminates the entire attack surface it represented, and the access it provided can be replaced with explicit accounts in your own forest for any remaining legitimate use cases.
Frequently asked questions
What are the security risks of Active Directory forest trusts?
The primary security risks of AD forest trusts are cross-forest privilege escalation and expanded attack surface. Cross-forest privilege escalation occurs when SID filtering is disabled and an attacker in the trusted forest can forge tokens containing privileged SIDs from the trusting forest using SID history attributes, gaining Domain Admin access across the forest boundary. Expanded attack surface means that a compromise in the trusted forest (such as an M&A partner's domain) gives the attacker a foothold to attempt lateral movement and authentication against resources in your forest. Secondary risks include cross-forest Kerberoasting (requesting service tickets for accounts in the trusting forest), credential relay attacks that use trust relationships to move laterally, and access persistence through accounts in the trusted forest that retain access after the business relationship ends.
What is SID filtering and why is it critical for forest trust security?
SID filtering (also called quarantine mode) filters out SID history attributes from authentication tokens crossing the forest boundary. In a forest trust with SID filtering disabled, a user account in the trusted forest can have a SIDHistory attribute populated with any SID including Domain Admins or Enterprise Admins from the trusting forest. When that user authenticates to a resource in the trusting forest, the SID history values are included in their Kerberos ticket, granting them the access rights associated with those SIDs. With SID filtering enabled, any SID in the token that does not belong to the trusted forest's own domain SID namespace is stripped before the token is presented to the resource. Forest trusts between different organizations have SID filtering enabled by default; be cautious about any configuration changes that disable it.
How do I configure selective authentication for an Active Directory forest trust?
Selective authentication is configured on the trust properties in Active Directory Domains and Trusts. Open Active Directory Domains and Trusts, right-click the domain, select Properties, then the Trusts tab, select the incoming or outgoing trust, click Properties, and on the Authentication tab select Selective authentication. Once enabled, users from the trusted forest cannot authenticate to any resource in your forest by default. To permit access, on each resource server that should be accessible, open the Active Directory object properties of the computer account, go to Security, add the users or groups from the trusted forest that need access, and grant them the Allow to authenticate permission specifically. This limits trust access to explicitly authorized resource-by-resource grants rather than the entire forest.
How do attackers abuse SID history for cross-forest privilege escalation?
The SID history attack abuses the SID history attribute that exists on user accounts to support domain migrations. When a user account is migrated from an old domain to a new one, the old domain SID can be preserved in SIDHistory so the account retains access to resources that still reference the old SID. An attacker with Domain Admin access in the trusted forest can populate a user account's SIDHistory attribute with privileged SIDs from the trusting forest using tools like Mimikatz (lsadump::sid) or by directly modifying the attribute. If SID filtering is disabled on the trust, authentication with this account to the trusting forest includes the injected SID in the Kerberos token, granting the associated privileges. Prevention: keep SID filtering enabled and monitor for SIDHistory modification events (event ID 4765 in the Security log).
What trust type should I use for M&A integration and how should I restrict its scope?
For M&A integration where temporary cross-forest access is needed, use an external trust to specific domains rather than a full forest trust if possible: external trusts are non-transitive and limited to the specific domains on each end, while forest trusts are transitive within each forest (any domain in the trusted forest can potentially authenticate). Configure selective authentication on the trust to limit which resources in your forest are accessible from the acquired company's forest. Enable SID filtering (confirm quarantine mode is on by running netdom trust /domain:TRUSTED_DOMAIN /EnableSIDHistory:no). Set a time limit on the trust and plan to migrate user accounts or decommission the trust once the integration is complete. Document all trusts in your asset inventory with the business justification and planned end date.
How do I audit existing Active Directory trusts for security misconfigurations?
Audit existing trusts using the netdom query trust /domain:YOURDOMAIN command to list all trusts and their direction (incoming, outgoing, bidirectional). For each trust, check the SID filtering status with netdom trust /domain:TRUSTED_DOMAIN /quarantine and confirm it shows quarantine:Yes. Verify selective authentication is enabled by checking the trust properties in Active Directory Domains and Trusts. Identify trusts where the trusted forest is an external organization with no current business relationship — stale trusts are a persistent attack surface. Review Kerberos authentication events (Event IDs 4768 and 4769) filtered by cross-forest authentication to identify unusual authentication patterns from trusted domains. Microsoft Defender for Identity generates alerts for cross-forest privilege escalation attempts and unusual cross-forest authentication patterns.
What is a PAM trust and when should I use one?
A PAM (Privileged Access Management) trust is a special one-way trust type introduced in Windows Server 2016 that enables a hardened bastion forest to provide privileged access to resources in the production forest with time-limited just-in-time access. The bastion forest maintains high security standards (no legacy OS, strict authentication policies, no internet connectivity), and shadow security principals in the bastion forest are mapped to privileged groups in the production forest. Administrators log into the bastion forest, request time-limited access (such as 1 hour of Domain Admin access), and perform their tasks. The access expires automatically. Use a PAM trust when you need to implement a privileged access model where administrators never have standing privileged access to the production forest from a general-purpose workstation.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.