Good Fences Make Good Neighbors: New AD Trusts Attack Paths in BloodHound

TL;DR The ability of an attacker controlling one domain to compromise another through an Active Directory (AD) trust depends on the trust type and configuration. To better map these relationships and make it easier to identify cross-domain attack paths, we are replacing the TrustedBy edge in BloodHound with new trust edges. We are also improving the coverage of AD special identities and introducing modeling of the trust account attack to provide a more complete picture of attack paths across trusts.

All BloodHound updates in this blog post apply to both BloodHound Community Edition and BloodHound Enterprise.

AD Trusts 101

An AD trust lets users from one domain access resources in another. The direction of access is opposite to the direction of the trust itself: the trusted domain is the one gaining access:

At first, this might seem counterintuitive, but it makes sense when you consider the trusted domain as the one “trusted” to access resources.

When you create a new domain in an AD forest, AD automatically creates a bidirectional, transitive trust with the parent or root domain. As a result, all domains within a forest inherently trust each other. The intraforest trust types are:

• ParentChild
• TreeRoot
• ShortCut

You can manually establish trusts between domains in different forests. The interforest trust types are:

• Forest
• External
• Realm

For now, just remember that some trusts apply within a forest and others connect domains across different forests. For a deeper dive, I recommend Microsoft’s classic Domain and Forest Trusts Technical Reference.

The TrustedBy Edge

Until version 7.4, BloodHound used the TrustedBy edge to model AD trusts. As the name suggests, this edge points in the opposite direction of the trust itself – that is, it follows the direction of access.

This design originally made sense for two reasons:

1. BloodHound edges typically follow the flow of access, control, or attack opportunities to reveal potential attack paths
   
2. At the time, SID-History Injection was the only publicly well-known trust attack technique. Under the right conditions, it enabled attackers to jump directly from one domain to full control of another. This attack also followed the direction of access

The TrustedBy Issue

The TrustedBy edge is traversable, meaning that it is included when you use the pathfinding feature:

This is helpful when a trust relationship can be abused, where compromising the first domain allows an attacker to control the second. However, this is not always the case.

An AD trust relationship is abusable under two overall conditions:

• The trust is between domains within the same forest.
  Control of any domain in a forest gives indirect control over the entire forest. Microsoft highlights this clearly in their documentation: “.. a domain is not a security boundary because it is not possible for administrators from one domain to prevent a malicious administrator from another domain within the forest from accessing data in their domain.”

• The trust is between domains in different forests and has a weak configuration that enables abuse

On the other hand, an AD trust relationship is not abusable when the trust is between domains in different forests and is configured securely as by default. We will explore the specific abuse techniques and conditions in the next section.

We strive to avoid including traversable edges in BloodHound that are not always abusable, as these can create false positive attack paths. This made the TrustedBy edge problematic.

Additionally, the TrustedBy edge’s direction sometimes causes confusion. We have caught ourselves mixing this up many times. For instance, if you looked at the Inbound Trusts accordion in a domain’s node panel of BloodHound v7.3, it showed the TrustedBy edges pointing into the node. However, these edges represent the domain’s outbound trusts, not inbound ones.

The Solution: New Edges

We have resolved the issue with the TrustedBy edge by replacing it with four new edges in BloodHound v7.4.

First, we split the TrustedBy edge into two separate edges to clearly distinguish same-forest trusts from cross-forest trusts:

• SameForestTrust (traversable): Represents a trust relationship within an AD forest (intraforest trust)
• CrossForestTrust (non-traversable): Represents a trust relationship between domains in different forests (interforest trust)

The SameForestTrust and CrossForestTrust edges follow the direction of the trust itself as we determined it would be more intuitive:

With the new trust edges, you can now gain a clear overview of trust relationships, easily distinguishing between same-forest and cross-forest trusts:

BloodHound edges typically follow the direction of access to support pathfinding, so it might seem that we are breaking that principle here. However, the direction of trust edges does not have to match the direction of trust access for several reasons:

