Mimikatz is a rapidly evolving post-exploitation toolkit by Benjamin Delpy. I call it a post-exploitation toolkit because it has a lot of features, far beyond the ability to dump plain-text passwords.
One of the interesting features in Mimikatz 2.0 is its ability to generate a Kerberos ticket for a domain administrator with a lifetime of 10 years. This Kerberos Golden Ticket will continue to work, even if the user it’s tied to changes their password. The only way to invalidate these golden tickets is to change the krbtgt user’s password on the domain controller.
Mimikatz became a Meterpreter extension in 2013, giving Metasploit Framework users the ability to use it without touching disk. Mimikatz 2.0 is a significant update to the original Mimikatz and it is available in Meterpreter as the Kiwi extension. The Kiwi extension was added to the Metasploit Framework by TheColonial.
In this post, I’ll take you through how to use the Kiwi extension to generate a golden ticket, apply it to your session, and use your rights to get access to other hosts.
This tutorial is written for Meterpreter users. If you’d like to use this technique with Mimikatz 2.0, consult the mimikatz – Golden Ticket tutorial written by Balazs Bucsay.
Generate the Golden Ticket
To generate a golden ticket, you will need to get four items:
- the account name of a domain administrator
- the domain name
- the SID for the domain
- the password hash of the krbtgt user from the Domain Controller
The first two items are easy. On my test domain, the domain administrator user is Administrator. The domain name is CORP. I’ll trust that you can find these values on your domain.
An easy way to get the SID for a domain is to open a command shell and type whoami /user. I assume that you’re typing this from the context of an account that’s part of the domain you’re interested in. This command will output a SID for the current user. If you drop the last segment of the user’s SID (-####); the remaining part is the domain’s SID.
We also need the password hash of the krbtgt user from the domain controller. You may obtain this password hash with Meterpreter’s hashdump command or the smart_hashdump module.
Now that we have these critical pieces of information, let’s generate a golden ticket. As with all things Mimikatz, you will want to migrate Meterpreter to a process that matches the native architecture. If the domain controller is a 64-bit system, migrate Meterpreter to a 64-bit process.
To use Mimikatz 2.0, you will need to load the Kiwi extension. Type use kiwi to do this.
To generate the golden ticket, we will use the golden_ticket_create command. Here’s the syntax to use it:
golden_ticket_create
-u [user]
-d [domain]
-k [password hash]
-s [domain SID]
-t [/path/to/golden.tkt]
This command will generate our Kerberos ticket with a lifetime of 10 years! This ticket will live on our local system in the file we specify with the –t flag. This file is particularly dangerous and you must protect it. As we will see in a moment, this file is our ticket to domain administrator rights when we need them in the future.
Apply the Golden Ticket
Time passes. We lose access to our target network. We’re OK with that. After some more time, we decide to re-establish our access. We send a phish and we land ourselves on a workstation.
We may now use our Golden Ticket to gift ourself Domain Admin rights in this new session. We do not need SYSTEM or local administrator rights to do this. First, load Mimikatz 2.0 with the use kiwi command in Meterpreter.
Use the kerberos_ticket_use command to apply the ticket to the current session.
kerberos_ticket_use [/path/to/golden.tkt]
At this time, you now have a Kerberos ticket for a Domain Administrator. Use whoami in a command shell to see who you (still) are. Use klist in a command shell to verify that the Kerberos ticket is associated with your session. You should see an End Time that’s ten years from when you generated the file.
Using Your Rights
A ticket associated with your session is not the same thing as an impersonated token. Your session continues to run in the context of its original user. When you try to access some shared resource, Windows will use your “Golden Ticket” to request a ticket to interact with the other resource. In my experiments, I found that if I interact with a system using its IP address, I do not get access. If I interact with a system using its NetBIOS name, things work. I’ll clarify this with an example.
When I manage to steal an identity on a network, the first thing I do is check where it’s a local administrator. I do this by trying to interact with an admin-only share on a remote system. For example:
dir \\10.10.10.3\C$
If I apply a Golden Ticket to my session, the above will come back with access denied. If I use the NetBIOS name for the same host, then everything works as expected:
dir \\DC\C$
If I want access to that DC, I simply need to copy a file over and schedule it to run. Cobalt Strike users may use Attacks -> Packages -> Windows Executable to generate an AV-safe Windows Service EXE.
To upload a file to another host via Meterpreter:
upload /root/path/to/your.exe \\\\DC\\C$\\windows\\temp
This command will upload the file you specify to c:\windows\temp on the host you specify. Make sure you escape the backslashes when you specify a UNC path as an upload destination .
From a command shell, use sc to create a service on the remote system and start it:
sc \\DC create blah binpath= c:\windows\temp\your.exe sc \\DC start blah
You now have access to the domain controller. There are other ways to abuse trust to start a process on a remote system and last week’s blog post went over a number of them.
Persistent Privileged Access
When I replicate an actor with long-term persistence, I like to live on workstations and other non-important assets. I don’t like to drop malware on key servers like the Domain Controller. Skilled network defense teams usually watch these assets well. They can (and should!) do things on these servers that don’t scale well to the rest of the enterprise.
When I gain access to a key server, I tend to rely on harvested credentials and password hashes to regain it later. During exercises, red teams also like to introduce mis-configurations to secure future access to these servers (e.g., Sticky Keys).
I see the Golden Ticket as a beautiful persistence opportunity. With the Golden Ticket, I now have the opportunity to turn a short window of access to a domain controller into the assurance that I may control my target’s enterprise at will.
The Golden Ticket is a double-edged sword. Generate it once and you have persistent access to higher privileges. Beware though–once you create this Golden Ticket, it becomes a liability. If you fail to secure this file properly, you may inadvertently give someone else the literal key to the kingdom.