Hacking Summer Camp: How to Steal Kerberos Tickets?

Welcome to the second episode of our Hacking Summer Camp! We hope you enjoyed Resetting the Admin’s Password Illegally and are now ready and steady for another adventure. Get ready for a decent portion of useful tools and tips.

 

Episode 2: How to Steal Kerberos Tickets?

 

Hi Security Enthusiasts! Today is the time to play a little bit with Kerberos tickets.

Actually, we’re stealing them! Within our Episodes, we will be discussing passwords several times, but this time let’s raise the bar a bit. First of all, we would like to discuss the problem of a bad habit with Domain Administrators or other domain privileged accounts who are logged into the user’s workstation.

When there is an RDP session used, DO NOT forget to log off properly, this is a common mistake when you close the session rather than logging off. In such cases, your credentials remain in the memory of the user’s workstation. Users who have a Debug Privilege (effectively being a member of the local Administrators group) are able to grab your password from memory in clear text. This magical space where passwords live is called: LSA Secrets, unfortunately, it’s no longer a secret.

The proper security practice is when you don’t even use a domain privileged account to log on a user’s workstation and always remember to log off properly after performing the administrative tasks using RDP.

The world would be a beautiful place if this problem was over, so let’s have a little fun, but not in a production environment, okay?

Scenario 1: Access to the services.

Imagine the situation where domain user: Administrator@cq.local enters a share from the Workstation1 that is a member of the domain. He goes to the share \\DC1\c$\:

The user spends a while opening several shared files. Then the user doesn’t completely log off and then another user logs in while being a member of the local Administrators group but he is not an administrator on the DC on the network. He then tries to access the same share:

It is predictable since this is a different user. If we check for the assigned Kerberos tickets, the user also receives different tickets:

But of course what happens is that Kerberos tickets of the previous user remain in the memory of the operating system and you can grab them by using mimikatz (download from: http://blog.gentilkiwi.com/mimikatz):

After enabling the Debug Privilege, it is time to export the Kerberos tickets of the previous user to the file:

First, we see tickets of our account (the same ones we displayed with klist before), when we scroll down however, we can see Admin tickets!

Kerberos tickets are exported to files in the Mimikatz folder:

Selected .kirbi file can be imported to LSASS memory for the current user’s session. This can be done for example by passing the name of the CIFS ticket as the parameter for the Kerberos::ptt, in the following way:

Now it’s time to verify the shared access, you can do this by opening up a new console. Make sure the console is running in elevated mode (in our case it’s Fred):

TRATADAMDAM! Verify if you have the appropriate ticket:

As you see the local administrator of the workstation (Fred) has been assigned the Kerberos ticket of the Domain Admin from the domain CQ.

Remember that when you have the ticket for one service, this is the only one that will be working as it requires a separate TGS (Ticket Granting Service), so browsing the shares on the other servers will not work unless you assign another TGT (Ticket Granting Ticket).

To be able to browse other server’s shares and, in general, act as another user you need to assign to yourself the following ticket, we suggest you do this on your own using the krbtgt ticket and just browse \\server2\c$ :

 

Scenario 2: The Golden Ticket to the Wonka Chocolate factory

[Warning]: Do this only in a test environment!

The way to get the Golden Tickets the NTLM hash of the password for the krbtgt account. To grab it you can use mimikatz as well. With this technique, you can access any resource in the domain. You first need to get the following information:

• Domain name
• Domain’s SID
• Username that you would like to impersonate
• krbtgt user’s NTLM hash (details later in the text)

In order to grab the NTLM hash, you need to be able to access the Domain Controller, which for the attacker may be the end of activities. The steps below are to show you what is possible and present the potential problem when someone has a few privileges. The goal to achieve the user’s token that is the privileged used. The first step is to get the Domain’s SID, you can use PsGetsid.exe from the Sysinternals tools:

Now it is time to get the krbtgt’s account SID. This is not the easiest thing to do, but let’s dig into it! The following commands need to run on the domain controller, but not the one in the production environment! It may happen that the server will reboot automatically because of the LSASS injection. If it reboots automatically you need to find another way to grab hashes for the krbtgt account (try https://dsinternals.com, wce, gsecdump, esedbextract + dsusers.py etc.)

In order to grab the hash, you can alternatively have a look at my TechEd session where you will find the presentation on how to grab hashes differently. In case a domain controller reboots this will for sure allow you to still extract the hash information: http://channel9.msdn.com/Events/TechEd/Europe/2013/ATC-B301 – starting in 32:00 minute. In the end, you should be able to read the hash of the krbtgt account.

If you have a hash you can generate the tickets for the chosen accounts:

This means that finally, we can enjoy the:

Of course, you need to perform pass the ticket attack with keberos:ptt command as we did before. In the current mimikatz folder you will find the file cq.local.kirbi that you can use to generate your own keys. If you share this file with someone, this person will act as a chosen user (Administrator) for the next 10 years or until you change krbtgt password twice.

After that you will see that ticket is valid for a bit longer than usual and it allows us to use all the domain services with high privileges:

The same situation may happen if you share a memory dump with someone. You can download procdump from here: http://technet.microsoft.com/en-us/sysinternals/dd996900.aspx

procdump /ma lsass.exe

mimikatz # sekurlsa::minidump lsass_140224_153946.dmp

mimikatz # sekurlsa::tickets /export

Stay safe!

CQURE Experts