Your Trust Doesn't Matter
AD Non-Transitive Trusts are broken - and Microsoft aren't going to fix it
Non-transitive trusts (a.k.a external trusts) - as described by Microsoft - are designed to “deny trust relationships with other domains”, or in other words, only the two domains involved in the trust will be able to authenticate to each other.
Unfortunately, researchers from Semperis have discovered that non-transitive trusts can - contrary to their design intent - allow authentication across domains, as well as potential privilege escalation within the trusting domain.
Breaking the Trust
In the diagram below, a non-transitive trust exists between semperisaz.lab and grandchild1.child1.semperis.lab. This allows for a referral TGT - which is used to request Service Tickets for any service within domains with an established trust path - to be requested for grandchild1.child1.semperis.lab.
However because it’s a non-transitive trust - there isn’t a trust path between semperisaz.lab and semperis.lab, and attempting to obtain a referral to this domain fails - as expected.
The way to circumvent this protection is through using a “local” TGT - i.e. a TGT for grandchild1.child1.semperis.lab (the domain for which the non-transitive trust exists) instead of semperis.lab - to request the referral for the domain for which no direct trust exists.
While this technique stops short of allowing an attacker to perform “trust hopping” into another forest, Semperis points out the implications of even this limited scope.
“Attackers could query domain information from supposedly disallowed domains, query more sensitive domains or domains with potentially weaker security, or perform Kerberoasting attacks or NTLM authentication coercion on domains that are assumed to be disallowed.”
Opalsec is a reader-supported publication. To receive new posts and support my work, please consider becoming a paid subscriber!
Pivoting using machine accounts
Semperis have been able to chain this technique with one they previously disclosed, in order to extend the use of local TGTs to enable trust hopping to a forest with which no trusts exist.
Continuing from where the previous scenario left off, the referral TGT for the semperis.lab domain can be used to retrieve a Service Ticket for the LDAP service, which can then be abused to create a machine account in that domain.
This account essentially serves as a beachhead within the semperis.lab domain from which we can repeat the exploitation of the flaws found in AD non-transitive trusts.
The machine account’s TGT requests a referral to the trusting domain of treetest.lab, which is then used request a “local” TGT from treetest.lab.
This local TGT can then be used to request a referral from the DC of the treetest.lab domain to the dsptest.lab domain - which should have been out-of-bounds of an account in semperis.lab, according to the design intent of non-transitive trusts.
Found this useful? Why not share it!
“It’s not a vulnerability, so - no.”
Unfortunately, Microsoft believe this flaw can’t be classified as a vulnerability, and as such - won’t be taking any action to rectify it.
The only “fix” to the solution is to disable any non-transitive trusts you may have in your environment.
Failing that, Semperis recommend auditing Windows 4769 events (A Kerberos service ticket was requested), specifically:
- Where a local TGT is requested - the domain (Account Domain field) is for a different forest, and the Service Name is krbtgt;
- A second event which follows, requesting a referral TGT - the domain (Account Domain field) is a domain in a different forest, and the Service Name is another domain within the local forest.
They also recommend disallowing Authenticated Users from creating machine accounts, in order to mitigate the ability to extend this flaw into additional forests.
Opalsec is a reader-supported publication. To receive new posts and support my work, please consider becoming a paid subscriber!
