I’ve talked about domain trusts more than many people probably care about. A few weeks ago I posted “Domain Trusts: We’re Not Done Yet” – apparently there’s even more!
I’ve said before that trusts will not let you magically exploit a domain. I now need to add one caveat to that statement concerning Golden Tickets and external sids, as some recent work in this area from Sean Metcalf and Benjamin Delpy will likely change the way we operate. Sean presented on this during his “Red vs. Blue: Modern Active Directory Attacks, Detection, & Protection” Blackhat presentation, and has a post up on his site on this topic as well.
The Mimikatz Trustpocalypse
Bejamin recently released yet another tweet recently, one that has major major implications for domain trust exploitation. Take a look at the tweet and see what you think:
So what’s going on here? Mimikatz’s functionality can now include extra account SIDs from other domains when it constructs a Golden Ticket. It does this by setting the ExtraSids section of the KERB_VALIDATION_INFO structure created for the ticket (the structure that “defines the user’s logon and authorization information provided by the DC“). The ExtraSids section is described as “A pointer to a list of KERB_SID_AND_ATTRIBUTES structures that contain a list of SIDs corresponding to groups in domains other than the account domain to which the principal belongs” (the KERB_SID_AND_ATTRIBUTES structure is defined here).
The key here is that if you compromise the krbtgt hash of a child domain in a forest, add S-1-5-21-<RootDomain>-519 to the ticket created using the /sids flag. This will effectively set the SID history for the ticket you’ve created to be the “Enterprise Admins” of the root, allowing you to a domain controller of the root as an enterprise administrator. I repeat: if you compromise the domain controller of a child domain in a forest, you can compromise its entire parent domain. Any domain controller compromise in a forest can result in a compromise of the ENTIRE forest!
Let’s see this in action. In the following setup, the root of the forest is testlab.local and its domain controller is PRIMARY. The child domain is dev.testlab.local and its domain controller is SECONDARY, which we’ve compromised and extracted the krbtgt hash from. I’m running actions from WINDOWS4.dev.testlab.local, so a workstation in the child domain, as an unprivileged user ‘dev\john’:
The following shows that dev\john does not have access to PRIMARY and SECONDARY, as it should be:
Now, let’s construct and inject a Golden Ticket with the krbtgt hash from SECONDARY.dev.testlab.local (SID: S-1-5-21-4275052721-3205085442-2770241942) and add the “Enterprise Admins” SID for testlab.local (S-1-5-21-456218688-4216621462-1491369290-519):
Now, you would think that we should only be able to access SECONDARY.dev.testlab.local with this ticket as it was constructed with SECONDARY‘s krbtgt hash. However, we also have access to the root domain controller, PRIMARY.testlab.local !
We’ve compromised a root domain solely through compromise of one of its children without modifying anything in either domain. Mind, blown!
Something to note here: this will work for hopping domains in the same forest, but will fail for most external domain trust relationships. This is because Windows Server 2003 and up automatically implement a security protection called SID filter quarantining on all external trusts. SID filtering is used to “…verify that incoming authentication requests made by security principals in the trusted domain contain only SIDs of security principals in the trusted domain“. So if SID filtering isn’t enabled on an external trust for whatever reason, this attack should work, but it will likely be heavily relegated to hopping up forest trust relationships.
Update [8/8/15]
As was pointed out to me after this post went up, Microsoft has stated for years that “the forest is the security boundary for Active Directory“. That domains were the security boundary was a misconception on my part, one that I know at least some admins share based on the structure of various forests I’ve seen on engagements over the last year or so. @Meatballs__ also pointed out that this particular issue with sid history has been known for a decade, something I was also unaware of. While the structural issues has been known, integrating sid histories into golden tickets offers a distinct advantage, in that domains within the forest do not need to be modified in order to exploit the issue. Apologies for framing the issue as if it was completely new or unknown.
Does the parent domain (testlab.local) trust the child domain (dev.testlab.local) in this situation? I’m guessing not, which is why this is surprising that it works. So the big deal here is you can compromise a parent domain from a child even though the parent *does not* trust the child, correct?
Because if the parent already trusted the child, then a domain admin from the child would already have domain admin rights on the parent as shown in your other posts. Or am I misunderstanding trust relationships?
Normally, as I understand it at least (http://www.harmj0y.net/blog/redteaming/trusts-you-might-have-missed/) even though there is an implicit two way transitive trust between a parent/child domain, a trust doesn’t automatically imply elevated access EXCEPT in the case of enterprise admins. When a child domain is joined to/created in a forest, enterprise admins are automatically added to the administrative groups for the child. However this doesn’t happen going the other direction- a child domain normally doesn’t have any *obviously* implicit access to its parent.
As it was pointed out to me online, Microsoft’s guidance has been that forests are the trust boundary, NOT individual domains. However, I had the misconception that domains themselves could be treated as trust boundaries. I’ve seen many many enterprise networks designed with the same misconception, so I’m hoping it was beyond just me believing it :)
Hi,
You say that if SID filtering isn’t enabled on an external trust for whatever reason, this attack should work, but it will likely be heavily relegated to hopping up forest trust relationships.
As I pointed to Sean in his article (http://adsecurity.org/?p=1588) , even with SID Filtering disabled most of well-known Sids are always filtered from PAC (See https://msdn.microsoft.com/en-us/library/cc237940.aspx).
Regards,
Greg
Cool, thanks for pointing that out!
You’re welcome.
Another thing interesting:
When a SID is filtered out, a 4675 event is logged on a DC in the trusting domain/forest.
For example if you inject RID-512 in the SidHistory attribute of an account in the trusted domain/forest and you access a ressource in the trusting domain/forest, a 4675 event is logged.
I notice that with a TGS request made from a referral ticket crafted with Mimikatz, no 4675 event is generated when you access a resource.
Well, even with that, monitoring this kind of events is still important.
Regards,
Greg
Pingback: An Empire Case Study | enigma0x3
Is it possibe to stop this attack by applying “QuarantinedWithinForest” trust type between domains in the same forest ? Reading MSDN article I found this description of QuarantinedWithinForest trust type: ”
A parent-child trust between a leaf domain in a forest and its parent can be marked as quarantined. The only SIDs that are allowed to be passed from such a domain are the “Enterprise Domain Controllers” (S-1-5-9) SID and those described by the trusted domain object (TDO).”
The question is, does it stop tha attack and what will break after applying it ? Any ideas please ? Thanks
Honestly, I’m not sure. Do you have the syntax to set the inner-forest trust to be quarantined?
I’m assuming this is what you found https://msdn.microsoft.com/en-us/library/cc237940.aspx . Considering that the S-1-5-9 SID is still allowed, it seems that that protection (even if easily enabled) may not stop the SID-hopping approach (http://www.harmj0y.net/blog/redteaming/mimikatz-and-dcsync-and-extrasids-oh-my/).
If you can get the syntax/approach to easily setting inner-forest trust types to be quarantined I can check.
Unfortunately I don’t have the means to set the quarantined intra-forest trust type. I just passed through your blog and correspoding MSDN articles and that trust type cached my eye. Nothing more. :-(
Anyway thanks for responding.