• The trust access alone is not sufficient to compromise the trusting domain. By default, users from the trusted domain only gain limited access (e.g. Authenticated Users) in the trusting domain. We will model the access provided by a trust more intelligently than just relying on the trust edge itself (see the Connecting the Special Identity Dots section)
• A trust may enable an attack depending on its type and configuration. Some trust attacks follow the direction of access, but others follow the direction of the trust. We will explore these different trust attack techniques later in the post
• For same-forest trusts (SameForestTrust edge), the edge direction does not significantly impact pathfinding. This is because within a forest, trusts are bidirectional and transitive; every domain inherently has a SameForestTrust path to every other domain in both directions
• The CrossForestTrust edge is non-traversable, meaning it is excluded from pathfinding, so its direction does not affect pathfinding outcomes

As CrossForestTrust edges are non-traversable, they prevent false positive attack paths through cross-forest trusts that cannot be abused; however, we still want to see paths when a cross-forest trust configuration is abusable. To address this, we have introduced two additional traversable edges for cross-forest trusts with an abusable configuration:

• AbuseTGTDelegation (traversable): Added alongside a CrossForestTrust edge when the trust has ticket-granting ticket (TGT) delegation enabled
• SpoofSIDHistory (traversable): Added alongside a CrossForestTrust edge when the trust has security identifier (SID) history enabled

These additional edges make it easy to identify cross-forest trusts with weak configurations that allow attacks. The AbuseTGTDelegation and SpoofSIDHistory edges follow the direction of the attack, consistent with all other traversable edges:

Let us now explore the details of the new edges.

SameForestTrust

The SameForestTrust edge represents a trust relationship between two domains within the same AD forest. In this relationship, the source node domain has a same-forest (intraforest) trust to the destination node domain, allowing users and computers from the destination domain to access resources in the source domain.

Because the domains are part of the same forest, they inherently trust each other. As a result, every domain has a SameForestTrust path to every other domain in the same forest in both directions.

Abuse

An attacker with control over any domain within the forest can escalate their privileges to compromise other domains through multiple methods.

Spoof SID History (SID-History Injection)

An attacker can spoof the SID history of a principal in the target domain, tricking the target domain into treating the attacker as a privileged user. This attack fails if SID filtering (i.e., quarantine) is enabled on the trust relationship in the opposite direction of the attack. The SID filtering blocks SIDs belonging to any other domain than the attacker-controlled domain; however, enabling quarantine is rare and generally not recommended for same-forest trusts.

See this blog post by Sean Metcalf for further details: Kerberos Golden Tickets are Now More Golden. 

​Coerce to TGT

An attacker can coerce a privileged computer (e.g., a domain controller [DC]) in the target domain to authenticate to an attacker-controlled computer configured with unconstrained delegation. This provides the attacker with a Kerberos TGT for the coerced computer. The attack fails if SID filtering (i.e., quarantine) is enabled, as this prevents TGTs from being sent across the trust boundary. Again, this setting is rarely configured.

Will (harmj0y) Schroeder wrote about this attack technique in the Not A Security Boundary: Breaking Forest Trusts blog post. While the post focuses on executing the attack across a forest trust, it also highlights that the same technique is effective within a forest.

​ADCS ESC5

The Configuration Naming Context (NC) is a forest-wide partition any writable DC within the forest can write to. Most AD Certificate Services (ADCS) configurations are stored in the Configuration NC. An attacker can abuse a DC to modify ADCS configurations to enable an ADCS domain escalation opportunity that compromises the entire forest. If ADCS is not installed; an attacker can install ADCS and exploit it.

See this blog post by Andy Robbins for further details: From DA to EA with ESC5.

GPO Linked on Site

AD sites are also stored in the forest-wide Configuration NC partition. An attacker can abuse a DC to link a malicious group policy object (GPO) to the site of any DC in the forest.

See the ‘GPO on site attack’ section of this blog post by Martin Sohn Christensen, Tobias Torp, and myself: SID Filter as Security Boundary Between Domains? (Part 4) – Bypass SID Filtering Research.

For more information about the edge, check out the edge entity panel in BloodHound or read the edge documentation here: BloodHound Docs: SameForestTrust.

