Kerberos tickets: Comprehension and exploitation

The main aim of this post is explaining the most common attacks that can be carried out in a security audit or pentest of Kerberos protocol used in Microsoft active directory domains.

To this effect, first it is going to be explained how Kerberos works in order to provide access to those network resources; second, how the most famous attacks work on Kerberos tickets; third, how to carry out a Golden ticket attack using Mimikatz; and finally, possible mitigations against this type of attacks.

How Kerberos works in an active directory

In an active directory the authentication is done using Kerberos. This is a protocol that works on the basis of tickets which are given to users which later are shown to different network resources in order to authenticate permissions.

In the Kerberos protocol there are 3 architecture main entities:

The client machine refers to the user who wants to access the service.

The machine hosting the service refers to the system the user wants to access to.

The Key Distribution Center (KDC) is a central server responsible for authenticating users and distributing tickets in order to be identified in services hosting machines. In active directories, KDC is installed in Domain Controller (DC).

On the other hand, there are 2 types of tickets a user should hold in order to access domain services:

Service Tickets (ST): used for identification purposes against the services.

Ticket Granting Ticket (TGT): used for authentication purposes against the Kerberos server and for obtaining the ST required for different services.

Please, find in the following image the necessary messages sequence to carry out user’s authentication process using Kerberos:

Authentication with Kerberos tickets

Kerberos messages

Firstly, as shown in the previous image, a user should have a TGT. To this effect, the user should be authenticated against the KDC sending the following message.

A session key that shall be used to encode the following messages exchanged with the KDC and TGT lifetime, both encoded with user’s NTLM hash (then the user could read this fields)

TGT encoded with krbrgt account NTLM hash (then, only the KDC can read it), and including the session key and the TGT lifetime, and also a token containing the PAC structure. This is where TGT holder privileges are detailed.

Once this process is finished, the user possesses a TGT that can be used in order to request ST, and therefore access domain services associated to Kerberos.

In order to apply for a ST, the following message should be sent to KDC:

ST Request message

In this message, three fields are included:

Requested service name

Username and an encoded timestamp with the session key established in TGT.

TGT

When the KDC receives this message, the user’s privileges contained in the TGT are authenticated and a ST is sent in the following message:

ST response message

This message is divided in 2 parts:

Service name, timestamp and service session key, all of them are encoded with the specified session key in TGT (then the user can read it)

ST including the following: username, service name, service session key, user’s permissionstoken copy. Therefore, the service machine can authenticate that this particular user holds the corresponding privileges in order to access the service and a timestamp indicating the moment when everything was created. All this is encoded with the domain account NTML associated to the service hash (then only this service can read it)

And if everything is correct, the user will have the ST providing access to the desired service.

It is important to remark, that TGT and ST are found cached in the computer where the user has logged in, and in particular, in the Isass process memory, responsible for authentication. This process is also responsible for storing other important information such as different authenticated users’ password hashes (LM, NTLM, SHA1…) in the machine and also clear passwords. Then, having this in mind, any user having enough permissions, such as the computer’s local administrator, could extract all this process information for all those users having a logged in account in the computer. For this purpose, Mimikatz tool is often used due to the fact that it counts on a module consisting on extracting the aforementioned credentials.

Overpass The Hash/Pass The Key (PTK)

The general definition of Pass the Hash (PTH) attack refers to an attack that uses the user’s hash in order to forge the user’s identity. In Kerberos ticket field, this is called Overpass The Hass or Pass The Key.

Observing any TGT obtaining process, it could be seen that if an attacker finds a user’s hash, a valid TGT request message could be created and this one can be used to access to any of the domain resources which that user in particular has access to without knowing the password.

Pass The Ticket (PTT)

Pass The Ticket consists of obtaining a user’s ticket and using it in order to gain access to those resources the user is holding the corresponding permissions.

Generally, this is carried out obtaining a user’s TGT, therefore if the attacker gets a ST, this attack could not work properly since there are certain protections.

