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:
Image may be NSFW.
Clik here to view.
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':
Image may be NSFW.
Clik here to view.
Image may be NSFW.
Clik here to view.
The following shows that dev\john does not have access to PRIMARY and SECONDARY, as it should be:
Image may be NSFW.
Clik here to view.
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):
Image may be NSFW.
Clik here to view.
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 !
Image may be NSFW.
Clik here to view.
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.