Not A Security Boundary: Breaking Forest Trusts

For years Microsoft has stated that the forest was the security boundary in Active Directory. For example, Microsoft’s “ What Are Domains and Forests? ” document (last updated in 2014) has a “ Forests as Security Boundaries ” section which states (emphasis added):

Each forest is a single instance of the directory, the top-level Active Directory container, and a security boundary for all objects that are located in the forest. This security boundary defines the scope of authority of the administrators. In general, a security boundary is defined by the top-level container for which no administrator external to the container can take control away from administrators within the container. As shown in the following figure, no administrators from outside a forest can control access to information inside the forest unless first given permission to do so by the administrators within the forest.

Unfortunately, this is not the case. The forest is no longer a security boundary.

By applying the MS-RPRN abuse issue (previously reported to Microsoft Security Response Center by my workmate Lee Christensen ) with various trust scenarios, we determined that administrators from one forest can in fact compromise resources in a forest that it shares a two-way interforest trust with. For more information on Lee’s MS-RPRN abuse (a legacy printer protocol “feature”) check out the DerbyCon 2018 “ The Unintended Risks of Trusting Active Directory ” presentation that my workmates @tifkin_ , @enigma0x3 , and myself gave this year. For more background on trusts, check out my “ Guide to Attacking Domain Trusts ” from last year.

The tl;dr non-technical explanation of “Why Care?” is that if your organization has a two-way forest trust (possibly ‘external’ trusts as well, more on that later) with another Active Directory forest, and if an attacker can compromise a single machine with unconstrained delegation (e.g. a domain controller) in that foreign forest, then they can leverage this to compromise your forest and every domain within it. In our opinion, this is very bad.

The tl;dr technical explanation is due to several default Active Directory forest configurations (detailed in the “ Attack Explanation ” section below) an attacker who compromises a domain controller in a forest (or any server with unconstrained delegation in said forest) can coerce domain controllers in foreign forests to authenticate to the attacker-controlled server through “ the printer bug. ” Due to various delegation settings, the foreign domain controller’s ticket-granting-ticket (TGT) can be extracted on the attacker-controlled server, reapplied, and used to compromise the credential material in the foreign forest.

This issue was reported to Microsoft’s Security Response center, and the associated teams determined that this was an issue best resolved via v.Next, meaning it may be fixed in a future version of windows. There is more detail concerning their response and my subsequent thoughts in the “ Microsoft’s Response and My Thoughts ” section at the bottom of this post. Also later in the post is mitigation guidance, and my teammate Roberto Rodriquez has a defensive post on complete detective guidance titled “ Hunting in Active Directory: Unconstrained Delegation & Forests Trusts “.

Vulnerability Attack Explanation

There are four main “features” in a default Active Forest installation that allow this attack to happen.

Writable domain controllers in default domain deployments are configured to allow unconstrained delegation. This means that any user that does not have the “Account is sensitive and cannot be delegated” setting on their account or is not contained within the “ Protected Users ” group will send their TGT within a service ticket when accessing a server with unconstrained delegation. From what we can tell, and from those we’ve spoken to, domain controller accounts themselves are almost never granted these protections- they are almost always applied just to domain administrator accounts. For more information on unconstrained delegation, check out Sean Metcalf ’s post on the subject , or the DerbyCon 2018 “ The Unintended Risks of Trusting Active Directory ” presentation that my workmates @tifkin_ , @enigma0x3 , and myself gave this year. According to Microsoft, “ When full delegation is enabled for Kerberos on a server, the server can use the delegated ticket-granting ticket (TGT) to connect as the user to any server, including those across a one way trust . “ This means that delegated TGT tickets can cross interforest trust boundaries. This behavior is enabled by default but can be manually blocked- see the “ Attack Mitigations ” section later in this post for guidance. The abuse of the previously-reported RpcRemoteFindFirstPrinterChangeNotification(Ex) RPC call (aka MS-RPRN abuse, “the printer bug”) allows any domain member of “Authenticated Users” to force any machine running the Spooler service to authenticate to a target of the attacker’s choice via Kerberos or NTLM. Again, for more information on Lee’s “printer bug”, check out our DerbyCon talk . Finally, according to Microsoft, “ When users authenticate from a trusted forest, they receive the Authenticated Users SID in their token. Many of the default rights for users in a forest are granted through the Authenticated Users. ” This means that any user in a trusted forest can execute the “printer bug” against machines in a foreign forest, as “Authenticated Users” is all the access needed to trigger the forced authentication.