CrossForestTrust

The CrossForestTrust edge represents a trust relationship between two domains of separate forests. In this relationship, the source node domain has a cross-forest (i.e., interforest) trust to the destination node domain, allowing users and computers from the destination domain to access resources in the source domain.

Abuse

BloodHound creates separate traversable edges between the domains if the configuration of the trust enables abuse. For more information about the edge, check out the edge entity panel in BloodHound, or read the edge documentation here: BloodHound Docs: CrossForestTrust.

TrustAttributes​ – it’s OK to Disagree

Before we dive into the AbuseTGTDelegation and SpoofSIDHistory edges, we need to explain how trust attributes work. The trustAttributes AD attribute holds the most important configuration settings for a trust relationship. This attribute exists on the Trusted Domain Object (TDO) for the trust. Each side of the trust has its own TDO, even for one-way trusts.

The trustAttributes value defines:

• TGT delegation: Determines whether TGTs are allowed to cross the trust
• SID filtering: Specifies which SIDs are filtered when accessing resources across the trust
• … and other security-related settings

Here is where things get tricky: Changing the trustAttributes value on one side of a trust does not automatically update the other side. For example, if you enable TGT delegation on one side of a one-way trust, the other side will still report that it is disabled:

It is even possible to create a situation where one side reports the trust as an external trust while the other side sees it as a forest trust.

I have also experienced that Get-ADTrust returns straight up wrong information. I executed the commands of the above screenshot as a user of target.local on an attacker.local host, but when I checked the values locally in target.local, I got a different result. Here, the inbound trust reported as having TGT delegation disabled, despite the same, correct TrustAttributes value:

This was wrong. I verified with a test that TGT delegation was enabled. The wrong value was also returned after a reboot. Therefore – check the trustAttributes value as it reports the raw LDAP value.

For bidirectional trusts, it makes sense that you can enable or disable settings for access in one direction only, which can lead to conflicting trustAttributes values. However, it is still not always clear which direction a particular trustAttributes flag applies to. For instance, if a bidirectional trust has TGT delegation enabled on one side, does that side send TGTs to the other side, or does it refuse to accept TGTs from the other side? You will need to dive into Microsoft’s documentation to determine the exact behavior.

Microsoft has made auditing trusts quite challenging. Both sides of a trust can report the configuration, but you need to know which side holds the truth for each setting and what direction it impacts. And even then, you cannot fully trust Microsoft’s own tool for checking the trust configuration, which is almost ironic.

I never figured out why Get-ADTrust returned a wrong value for TGT delegation. The best theory I have is this one I got from my manager:

TrustAttributes in BloodHound

In BloodHound, we now collect and store the trustAttributes settings from both sides of the trust as properties on the trust edges:

• Trust Attributes (Inbound): The value collected from the domain where the trust is inbound
• Trust Attributes (Outbound): The value collected from the domain where the trust is outbound

We have also updated the logic for the two most important trust edge properties, Spoof SID History Blocked and TGT Delegation, such that they are only created if you have collected data from the side of the trust that holds the truth.

Spoof SID History Blocked (True/False)

An attacker with control over the trusted domain may attempt to escalate privileges in the trusting domain using a spoof SID history attack by injecting the SID of a privileged principal from the trusting domain into their authentication request. However, SID filtering can prevent this attack.

SID filtering removes domain SIDs from authentication requests of foreign principals based on the trust configuration. Built-in SIDs (S-1-5-32-*) are always filtered, regardless of the configuration. 

SID filtering blocks the spoof SID history attack over same-forest trusts when the trust is configured in quarantine mode (i.e., trustAttributes flag QUARANTINED_DOMAIN enabled), which filters out SIDs that do not belong to the trusted domain. Same-forest trusts do not have quarantine mode enabled by default.

For cross-forest trusts, blocking spoof SID history attacks requires filtering out SIDs that do not belong to the forest of the trusted domain, which happens by default. 

