Golden Tickets and External SIDs – Spread the Compromise

Note: Be sure to check out Sean Metcalf’s (@Pyrotek3) post about this technique available here!  He talked about this at BlackHat USA 2015!

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 ( and child ( 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:

3 - domaintrustsAs 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.

1 - mimikatz krb purgeNow that all tickets have been purged, let’s verify that I cannot access either the child domain’s domain controller’s C$ share, or the parent domain’s domain controller’s C$ share.

2 - cantaccessNext, 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.

pttchild 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.

4 - getshellLet’s test our access!

5 - accesstoprimarydcSweet!  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.






Mimikatz, Kiwi, and Golden Ticket Generation

First off, I want to state that the purpose of writing this post is to help myself learn how to use Golden Tickets on assessments.  If you want to see some great write-ups about Golden ticket generation, be sure to look at these:

Those posts are significantly more authoritative on the subject than mine, I just wanted to write this out so I can reference this on assessments.

Golden tickets can offer an extremely powerful to escalate privileges for an attacker on a network, or obtain access to resources which are only available to a select group.  However, it’s absolutely worth mentioning that with this great power, pen testers need to take extra precaution to protect any golden tickets that they’ve created.  It’s highly recommended that any tickets created should be securely encrypted during your assessment, and securely deleted when it is no longer needed.

Golden Tickets can be generated two different ways.  The first way is through the kiwi extension in Metasploit, and the other is through Mimikatz’s stand alone application.  This post will show how to use both options to generate your ticket.  Lets start off with Metasploit’s Kiwi Extension.

At this point, I am going to assume that you have a meterpreter session, as SYSTEM, on the domain controller for the domain you are targeting.  Within your session, you want to load the kiwi extension by typing:

load kiwi

Load Kiwi

Now that the kiwi extension is loaded, when you type help, you should see the additional commands that are available for you.  The command that we’re interested in is golden_ticket_create.  In order to create the golden ticket, we’re going to need at least four pieces of information (tickets can be further customized with additional information, but the generation process needs a minimum of four):

  • The Domain Name
  • The Domain SID
  • The krbtgt account’s nt hash
  • The user account you want to create the ticket for

MSF Golden Ticket Create

To get this information, you can just interact with the meterpreter session you already have active.  Drop into a shell, and run:

whoami /user

Domain Sid

The domain SID starts at the S-1… and goes to …70370.  Copy and paste that information into a text file.  Next up, grab the domain name.  One way I like to do this is just running:

ipconfig /all

Find Domain Name

In this case, I can see (and I know) the domain name is  So, this info should also be saved off to a text file.  The last big hurdle that you will need is the nt hash from the krbtgt account.  Since you should be on the DC, perform a hashdump and obtain the krbtgt hash.

Now that we have all of the required information, we can generate a golden ticket!  At this time, go ahead and determine the user account you are wanting to impersonate, or, you can actually use an account that is nonexistent.  Now, it’s just getting everything in place for the command.  In our case, the command looks like this:

golden_ticket_create -d -k <nthash partially redacted> -s S-1-5-21-522332750-710551914-1837870370 -u invaliduser -t /root/Downloads/invaliduser.tck

MSF Ticket Created

We can see from the previous picture that the ticket was successfully created and written out.  The user that we are impersonating is “invaliduser”, and the ticket is saved to /root/Downloads/invaliduser.tck.

Now that the ticket has been created, it’s time to apply it to our current session.  To do this you want to type the following command:

kerberos_ticket_use /root/Downloads/invaliduser.tck

Ticket applied

In the above screenshot, I cleared all existing tickets, then applied the created ticket, and then we can see the golden ticket in use.  Note: you don’t have to purge existing tickets, but I did for demonstration purposes.

Now that the ticket has been applied, a low level user account can now act as a Domain Administrator:

MSF Ticket Applied

The user account could not previously access the DC’s C$ share, but with the ticket applied, it can!  We’re now operating with the same level of permissions as a DA!


So, our other option for generating and using golden tickets is to use the mimikatz binary.  You can download that from here.  Once downloaded, navigate to the mimikatz binary and start it.  We can re-use the information that we already have to generate our golden ticket.  To generate the ticket, you’re going to run a command similar to the following:

kerberos::golden /user:invaliduser2 / /sid:S-1-5-21-522332750-710551914-1837870370 /krbtgt:<ticket partially redacted> /ticket:invalidadmin.tck /groups:501,502,513,512,520,518,519

(Thanks to Benjamin Delpy (@gentilkiwi) for letting me know that I failed at redacting my own krbtgt hash, haha.  This is why you should always post things from a test/lab domain :).  Pic below is now updated)



In this case, we’re creating a ticket for a non existent user account, the User ID is at its default value (500), and we’ve added groups that the user should be part of.  The ticket is saved to the invalidadmin.tck file within the same directory that the mimikatz binary is running from.

Now that the ticket has been created, we just want to apply it with Mimikatz.  This can be done by running the following command:

kerberos::ptt invalidadmin.tck

Win Ticket Submission

And to verify that we have administrative access to the domain controller again…

Access DC Share

We can actually also see from the DC that the Logon was successful, even though it was with an account that doesn’t exist within the domain!

Windows Log

And that’s about it!  Writing this out helped me gain a better understanding about generating and using golden tickets, hope that it can help someone else too!