What Are Active Directory Trust Attacks?
Active Directory trust attacks abuse the authentication and authorization paths that allow one domain or forest to access resources in another. Trusts are a normal part of AD DS. Parent-child trusts inside a forest, external trusts, shortcut trusts, and forest trusts all exist to support real access requirements. The risk is that a trust also extends the security boundary that defenders must understand.
A trust does not automatically mean compromise. The practical risk depends on trust type, direction, transitivity, SID filtering behavior, selective authentication, administrative tiering, and the compromise level in the source domain. But in a multi-domain forest, a child-domain compromise can become a forest-level incident if the attacker can abuse Kerberos trust paths, privileged SIDs, or administrative access that crosses the boundary.
A good review starts with three questions:
- which trusts exist and who owns them
- which trusts still have a current business requirement
- whether each trust limits cross-boundary authorization to the intended scope
How Active Directory Trusts Work
Microsoft documents that AD DS uses domain and forest trust relationships to provide authentication across domains and forests. Before access across a trust is possible, Windows computes a trust path between the domain controller for the resource and a domain controller in the requesting account's domain.
Trusts can be one-way or two-way. They can also be transitive or non-transitive. In an on-premises AD DS forest, new child domains automatically create two-way, transitive trust relationships with the parent domain. That transitivity lets authentication requests follow trust paths across the domain tree when permissions allow access.
That behavior is useful, but it means defenders should not treat a child domain as a low-consequence directory. If a child domain is poorly administered, over-trusted, or compromised at the domain-controller level, the forest has to be reviewed as a connected security system.
Where SID Filtering Fits
Kerberos tickets include authorization data, including SIDs used to make access decisions. SID History exists for migration scenarios where an account must retain access to resources that still reference an old SID. Microsoft documentation for SIDHistory migration notes that unauthorized modification of sIDHistory can allow unauthorized access to resources in domains that trust the unauthorized account domain.
SID filtering is designed to reduce this risk at trust boundaries. Microsoft's PAC specification describes SID filtering behavior across trust boundaries, including cross-forest and external trusts. The exact behavior depends on the trust boundary and SID category, so it is important not to reduce the topic to a single flag without understanding the trust type.
For external trusts, administrators commonly review quarantine or SID filtering state. For forest trusts, selective authentication and forest trust settings may also matter. For parent-child trusts inside the same forest, the larger issue is often architectural: all domains are part of the same forest trust fabric, so domain compromise can have consequences beyond the local domain.
Scope Limits and Preconditions
This is not a claim that every AD trust is exploitable. High-impact trust abuse normally requires a strong prerequisite, such as:
- compromise of a domain controller or equivalent domain-level secret in the source domain
- ability to forge or manipulate Kerberos authorization data
- a trust path that accepts the resulting authorization context
- target resources that authorize access based on privileged SIDs or cross-domain groups
- weak separation between administrative tiers across domains
That is why trust review should be tied to incident response assumptions. If a child domain's krbtgt secret or domain controllers are compromised, do not treat the incident as isolated until the trust paths, privileged sessions, and cross-domain authorization have been reviewed.
Common Trust Abuse Patterns
Child Domain to Parent or Forest Root
The classic escalation scenario starts with domain compromise in a child domain. If the attacker controls the source domain deeply enough, they may try to forge Kerberos material that carries privileged authorization data toward a parent or forest-root resource. Whether that succeeds depends on trust behavior and filtering, but the defensive lesson is clear: child domains require Tier 0-grade protection when they are part of the same forest.
Stale External Trusts
Old external trusts are common after migrations, partner integrations, acquisitions, or temporary projects. A stale trust may still permit authentication paths nobody actively owns. Even if SID filtering is enabled, an unnecessary trust is still an unnecessary attack surface.
Weak Trust Ownership
A trust without an owner becomes hard to change because nobody can approve removal. That leads to permanent exceptions. Every remaining trust should have an application owner, business owner, authentication direction, expected users, and review date.
Privileged Administration Across Boundaries
Trusts become more dangerous when administrators use privileged credentials across domains or forests. A privileged session in a lower-governance domain can expose credentials or tokens that allow movement into a more sensitive domain. Trust hardening and privileged access hardening must be reviewed together.
Detection
No single Windows event proves a trust attack. Detection requires trust inventory, Kerberos event review, privileged logon context, and change monitoring.
Windows Event and Log Sources
| Signal | Why It Matters |
|---|---|
| 4769 Kerberos service ticket requests | Helps investigate cross-domain or cross-realm service-ticket activity. |
| 4624 successful logons | Shows administrative or cross-domain logons on target systems. |
| 4672 special privileges assigned | Useful when a logon receives high-privilege rights unexpectedly. |
| Trust object changes | Changes to trust direction, attributes, or filtering behavior can alter the boundary. |
| Privileged group changes | Cross-domain group membership or nested group changes can expose trust-based paths. |
Event data needs context. A cross-domain 4769 event may be normal for an application. A cross-domain administrative logon from an unexpected account, after a child-domain incident, is very different.
Trust Inventory Review
Inventory all trusts and classify them:
Get-ADTrust -Filter * |
Select-Object Name, TrustType, TrustDirection, ForestTransitive, SelectiveAuthentication, SIDFilteringQuarantined
Use the result for triage. SIDFilteringQuarantined = False is not automatically proof of compromise or misconfiguration, but it should have an owner and a reason. If nobody can explain why the trust needs its current settings, it belongs in the cleanup queue.
Remediation
The safest trust is the one that no longer exists because the business dependency ended. Harden the remaining trusts according to their type and purpose.
1. Remove Stale Trusts
Review old partner, migration, test, and acquisition trusts first. If a trust has no owner, no active application dependency, and no recent access requirement, remove it through the normal change process.
2. Review SID Filtering and Quarantine
For external trusts where compatible, enable quarantine or SID filtering and validate the dependent workflows. Microsoft netdom trust supports the /Quarantine option for trust management, and the command documentation notes that No accepts any SID. That setting should not be left to historical accident.
3. Use Selective Authentication Where Appropriate
For forest trusts, selective authentication can limit which users from the trusted forest can authenticate to specific resources. It is not a substitute for good ACLs or privileged-access hygiene, but it reduces broad authentication reach.
4. Treat Child Domains as High-Consequence
Do not assume a child domain is a low-risk administrative zone. Secure child domain controllers, privileged groups, krbtgt handling, and administrative workstations with the same seriousness as the forest root when trust paths allow cross-domain access.
5. Reduce Cross-Boundary Privileged Sessions
Do not routinely use forest-root or parent-domain privileged accounts in less trusted child domains. If administrators must cross the boundary, use dedicated accounts, controlled admin workstations, and logging that makes the session visible.
What Not to Change Blindly
Do not enable or remove trust controls without testing the dependent authentication flow. SID filtering, quarantine, and selective authentication can break legacy access patterns, migration workflows, or applications that were built around broad cross-domain access. That compatibility risk is not a reason to leave the trust unsafe; it is a reason to document the dependency, test in a controlled window, and replace broad trust with explicit access where possible. If the business cannot remove a risky trust immediately, the exception should include an owner, end date, monitoring plan, and compensating privileged-access controls.
Validation After Trust Hardening
After a trust change, validate both security and business function:
- re-run trust inventory and record direction, type, transitivity, selective authentication, and SID filtering state
- confirm application teams retested workflows that depend on the trust
- verify old migration or partner trusts were removed rather than only documented
- review Kerberos and logon activity across the trust after the change
- check whether privileged users still authenticate across the boundary
- document exceptions with an owner, expiration date, and compensating controls
A trust review is successful only when the remaining trusts are intentional, owned, monitored, and constrained to the access the business still needs.
How EtcSec Detects This
EtcSec audits trust relationships and highlights trust paths that increase the chance of cross-domain escalation.
Trust-related findings are most useful when they are correlated with the surrounding attack path: whether a child domain already has weak administrative hygiene, whether a stale external trust still exists, and whether high-value identities or delegated rights sit on both sides of the boundary.
Related Reading
Review trust exposure together with Active Directory Attack Paths to Domain Admin, Dangerous Group Nesting: Hidden Paths to Domain Admin, ACL Abuse and DCSync: The Silent Paths to Domain Admin, Kerberos Delegation Attacks: From Unconstrained to RBCD Abuse, and Golden Ticket Attack: The Keys to Your Kingdom. Trust abuse is usually a path multiplier, not an isolated misconfiguration.