Forest trusts filter out SIDs that do not belong to the forest of the trusted domain, but SID filtering for forest trusts can be relaxed by enabling the trustAttributes flag TREAT_AS_EXTERNAL. When enabled, SID filtering behaves like it does for external trusts (without quarantine mode), meaning only SIDs with a RID below 1000 (default AD principals) are filtered, allowing a potential spoof SID history attack.

External trusts have quarantine mode enabled by default to protect the trusting domain. An external trust with quarantine mode disabled does not block spoof SID history attacks.

SID filtering is controlled from the domain where the trust is outbound. As a result, this property is only created if trust data from the outbound side has been ingested.

TGT Delegation (True/False)

TGT delegation determines whether TGTs are allowed to be sent over the trust. When a principal from the trusted domain authenticates against a Kerberos resource with unconstrained delegation in the trusting domain, their Kerberos TGT is forwarded to the resource as part of Kerberos authentication, but only if TGT delegation is enabled (true).

TGT delegation is enabled for same-forest trusts by default. It is disabled if quarantine mode (trustAttributes flag QUARANTINED_DOMAIN) is enabled. 

By default, TGT delegation is disabled for cross-forest trusts. It is enabled if the trustAttributes flag CROSS_ORGANIZATION_ENABLE_TGT_DELEGATION is enabled, unless quarantine mode is enabled.

TGT delegation is controlled from the domain where the trust is inbound and the property is therefore only created if trust data from this side has been ingested.

AbuseTGTDelegation

The cross-forest trust from the target node domain to the source node domain has TGT delegation enabled.

When a resource in the source node domain is configured with unconstrained delegation, principals from the target node domain will automatically forward their TGT to that resource upon access.

This edge models the attack technique of the blog post Not A Security Boundary: Breaking Forest Trusts by Will (harmj0y) Schroeder.

Note that this attack goes in the direction of the trust and against the direction of access.

​Abuse

TGT delegation allows an attacker to capture TGTs of privileged users or computers in the target domain when they authenticate against a system configured with unconstrained delegation.

A common attack method involves the attacker logging into a DC of the source domain and coercing a DC of the target domain. Since DCs have unconstrained delegation enabled by default, this grants the attacker a TGT for a target domain DC, which can then be used to perform a DCSync attack on the target domain.

Alternatively, attackers can target other privileged computers or users besides DCs.

Authenticated Users access is required in the target domain to coerce the target computer. If the trust relationship is bidirectional, all principals in the source domain have this access by default. If not, coercion must be executed as a principal from the target forest. Attackers can obtain such a session using the trust account attack, which we will cover in the next section.

The attack will fail if the target is a member of Protected Users or is marked as not trusted for delegation, as their TGTs will not be sent to hosts with unconstrained delegation. This configuration is however very uncommon for computers. 

Read the edge documentation for more information: BloodHound Docs: AbuseTGTDelegation.

SpoofSIDHistory

The cross-forest trust from the target domain to the source domain has a weak SID filtering configuration.

The target domain allows principals of the source domain access by SIDs of the target domain in their SID history. An attacker with control over the source domain can craft access requests with manipulated SID history containing SIDs of privileged principals of the target domain to gain control over the target domain.

This edge models the attack technique of the blog post Active Directory Forest Trusts Part 1 – How Does SID Filtering Work? by Dirk-jan Mollema.

Abuse

When spoofing SID history over a same-forest trust, you can use any domain SID from the target domain. The most common choice is the Enterprise Admins SID, as it grants full control over the target domain.

Spoofing SID history over a cross-forest trust is more restricted. In this scenario, SID filtering removes SIDs with a RID below 1000, meaning you cannot use default AD groups like Domain Admins and Enterprise Admins. Additionally, group memberships for global and universal groups are not applied based on SID history, making accounts in groups like Domain Admins and Enterprise Admins ineffective as targets.

The attack target must be a user, computer, or a custom group with permissions granted directly or through built-in/domain local groups (NOT through membership of global/universal groups).

Common viable targets with indirect full control over the environment include:

• The Exchange Windows Permissions group
• Entra ID sync (MSOL_) accounts
• Custom groups with administrative control over Tier Zero assets

