Understanding how domain trusts operate in Windows Active Directory has become a critical skill in modern cybersecurity. Trust relationships—meant to simplify authentication across organizational boundaries—can also provide attackers with powerful pivoting opportunities. This guide explores the fundamentals of domain trusts, their attack surface, and techniques for exploitation and defense.
A domain trust allows users in one domain to authenticate and access resources in another. When properly configured, this enables seamless cross-domain access. When misconfigured, however, it exposes organizations to serious security risks.
Bi-directional Trusts: Users in both domains can authenticate and access each other’s resources.
Inbound Trusts: The target domain trusts the originating domain, granting access to its resources.
Outbound Trusts: The originating domain trusts the target, giving its users access to originating domain resources.
Transitive Trusts: Extend trust transitively (e.g., if A trusts B, and B trusts C, then A trusts C).
Non-Transitive Trusts: Limit trust to only the directly defined domains.
Directionality and transitivity define how attackers can navigate a trust network, making them critical in exploitation planning.
Active Directory forests group domains under shared schema, configuration, and security policies. Within a forest, domains automatically inherit bidirectional transitive trust relationships.
This built-in trust creates a high-value attack surface. Compromising one child domain could allow an attacker to escalate privileges and ultimately reach the forest root domain. For example, if an attacker controls training.redfox.local, they could eventually compromise redfox.local (the parent domain).
The initial step to exploiting domain trusts involves gathering intel on trust relationships within your target environment using various techniques and tools that enumerate and visualize trust architecture.
Trust Enumeration
Powerview, a popular PowerShell-based tool, offers an effective set of functions for enumerating domain trusts. The Get-DomainTrust cmdlet makes this easier; providing information about all trust relationships associated with your current domain as well as trust type attributes and directions. Running this cmdlet in our domain, we see that the domain training.redfox.local has a bidirectional trust relationship with the parent domain redfox.local.
A partial replica of the Active Directory Forest, the global catalogue can also be leveraged to map trust relationships within an environment. By querying it, you can gain a more holistic picture of trust mesh across multiple domains.
One of the most dangerous attacks inside a forest is “Trustpocalypse.” It abuses the SIDHistory attribute, originally intended to preserve group memberships during migrations.
The SIDHistory Vulnerability
At the core of Trustpocalypse lies its exploit of Windows 2000 Active Directory’s SIDHistory attribute for user migration between domains. This feature allows existing group memberships (SIDs) of users who have moved between domains to be maintained even after migration has occurred.
Importantly, the SIDHistory attribute is respected between forest domains, as SIDs are not stripped out during cross-domain referrals. This means an attacker who gains control of one of these child domains can alter a user account’s SIDHistory to include SIDs belonging to privileged groups like “Enterprise Admins,” thus giving them elevated access to the forest root domain.
This attack requires creating a “Golden Ticket“, or Kerberos ticket-granting ticket (TGT), that has been signed off on by the target domain’s krbtgt account and signed by any user within it – even those with elevated privileges! A DCSync attack can quickly obtain this hash before creating this TGT with SIDHistory that impersonates anyone within its forest, including users with higher privileges.
Although Trustpocalypse attacks can be used to compromise intra-forest trust relationships, exploiting cross-forest trust relationships requires taking a different approach due to extra security controls like SID filtering that may obfuscate their attack surface and complicate exploit attempts. Even though this is the preferred attack for cross-forest domains, it can also be performed to compromise the parent domain in our scenario: redfox.local
Understanding Inter-Realm Trust Tickets
When users attempt to access resources in another domain, their domain controller issues an inter-realm ticket-granting-ticket (TGT), signed with an encryption key shared between domains.
Foreign domains then use their trust key agreement to validate and decrypt referral tickets sent from different domains, authenticating user identities and granting access when appropriate.
Let us now see how this works:
However, if an attacker compromises the inter-realm trust key, they can forge the inter-realm referral tickets themselves, bypassing the need to first authenticate to the original domain.
Let us now extract the inter-realm trust key from our domain training.redfox.local.
With the hash of the compromised domain admin ADMINISTRATOR, let us create a session for that user using Rubeus by the overpass-the-hash method.
Once we have the domain Admin ADMINISTRATOR’s session in the training.redfox.local domain, we extract the trust key. We can use mimikatz’s dcsync to do this. The trust key is the trust name with a dollar sign at the end. So, in our case, it will be REDFOX$. We would also need to specify the domain.
Here, we’ve successfully extracted the trust key, essentially the NT hash of the account.
An attacker with the inter-realm trust key can forge trust tickets to impersonate any user from their domain in foreign domains. This is useful when they’ve compromised one domain but lack privileges to access another directly.
In order to forge the Inter-realm TGT, we would first need the domain SIDs of both domains. We can use the PowerView cmdlet Get-NetDomainSID to get this. We need to specify the domains using the -Domain flag.
Once we get both the SIDs, we can now craft an inter-realm TGT using mimikatz’s “golden” command, to forge a TGT for the domain admin ADMINISTRATOR for the service krbtgt on the domain redfox.local using the trust key. This ticket is then saved to a file trust.kirbi
Now using this, we can try to access to Domain controller DC-01 of the parent domain redfox.local. First, we need to forge a service ticket for the CIFS service on DC-01 using Rubeus with the inter-realm TGT.
Now, we will try to access the C: drive of the domain controller DC-01. We can list its contents, confirming that we can compromise the parent domain redfox.local through this DC.
Mitigating risks related to domain trust exploitation requires a multifaceted approach, including installing comprehensive security controls and conducting regular audits, in addition to adopting a “Red Forest” architecture.
1. Implementing SID Filtering and Quarantined Domains
Configuring SID filtering and quarantined domains prevents lateral movement of privileged accounts across trust boundaries, reducing the attack surface. By carefully managing which SIDs traverse each trust boundary, organizations can substantially lower their attack surface.
2. Adopting the Enhanced Security Administrative Environment (ESAE)
Microsoft recommends adopting a Security Administrative Environment, known as Red Forest, for Active Directory. This minimizes domain trust vulnerabilities and enhances overall security. By adopting and implementing such an administrative environment, organizations can bolster their overall security posture.
3. Continuous Monitoring and Auditing
Continuous monitoring and auditing of domain trust relationships, group memberships, and ACLs are vital. This helps quickly identify misconfigurations or vulnerabilities and take appropriate action. Automated tools like BloodHound can assist in this effort to assess trust architecture and identify possible attack paths.
Domain trusts—while essential for enterprise authentication—create powerful opportunities for lateral movement and privilege escalation. By understanding their mechanics, attackers can craft sophisticated exploitation chains, but defenders can also design effective mitigations.
Staying ahead requires:
Clear visibility into trust relationships.
Strong architectural controls like ESAE.
Ongoing monitoring and proactive security testing.
Redfox Security specializes in identifying and mitigating these risks. Reach out to strengthen your Active Directory defenses—or explore our training programs to deepen your expertise.
Redfox Cyber Security Inc.
8 The Green, Ste. A, Dover,
Delaware 19901,
United States.
info@redfoxsec.com
©️2025 Redfox Cyber Security Inc. All rights reserved.
