AD Trusts: How Hackers Weaponize Network Trust to Hijack Systems

To understand how trusts are exploited, one must first grasp the distinct types of trust relationships and how authentication flows across them. Active Directory Trusts are defined by two primary characteristics: Direction and Transitivity.

Trust Direction: Who Trusts Whom?

Trust relationships are inherently directional, dictating the flow of authentication.

• One-Way Trust: In a one-way trust, Domain A trusts Domain B. This means users from Domain B (the Trusted domain) can access resources in Domain A (the Trusting domain). However, users in Domain A cannot access resources in Domain B. The trust flows in one direction, while the access flows in the opposite direction.
• Two-Way Trust: In a two-way trust, Domain A and Domain B trust each other equally. Users in either domain can access resources in the other, assuming they have the appropriate permissions.

Transitivity: The Chain Reaction

Transitivity is the most critical and dangerous aspect of AD Trusts.

• Transitive Trusts: If Domain A trusts Domain B, and Domain B trusts Domain C, a transitive trust implies that Domain A automatically trusts Domain C. The trust relationship flows through the chain. By default, all parent-child domains within the same AD Forest share a two-way, transitive trust. This means every domain within a forest inherently trusts every other domain in that forest.
• Non-Transitive Trusts: The trust relationship is strictly bounded between the two explicitly connected domains. It cannot be extended to other domains. External trusts and Realm trusts are typically non-transitive.

Intra-Forest vs. Inter-Forest Trusts

Intra-Forest Trusts are the default, automatically generated trusts between domains within the same overall AD Forest. Because they are transitive, the Forest is considered a single security boundary. A compromise anywhere in the forest can potentially lead to the compromise of the entire forest. Inter-Forest Trusts (or Cross-Forest Trusts) are established manually between two entirely separate AD Forests (e.g., when two companies merge). These can be one-way or two-way, but they establish a hard security boundary between the forests, meaning a compromise of Forest A should technically not result in the automatic compromise of Forest B, provided the trust is properly secured.

When an attacker gains Domain Administrator privileges in a child domain (e.g., dev.corp.local), their immediate objective is to escalate their access to the parent root domain (corp.local), where the most critical enterprise assets and Enterprise Administrator accounts reside. Attackers abuse the inherent trust architecture to forge authentications and bypass security boundaries.

The ExtraSids Attack (Forging SID History)

Every user and group in Active Directory is identified by a unique Security Identifier (SID). When a user logs in, the Domain Controller generates a Kerberos Ticket Granting Ticket (TGT) that contains the user's SID, as well as the SIDs of all the groups they belong to. When organizations migrate users between domains, they use a feature called SID History to ensure the user retains access to resources in their old domain.

Attackers brilliantly weaponize SID History in an attack known as SID Filtering bypass or the ExtraSids attack. If an attacker has compromised a child domain and extracted the password hash of the krbtgt account for that child domain, they can forge a Golden Ticket. Crucially, when forging this ticket, the attacker injects the highly privileged SID of the "Enterprise Admins" group (which exists only in the parent root domain) into the SID History field of their forged ticket.

Because the parent domain inherently trusts the child domain (via the default intra-forest trust), it accepts the Kerberos ticket presented by the attacker. When the parent domain reads the SID History field, it grants the attacker Enterprise Admin privileges across the entire forest. The attacker has seamlessly escalated from controlling a minor child domain to dominating the entire global enterprise infrastructure.

Abusing Cross-Forest Trusts

While Inter-Forest trusts represent a harder security boundary, they are not impenetrable. If Company A has a two-way trust with Company B, and an attacker compromises Company A, they will immediately begin probing Company B across the trust boundary.

Attackers utilize tools like BloodHound to map cross-forest trust relationships and identify misconfigurations. They actively hunt for users or groups in the compromised forest (Company A) that have been improperly granted administrative privileges over resources in the target forest (Company B). Furthermore, attackers can execute Kerberoasting attacks across forest trusts. Any user in Company A can request a Service Ticket for a service hosted in Company B. The attacker requests the ticket, extracts it, cracks it offline, and uses the resulting credentials to establish a direct foothold in the second forest.

Unconstrained Delegation Across Trusts

Kerberos Delegation, particularly Unconstrained Delegation, is incredibly dangerous when combined with AD Trusts. If an attacker compromises a server with Unconstrained Delegation in Domain A, they can attempt to coerce a highly privileged user from a trusted Domain B (e.g., via a forced authentication attack like the "Printer Bug") to connect to their compromised server. The server in Domain A will capture and store the Ticket Granting Ticket (TGT) of the Domain B administrator in memory. The attacker can simply extract this TGT and use it to assume full administrative control over Domain B.

Securing complex trust architectures requires organizations to abandon the assumption that internal networks are inherently safe. Defending against trust exploitation demands strict isolation, aggressive filtering, and continuous architectural review.

Enforce SID Filtering

The most critical defense against the ExtraSids/SID History attack across trust boundaries is the rigorous enforcement of SID Filtering (also known as SID Quarantine). When SID Filtering is enabled on a trust link, the trusting domain will actively inspect incoming Kerberos tickets. If the ticket contains SIDs in the SID History field that claim highly privileged status (like Enterprise Admins) but originate from the trusted domain, the trusting domain will strip those SIDs out of the ticket before granting access.

While SID Filtering is enabled by default on external Inter-Forest trusts, it is not enabled by default on Intra-Forest trusts (between parent and child domains). Organizations must understand that the Forest is the absolute security boundary. If a child domain is deemed less secure, it should not reside in the same forest.

Implement Selective Authentication

When establishing external or cross-forest trusts, organizations should absolutely avoid using the default "Forest-wide Authentication." This default setting allows any authenticated user in the trusted forest to authenticate to any resource in the trusting forest.

Instead, administrators must enforce Selective Authentication. With this highly restrictive setting, users from the trusted forest are not granted default access to anything. Administrators must explicitly manually configure specific resources (e.g., a specific file server or application) to allow authentication from specific users or groups across the trust. This drastically reduces the attack surface and prevents an attacker in a compromised forest from freely pivoting into the trusting forest.

Continuous Trust Auditing and BloodHound Mapping

Trust relationships are often created for temporary projects or integrations and then forgotten, leaving massive security backdoors open for years. Security teams must implement a rigid, continuous audit cycle for all AD Trusts.

Any trust relationship that is no longer strictly required for business operations must be immediately severed. Furthermore, defenders should routinely utilize tools like BloodHound to map their own environments, specifically analyzing cross-domain and cross-forest attack paths. By visualizing how privileges flow across trust boundaries, security teams can identify and remediate toxic permission combinations before adversaries can exploit them.