Alternatively, an attacker can target a DC and use resource-based constrained delegation (RBCD) to obtain a local TGT as the DC, which can then be used for a DCSync attack on the target domain. However, the RBCD attack requires control over an account (user or computer) in the target forest. If no such account is available and the default permissions for creating computers have not been restricted, the attacker can first spoof SID history against a target with permissions to create computer accounts, to then perform the RBCD attack against a DC.

The spoofed SID can be added to SID history at three different levels for the attacker-controlled principal of the trusted domain:

• In the principal’s SID History AD attribute
• In the principal’s Kerberos TGT
• In the principal’s Kerberos interforest TGT

The first option enables the attack over both Kerberos and NTLM, whereas the latter two only apply to Kerberos authentication. However, modifying the SID History attribute is risky — it cannot be edited directly via LDAP or built-in AD tools. Mimikatz supports modifying it with the command sid::patch followed by sid::add, but sid::patch does not work on Windows Server 2016 and later. It is possible to modify the SID History attribute using the DSInternals command Add-ADDBSidHistory, but this requires stopping and restarting the NTDS service, which is not recommended in a production environment. The second and third options are safer.

Read the edge documentation for more information: BloodHound docs: SpoofSIDHistory.

Connecting the Special Identity Dots

What access do you gain when a domain trusts your domain? You can be granted custom permissions in the trusting domain, but you automatically gain the access of Special Identity groups such as Authenticated Users and Everyone.

What are special identity groups? Special identities, or special identity groups, function similarly to AD groups in that they contain members and can be assigned permissions within Windows and AD. However, unlike regular AD groups, their members cannot be manually modified. Instead, whether a principal is a member is determined dynamically during authentication based on predefined criteria. Example: The special identity Network (S-1-5-2) is assigned to any principal that authenticates to Windows over the network rather than via console logon.

So far, BloodHound’s coverage of special identities has been limited. We have made two key changes to improve the discovery of attack paths involving these identities. These changes are not live in BloodHound yet but will be released this summer (2025).

1) Adding Authenticated Users and Everyone memberships across trusts

For all SameForestTrust and CrossForestTrust edges, we now add Authenticated Users from the trusted domain as members of Authenticated Users in the trusting domain. We apply the same logic for Everyone:

This enhancement allows you to uncover attack paths that traverse Authenticated Users and Everyone permissions in other domains.

2) ClaimSpecialIdentity edge

The ClaimSpecialIdentity edge represents the ability to obtain an access token containing a special identity (group) SID:

The special identity groups are represented as regular group nodes, just like Authenticated Users and Everyone have always been. The ClaimSpecialIdentity edge starts at Everyone, and goes to special identity groups “everyone” can claim. For example, everyone can authenticate to AD over the network and obtain an access token with Network identity SID.

Some of the special identity groups are more complex than the Network identity and require additional explanation to understand how you get their SIDs included in your access token. You can check the information about the special identity groups connected by the ClaimSpecialIdentity edge in the edge documentation: BloodHound Docs: ClaimSpecialIdentity (this page will be live when the feature has been released).

Selective authentication

You can control access across a cross-forest trust with more granularity by enabling selective authentication. When enabled, an administrator of the trusting forest must manually grant Allowed to Authenticate permission to principals of the trusted domain for them to access resources:

• Active Directory (LDAP) access: Requires Allowed to Authenticate on the DC’s computer object
• Access to a host or service running as SYSTEM: Requires Allowed to Authenticate on the host’s computer object
• Access to a service running as a service account: Requires Allowed to Authenticate on the service account object

BloodHound does not account for selective authentication. Modeling the effective permission in a meaningful way would be challenging, and selective authentication appears to be rarely used in practice.

Transitivity restrictions

Trusts are generally transitive, which means that DomainA and DomainC trust each other in a chain like DomainA <-> DomainB <-> DomainC. However, there are two main exceptions:

• External trusts
  These are not transitive. That said, attackers can bypass this limitation, as Charlie Clark has documented here: External Trusts Are Evil