When a ST is sent to the machine providing the service, this one compares the timestamps included in the ST (the moment when the ticket was created) with the moment when the ticket was sent and it is directly dismissed if there is difference of more than 2 minutes. Besides, the first ticket sent to the service machine (most of the time it refers to the legitimate user) is cached in the memory and the following tickets are rejected.

Then, it is very common to have a TGT without this protections, although it should be taken into account that this one has a maximum lifetime (normally 10 hours) after which the ticket may expire. In addition, the TGT is not only restricted to one service but also it could be used to apply for any service the owner may access to.

Kerberoasting

Kerberoasting tries to use ST to crack offline users’ passwords.

As it could be seen previously, ST are encoded with the domain account NTLM hash associated to the service. Therefore, if a user requests a service ST associated to a user, once the ST is obtained, this one can be used in another machine and crack the user’s password, which generally holds many privileges in the domain or at least in the machine where the service is run.

The first part could refer to computer accounts associated to services and even to the krbtgt account if TGT is extracted. However, these accounts passwords are generated automatically and these passwords are too complex to be cracked.

Golden Ticket and Silver Ticket

The main aim of the Golden Ticket attack is creating a TGT. For this purpose, the krbtgt account hash is necessary since it is used to encode the ticket. Once this hash is obtained, it is possible to create a TGT including any desired expiration date, and most importantly, any required permissions, containing even domain administrator privilege.

It also has to be taken into account that a TGT validity depends on two aspects: the given expiration date and the NTLM hash used to encode (referring to krbtgt account password). Therefore, either lifetime does not expire either the krbtgt account password is changed. The ticket will be valid regardless of whether the forged user’s password expires.

Silver Ticket concept is similar. However, this time the ticket created is a ST and therefore, it is required the domain account NTLM hash associated to the service you want to access to.

Golden Ticket attack

In the next section, how it is possible to build a Golden Ticket using Mimikatz tool is going to be explained.

First of all, you need to find krbtgt account hashes which are stored in the NTDS.DIT file of domain controllers:

For that purpose, Mimikatz should be executed in the domain controller. I personally prefer the PowerShell script Invoke-Mimikatz of Empire repository that enables to run Mimikatz directly on the memory.

If we run the following instruction in a PowerShell we can download the utility code and load it directly to the memory:

The password should be reset twice, due to usability purposes. Then, those tickets using krbtgt password NTLM hash as encryption key prior to the current one will be considered still valid. However, it should be taken into consideration that it is only possible to change the password in the krbtgt account if the domain functional level is either the same or higher than Windows Server 2008.

Generales mitigations

Attacks types previously described take advantage of Kerberos protocol inherent weaknesses. Therefore, there is not an easy way to prevent them. Nevertheless, Microsoft provides a publicly available guide explaining how to mitigate this kind of attacks: https://www.microsoft.com/en-us/download/details.aspx?id=36036

2 Comments

Dear I have simple question regarding kerberos ticket, now in replay attack, its possible for intruder or attacker to access and read and modify the contents of the ticket that AS send to the client. Please replay me at my email.

In order to change or read the content of the TGT ticket send from the AS to client, it is necessary to know the secret key of KDC, with which the TGT is encrypted. That secret key is the password NTLM hash of krbtgt account. Furthermore, kerberos avoids replay attacks including a nonce that is sent to server by client in previous message(using its hash to encrypt it).

Sorry for no replaying at email, but I would like to share the answer to this excellent question with other people, which it is the goal of this post.

Necesary

Used by the content network, Cloudflare, to identify trusted web traffic

Settings

It's used to serve the user's preferred language on the website

Statistics

These cookies help us to understand how visitors interact with our website, collecting and reporting data about your interaction within our website

Marketing

Marketing cookies are used to track visitor across websites. The intention is to display ads that are relevant and engaging for the individual user an thereby more valuable for publishers and third party advertisers.