Combined together, this means that if FORESTA has a two way interforest trust with FORESTB, then the compromise of any domain controller (or any server with unconstrained delegation) in FORESTB can be leveraged to compromise the FORESTA forest root (or vice versa) and all domains within it!

To execute this attack (using currently public tools) an attacker would:

Compromise any server with unconstrained delegation, for example a domain controller (e.g. DCB) in FORESTB. Begin monitoring for 4624 logon events on the compromised FORESTB server, extracting new TGTs from any new logon sessions through established LSA APIs. This can be done with Rubeus ’ monitor action. Trigger the MS-RPRN “printer bug” against a domain controller (e.g. DCA) in FORESTA. This can be done with Lee’s proof of concept code . FORESTA’s domain controller will authenticate to the attacker-controlled server in FORESTB with the FORESTA domain controller machine account (DCA$ in this case). The TGT of FORESTA’s DC will be contained within the service ticket sent to the attacker-controlled server and cached in memory for a short period of time. The attacker extracts the foreign domain controller’s TGT using established LSA APIs, and applies the TGT to the current (or another) logon session. This can again be done using Rubeus . The attacker executes a DCSYNC attack against FORESTA to retrieve privileged credential material in FORESTA (such as the hash of the FORESTA\krbtgt account).

Here’s a diagram of what’s happening:

Kind of make sense? How about seeing the attack work in action.

The following screenshots show compromising FORESTA.LOCAL from the domain controller DCB.FORESTB.LOCAL :

The following screenshot shows compromising FORESTB.LOCAL from the domain controller DCA.FORESTA.LOCAL :

Or check out this demonstration video of the entire attack.

This attack also provides an alternative way to escalate from a child domain to the root domain within the same forest , similar to the abuse of sidHistory in Golden Tickets discovered by Sean Metcalf and Benjamin Delpy in 2015. However, as the forest is specified as the trust boundary, this is not quite as interesting as the compromise of interforest trusts that this new attack entails.

Again, as a tl;dr the compromise of any server with unconstrained delegation (domain controller or otherwise) can not only be leveraged to compromise the current domain and/or any domains in the current forest, but also any/all domains in any foreign forest the current forest shares a two-way forest trust with!

As we stated previously, in our opinion this is very very bad. Why? This attack works with default, modern configurations for Active Directory forests as long as a two-way forest trust is in place. Also, as mentioned, this attack works from any system with unconstrained delegation enabled, not just domain controllers. Imagine this scenario:

HotStartup has a single forest with multiple domains. In one development subdomain that’s used for testing and not as monitored/protected as the production domain, an administrator provisions a testing server with unconstrained delegation (for some reason). This server is used and not deprovisioned due to an oversight, and the fact that it’s in the development domain. SuperMegaCorp purchases HotStartup and establishes a two-way forest trust between the two forests using Microsoft’s existing trust guidance. An attacker is able to compromise the development unconstrained delegation server. The attacker executes this attack against a domain controller in SuperMegaCorp and is able to compromise all resources in the SuperMegaCorp forest.

So what if SuperMegaCorp (or HotStartup ) performed proper network segmentation and the development server is restricted from talking to machines outside its development subdomain? Well, domain controllers have to be able to talk to each other for replication to occur. The attacker could use the unconstrained dev server compromise to compromise the development subdomain via the attack, perform the attack again to hop from the development subdomain domain controller to the production domain controller, and perform the attack a third time to compromise SuperMegaCorp ‘s forest. This is marginally better than no segmentation, as it forces an attacker to log onto various domain controllers to perform the attack (instead of from ANY unconstrained server) but the attack chain is still feasible.

Like we stated, we believe this is bad.

A note on one-way trusts

We tested the one-way interforest trust scenario, where FORESTB.LOCAL trusts > FORESTA.LOCAL, but we were unable to get the attack working in either direction (FORESTA to FORESTB nor FORESTB to FORESTA).

We believe this is because while delegation TGTs can flow from FORESTA to FORESTB in this case, users in FORESTB cannot authenticate to FORESTA, so they do not receive a referral ticket with “Authenticated Users” within in it. This means that the printer bug cannot be triggered against FORESTA’s DC from FORESTB. In the reverse direction, while users from FORESTA can trigger the printer bug against DCs in FORESTB, as delegated TGTs cannot flow from FORESTB to FORESTA the attack as also n