• Trust chained through multiple forests
  In a configuration like ForestA <-> ForestB <-> ForestC, ForestA and ForestC do not trust each other. An attacker in ForestA cannot directly access ForestC. However, if they compromise a user or computer in ForestB, they can then access ForestC

BloodHound does not model transitivity restrictions for two reasons:

1. It is complex to represent restrictions that block path traversal of certain edges depending on the start and end node
2. You can often bypass transitivity restrictions in practice

Trust Account Attack

When you use a domain account to authenticate within its own domain, you receive a Kerberos TGT encrypted with the password of the krbtgt account. When you instead request access to a service in a remote domain, the local domain issues an inter-realm TGT. This TGT is encrypted with a trust key, which can be used to access services in the remote domain. The remote domain also holds a copy of this trust key, allowing it to decrypt the inter-realm TGT and grant access.

The trust key is derived from the password of a trust account: an account similar to krbtgt. This trust account exists in the remote domain. A key difference from the krbtgt account is that the trust account is enabled and you can perform Kerberos authentication with it. Furthermore, the account has Domain Users as its primary group, unless the domain level is Server 2025, as Tobias Torp discovered, in which case the primary group is the undocumented “External Trust Accounts.”

An attacker who compromises a domain can extract the trust keys and use them to authenticate to remote domains via the trust account. This allows the attacker to gain Authenticated Users access (and often Domain Users and Users access) in the remote domain – even if the compromised domain is not trusted. This low-privileged access is frequently enough to escalate to full control, unfortunately. For instance, coercion attacks typically require only Authenticated Users access.

You can find a detailed description of the trust account attack in the blog post SID Filter as Security Boundary Between Domains? (Part 7) – Trust Account Attack – From Trusting to Trusted by Martin Sohn Christensen, Tobias Torp, and myself. 

HasTrustKeys Edge

The new HasTrustKeys edge is introduced with BloodHound v7.5. It connects a domain node (i.e., source) to a trust account node (i.e., target). The source domain holds the trust keys for the trust account in the target domain. This trust account exists because the source domain has an outbound trust to the trust account’s domain.

Who Can Create Trusts?

Membership in Enterprise Admins or Domain Admins is required to create trusts. However, there is one exception: members of the Incoming Forest Trust Builders group can create inbound forest trusts, as the group holds the Create-Inbound-Forest-Trust extended right on the forest root domain. 

Can attackers abuse this permission to compromise the forest? Yes! In fact, I am releasing a second blog post today that explains how you can abuse this permission: Untrustworthy Trust Builders: Account Operators Replicating Trust Attack (AORTA)

Audit Your Trusts and Security Boundaries

In my experience, organizations tend to focus too heavily on securing the domains that contain the most business-critical assets while overlooking the other trusted domains in the environment. It is essential to understand that attack paths to Tier Zero in any domain within the forest can enable an attacker to compromise the entire forest. This means that the security boundary protecting Tier Zero extends across all Tier Zero objects in all domains within the forest.

If a forest has cross-forest trust with weak configuration enabling abuse, the Tier Zero security boundary extends even further – to Tier Zero in the other forest, or in the reverse direction, depending on the enabled attack techniques.

Attack paths that originate from special identities like Authenticated Users or Everyone are particularly dangerous, as they allow principals from both the local forest and trusted domains in other forests to exploit them. Below is a visual example illustrating how an attack path from Authenticated Users to Tier Zero in a single domain can enable all principals in two forests to compromise the entire environment; completely bypassing even a perfectly tiered security architecture in the main domain:

Final Words

If you would like to explore security boundaries and attacks within an AD forest – presented with a thick Danish accent – I recommend watching the recording of my Security Boundaries Within an Active Directory Forest talk from SO-CON.

For those more interested in cross-forest attack paths (also presented with a thick Danish accent), keep an eye out for the recording of my Breaking Boundaries: Unraveling AD Cross-Forest Attack Paths talk on the Troopers YouTube channel. 

The new trust edges in BloodHound are designed to make life easier for everyone, whether you are a red teamer looking for the shortest path to your target, or a defensive operator managing attack paths. In any case, we value your feedback. You can always find me and other Specters in the BloodHoundGang community Slack.