Benjamin Delpy (@gentilkiwi) recently tweeted about adding External SIDs into Mimikatz’s golden tickets which was quickly followed up by Skip Duckwall (@Passingthehash) also tweeting how devastating this addition can be to defenders. Skip said it best by saying, “Pwning the child can (with default settings) compromise the parent”. This capability has a fairly significant impact for both attackers and defenders. If as an attacker I can just target the weakest child domain and leverage that access to compromise the parent domain, my attack path just potentially became significantly easier. As a defender, I now know that if any child domain is compromised, then the integrity of the forest as a whole is now in jeopardy.
This was something that I really wanted to test myself, so I did just that. I set up a parent (sonofflynnlab.com) and child (child.sonofflynnlab.com) domain in my home lab with workstations in each respective domain. I used the default settings when creating the child domain within the parent domain. There’s a total of four normal user accounts:
- test1 and test2 – Members of the parent domain’s (SONOFFLYNNLAB) Domain Users group
- testc1 and testc2 – Members of the child domain’s (CHILD.SONOFFLYNNLAB) Domain Users group
Once both domains were created and populated with user and computer accounts, I wanted to test the relationship between the two domains. One of the easiest ways to do this is to use Veil-Powerview, which is part of the Veil-Framework’s Powertools and developed by Will Schroeder (@harmj0y). I ran Invoke-MapDomainTrusts to view the relationship between the two domains and received the following output:
As you can see, there’s a bidirectional trust between the child and parent domain. Now that it looks like I have everything setup the way I would like it to be, it’s time to test creating a golden ticket with an external SID. To give some context to how I am testing this scenario, I will be running all commands from a workstation within the child domain and will be logged into the workstation in the context of a user within the child domain.
The first step I will perform is to download Mimikatz onto this workstation and purge all kerberos tickets.
Next, lets build the golden ticket with the external/parent SID information. The golden ticket is built with all the same information as a normal golden ticket with the addition of the external SID via the /sids flag. At this point, I’m going to assume that you have already obtained the krbtgt hash, and domain sid of the child domain. If you need help finding this information, review this post. However, the new piece of information that we will need to grab is the SID of the parent domain, and the RID of the group we want to “add” the user to. One way to obtain this is to utilize PowerView. I can use the Get-NetLocalGroup command to find the SID of the domain with the following command (since my machine can currently hit the parent domain’s DC):
Once I’ve obtained all the information I need, it’s time to create the golden ticket.
In this case, you can see I am referencing the 519 group which is the Enterprise Admins group within the external SID. If you are looking to change the group you wish to “add” yourself into, some default group values are available here. I’m also using /ptt to immediately submit the ticket.
Now that my ticket has been submitted, it’s time to open a command prompt with the submitted ticket applied to it.
Sweet! My normal domain user account within the child domain now has access to not only the child domain’s domain controller’s C$ share, but I can also access the C$ share on the parent domain’s domain controller since I am essentially running in the context of an Enterprise Admin!
At this point, I can leverage any number of techniques to move into the parent domain. Needless to say, this is something that I will look for on future assessments.