Kerberoasting: warum jeder Domain-User Service-Konten angreifen kann
Kerberoasting braucht keine Admin-Rechte, nur einen gültigen Domain-Account. Die Mechanik dahinter, und warum Service-Account-Passwörter die eigentliche Schwachstelle sind.
Kerberoasting ist deshalb so verbreitet, weil die Voraussetzung dafür fast immer schon erfüllt ist: ein einziger, beliebig niedrigprivilegierter Domain-Account. Kein Exploit, keine Fehlkonfiguration im klassischen Sinn, nur die Art, wie Kerberos Service-Tickets ausstellt, kombiniert mit Service-Account-Passwörtern, die seit Jahren nicht angefasst wurden.
Die Mechanik
Jeder Dienst in Active Directory, der Kerberos-Authentifizierung unterstützt, ist über einen Service Principal Name (SPN) an einen Account gebunden, oft ein dediziertes Service-Konto statt eines Computer-Accounts. Will ein Client diesen Dienst nutzen, fordert er beim KDC ein Service-Ticket (TGS) für genau diesen SPN an, das Ticket wird mit dem NTLM-Hash des Passworts des Service-Accounts verschlüsselt.
Der entscheidende Punkt: jeder authentifizierte Domain-User darf ein solches TGS anfordern, für jeden SPN in der Domäne, unabhängig davon, ob er den Dienst je nutzen wird. Der KDC prüft keine Berechtigung zum Anfordern des Tickets, nur zur Domain-Mitgliedschaft.
GetUserSPNs.py corp.local/j.weber:'Summer2026!' -dc-ip 10.10.11.5 -requestDas Ergebnis ist ein Hash im $krb5tgs$-Format, offline crackbar, ohne
dass der Angriff dafür ein einziges Paket mehr an den Domain Controller
schicken muss:
hashcat -m 13100 kerberoast_hashes.txt rockyou.txtWarum das funktioniert, nicht nur dass es funktioniert
Der Angriff ist kein Bug, er ist eine direkte Konsequenz davon, wie Kerberos TGS-Verschlüsselung einsetzt: Vertraulichkeit des Tickets gegen den Client, nicht Autorisierung der Anfrage. Die eigentliche Schwachstelle liegt eine Ebene darunter, im Passwort des Service-Accounts selbst. Service-Konten werden bei der Ersteinrichtung vergeben und danach oft jahrelang nicht rotiert, weil ein Passwortwechsel im schlimmsten Fall einen Produktionsdienst lahmlegt. Genau diese Trägheit macht sie zum lohnendsten Ziel für Offline-Cracking.
Achtung
Das Anfordern eines TGS für einen beliebigen SPN ist Kerberos-Standardverhalten,
kein ungewöhnlicher Vorgang. Ein einzelnes GetUserSPNs.py sieht in den
Security-Logs fast identisch aus wie normale Dienst-Nutzung. Erst das
Muster, ein Account fordert in kurzer Zeit Tickets für ungewöhnlich viele
verschiedene SPNs an, die er nie zuvor genutzt hat, ist der verwertbare
Indikator (Windows Event-ID 4769 mit Verschlüsselungstyp 0x17, RC4,
statt AES).
Härtung
Hardening-Tipp
Drei Maßnahmen in Reihenfolge der Wirksamkeit: Service-Account-Passwörter
auf 25+ Zeichen, zufällig generiert, zwingen das Cracking praktisch zum
Scheitern, unabhängig von allem anderen. AES statt RC4 für
Kerberos-Tickets erzwingen (msDS-SupportedEncryptionTypes), weil RC4-Hashes
mit handelsüblicher GPU-Hardware um Größenordnungen schneller zu knacken
sind als AES. Group Managed Service Accounts (gMSA) nehmen Menschen die
Passwortverwaltung für Service-Konten komplett ab, automatische Rotation
alle 30 Tage, Passwort nie manuell gesetzt oder bekannt.