1. Kern & Mechanik: Was ist Kerberoasting?
Kerberoasting (MITRE ATT&CK T1558.003, Tactic: Credential Access) ist kein klassischer Software-Exploit. Der Angriff missbraucht ein legitimes Feature des Kerberos-Authentifizierungsprotokolls: Jeder authentifizierte Domänenbenutzer darf beim Key Distribution Center (KDC) ein Ticket Granting Service Ticket (TGS) für beliebige Service Principal Names (SPNs) anfordern. Dieses Ticket ist mit dem NTLM-Passwort-Hash des zugehörigen Service-Accounts verschlüsselt – und kann danach vollständig offline angegriffen werden.
Die eigentliche Schwachstelle ist konfigurativ, keine Programmierfehler: Solange RC4-Kerberos (Verschlüsselungstyp 0x17) erlaubt ist und Service-Accounts menschlich gesetzte, kurze Passwörter tragen, ist das ausgestellte Ticket ein direktes Cracking-Target. AES-256 verwendet Salting und eine PBKDF2-ähnliche Schlüsselableitung; RC4 tut das nicht – der Passwort-Hash geht direkt als Schlüssel ein.
Kerberos (RFC 4120) war ursprünglich für eine Welt ohne GPU-Cracking konzipiert. RC4 als Kerberos-Verschlüsselung gilt heute als veraltet. Windows Server 2025 und Windows 11 24H2 deaktivieren RC4 standardmäßig; ältere Umgebungen müssen die Abkehr von RC4 aktiv erzwingen.
Der Angriffspfad im Überblick
Der Ablauf gliedert sich in vier Schritte – erkennbar nur, wenn die richtigen Audit-Politiken aktiv sind:
[Angreifer mit gültigem Domänen-Account]
│
▼
[1] SPN-Enumeration — LDAP-Abfrage nach User-Accounts mit servicePrincipalName
→ Signal: LDAP-Abfrage-Volumen / BloodHound-ähnliche AD-Enumeration
│
▼
[2] TGS-Anfragen für alle gefundenen SPNs
→ KDC stellt Tickets aus (Windows Event 4769, etype 0x17)
→ Anomalie: ein Account fordert in kurzer Zeit viele Tickets für verschiedene Services
│
▼
[3] Offline-Cracking des RC4-Hashes (z. B. mit Hashcat)
→ Kein Netzwerkverkehr mehr; vollständig passiv
→ GPU-Cracking: schwache Passwörter in Sekunden bis Minuten
│
▼
[4] Zugriff mit geknacktem Service-Account-Passwort
→ Lateral Movement, Privilege Escalation wenn SPN-Account privilegiert istRC4-verschlüsselte TGS-Tickets verwenden den Passwort-Hash ohne Salt und ohne Key-Stretching als Schlüssel. Jedes ausgestellte Ticket ist damit ein direktes Offline-Cracking-Target. AES-256 ist unter diesen Bedingungen nicht praktikabel angreifbar.
2. Ausnutzung & Konsequenz: Wer nutzt das – und was passiert?
Kerberoasting ist keine akademische Technik. Laut MITRE ATT&CK Procedure Examples setzen bekannte Bedrohungsakteure wie APT29 (Solorigate-Kampagne), FIN7 und Wizard Spider es gezielt ein – als Teil von Lateral-Movement- und Privilege-Escalation-Ketten. Credential-Missbrauch allgemein steht laut dem IBM X-Force Threat Intelligence Index 2025 hinter rund 30 Prozent aller Einbrüche im Jahr 2024 (Angabe laut IBM X-Force via Microsoft Security Blog).
Besonders brisant: Der KDC-Log zeigt bei einem erfolgreichen Kerberoast-Angriff keinen Fehler-Event, sondern nur ein normales Erfolgsereignis (Event ID 4769 mit Status 0x0). Ohne dedizierte SIEM-Logik auf den Verschlüsselungstyp ist der Angriff im normalen Kerberos-Traffic unsichtbar.
Service-Accounts mit SPNs haben häufig weitreichende Berechtigungen – Datenbankzugriff, Backup-Rechte, Domain-weite Services. Ein geknacktes Passwort kann direkt zu Domain Compromise führen, wenn der Account über erhöhte Privilegien verfügt.
Erkennungs-Signaturen
Die primären Detektionssignale liegen in Windows Event 4769. Der entscheidende Filter ist der Verschlüsselungstyp: Legitime moderne Umgebungen verwenden ausschließlich AES. Ein RC4-TGS-Request von einem normalen Benutzer-Account ist ein starkes Indiz.
| Signal | Event / Quelle | Filter |
|---|---|---|
| RC4-TGS-Anfrage | Windows Event 4769 | EncryptionType=0x17 AND ServiceName≠krbtgt AND ServiceName≠*$ AND Status=0x0 |
| SPN-Massenenumeration | LDAP-Audit / 4769-Burst | ≥ 5 TGS-Anfragen eines Accounts in 60 Sekunden |
| PowerShell-Kerberoast | Event 4104 (ScriptBlock) | KerberosRequestorSecurityToken im Block |
| Defender XDR | MDI Alert | External ID 2410: Suspected Kerberos SPN Exposure |
3. Schließen & Absichern: Strukturelle Härtung
Kerberoasting lässt sich nicht durch ein einzelnes Patch schließen – es ist eine Konfigurationsschwäche. Die Härtung muss an mehreren Punkten gleichzeitig ansetzen: Schlüsselqualität, Verschlüsselungserzwingung und Angriffsflächen-Reduktion durch SPN-Hygiene.
Maßnahme 1: gMSA und dMSA einsetzen
Group Managed Service Accounts (gMSA) sind die effektivste strukturelle Antwort. Das Passwort ist 120 Zeichen lang, vollständig zufällig und rotiert automatisch alle 30 Tage. Menschen setzen es nie – der Service-Account ist damit aus dem Offline-Cracking-Bereich herausgenommen. Delegated Managed Service Accounts (dMSA), eingeführt mit Windows Server 2025, erweitern dieses Modell für Szenarien ohne klassische gMSA-Unterstützung.
Nebenwirkung: gMSA-Migration erfordert Aufwand. Dienste müssen gMSA-kompatibel sein (kein interaktives Login, keine Tasks mit gespeicherten Credentials). Eine Bestandsaufnahme aller SPN-tragenden Accounts ist vor der Migration zwingend.
Maßnahme 2: AES-only-Enforcement
Wo gMSA kurzfristig nicht umsetzbar ist, muss RC4 für betroffene Accounts deaktiviert werden. Dies geschieht über das AD-Attribut msDS-SupportedEncryptionTypes (Wert 0x18 = AES128+AES256) in Kombination mit Gruppenrichtlinien (Network security: Configure encryption types allowed for Kerberos). Der Effekt: Ausgestellte TGS-Tickets verwenden AES – offline nicht praktikabel crackbar.
Nebenwirkung: Ältere Clients ohne AES-Unterstützung (Windows XP, bestimmte Linux-Kerberos-Implementierungen) können sich dann nicht mehr gegen diese Services authentifizieren. Kompatibilitätstests im Staging sind pflicht.
Maßnahme 3: Passwortlänge ≥ 25 Zeichen für bestehende SPN-Accounts
Als Sofortmaßnahme – bis gMSA vollständig migriert ist – sollten Passwörter für SPN-tragende Accounts mindestens 25 zufällige Zeichen umfassen. Bei dieser Länge ist Offline-Cracking selbst mit moderner GPU-Hardware in praktikabler Zeit nicht möglich.
Maßnahme 4: SPN-Hygiene und Tiering
Regelmäßige Audits der SPN-Registrierungen reduzieren die Angriffsfläche. Verwaiste SPNs (für Dienste, die nicht mehr existieren), doppelt registrierte SPNs und SPNs auf privilegierten Accounts (Tier-0/Tier-1) sind besonders kritisch. Das AD-Tiering-Modell verhindert, dass Service-Accounts über Tier-Grenzen hinweg privilegiert sind.
Die Aufnahme von Service-Accounts in die „Protected Users"-Sicherheitsgruppe verhindert laut Forscher-Analyse (dev-2null.github.io) die Ausstellung von RC4-TGTs für diese Accounts. Dies ist eine ergänzende, keine primäre Maßnahme – Dienste müssen vorher auf AES-Kompatibilität geprüft werden.
| Maßnahme | Wirkung | Aufwand |
|---|---|---|
| gMSA / dMSA | 120-Zeichen-Zufallspasswort, auto-rotiert → Cracking strukturell unmöglich | Mittel (Migration, Kompatibilitätstest) |
| AES-only-Enforcement | RC4-Tickets nicht mehr ausstellbar → kein praktisches Cracking-Target | Niedrig–Mittel (GPO + Attribut, Kompatibilitätstest) |
| Passwort ≥ 25 Zeichen | Sofortmaßnahme: Cracking unpraktikabel | Niedrig (Passwortrichtlinie) |
| SPN-Hygiene + Tiering | Angriffsfläche reduziert; privilegierte Accounts geschützt | Mittel (Audit, Reorganisation) |
| SIEM-Detection (Event 4769) | Aktive Erkennung laufender Angriffe | Niedrig–Mittel (Regel-Implementierung) |
4. Beweis: Angriff vorher – nach Härtung gescheitert
Im Labor wurde der Angriff gegen eine isolierte Active-Directory-Umgebung (lab.local) mit einem kerberoastbaren Service-Account (svc-sql) durchgeführt. Alle Daten sind synthetisch; es wurden keine produktiven Systeme oder echte Nutzerkonten verwendet.
Vorher: schwaches Passwort, RC4 aktiv
Ein authentifizierter Domänenbenutzer fordert ein TGS-Ticket für den SPN des Datenbankdienstes an. Das Ticket wird mit dem RC4-Hash des Service-Account-Passworts verschlüsselt und lokal gespeichert. Das anschließende Offline-Cracking liefert das Klartextpasswort innerhalb von Sekunden.
# Schritt 1: TGS-Ticket für SPN anfordern und als Hash extrahieren $ GetUserSPNs.py lab.local/jdoe:Password1 -dc-ip 192.168.10.10 -request-user svc-sql -outputfile svc-sql.hash ServicePrincipalName Name MemberOf PasswordLastSet LastLogon ---------------------------- ------- -------- --------------------------- --------- MSSQLSvc/db01.lab.local:1433 svc-sql 2025-01-15 08:12:44.000000 <never> $krb5tgs$23$*svc-sql$LAB.LOCAL$MSSQLSvc/db01.lab.local:1433*$a3f8... # Schritt 2: Offline-Cracking des RC4-Hashes $ hashcat -m 13100 svc-sql.hash rockyou.txt Session..........: hashcat Status...........: Cracked Hash.Mode........: 13100 (Kerberos 5, etype 23, TGS-REP) Recovered........: 1/1 (100.00%) Plaintext........: Summer2026 # ✅ Angriff erfolgreich — Passwort im Klartext
Nach der Härtung: gMSA + AES-only
Nach der Migration von svc-sql auf ein Group Managed Service Account und der Erzwingung von AES-only-Verschlüsselung schlägt derselbe Angriff fehl. Der SPN bleibt registriert; das ausgestellte Ticket verwendet AES-256 – kein praktikables Cracking-Target mehr.
# Dieselbe Anfrage nach der Härtung $ GetUserSPNs.py lab.local/jdoe:Password1 -dc-ip 192.168.10.10 -request-user svc-sql$ -outputfile svc-sql-post.hash ServicePrincipalName Name MemberOf PasswordLastSet LastLogon ---------------------------- -------- -------- --------------------------- --------- MSSQLSvc/db01.lab.local:1433 svc-sql$ 2026-07-19 09:00:00.000000 <never> # Ticket verwendet AES-256 (etype 0x12) — kein RC4-Hash mehr extrahierbar # Cracking-Versuch: $ hashcat -m 19700 svc-sql-post.hash rockyou.txt Session..........: hashcat Status...........: Exhausted Hash.Mode........: 19700 (Kerberos 5, etype 18, TGS-REP) Recovered........: 0/1 (0.00%) # ✅ Angriff gescheitert — gMSA-Passwort (120 Zeichen, zufällig) nicht crackbar
Nach der Umstellung auf AES-only sollte das SIEM aktiv auf verbleibende Event-4769-Einträge mit Verschlüsselungstyp 0x17 überwacht werden. Jeder solche Treffer zeigt entweder einen noch nicht migrierten Account oder einen aktiven Angriffsversuch.
Active-Directory-Härtung mit Blackfort
Blackfort bewertet und härtet AD-Konfigurationen strukturell: Service-Account-Passwortrichtlinien, SPN-Hygiene, Managed Service Accounts und das AD-Tiering-Modell. Zusätzlich implementieren wir Detection-Regeln im SIEM (Wazuh/SIEM) gegen Kerberoasting und ähnliche Credential-Access-Techniken – direkt verknüpft mit DORA-IAM-Resilienz- und NIS2-Identitätssicherungsanforderungen.
Mehr zu unserem Ansatz: www.blackfort-tec.de/leistungen
Hinweis & Haftungsausschluss
Dieser Beitrag dient ausschließlich der Information und der Verbesserung der IT-Sicherheit (Erkennung und Härtung). Er stellt keine Rechtsberatung dar und enthält keine einsatzfähige Angriffsanleitung. Alle Tests fanden in einer isolierten Laborumgebung mit ausschließlich synthetischen Daten statt. Für Schäden aus der Anwendung der beschriebenen Inhalte wird keine Haftung übernommen.
Der zugrunde liegende Proof-of-Concept ist öffentlich verfügbar. Nennung und Lizenz werden respektiert; über den bereits öffentlichen Stand hinaus erfolgt keine Bewaffnung.
Quellen
- [1] MITRE ATT&CK – T1558.003 Steal or Forge Kerberos Tickets: Kerberoasting. attack.mitre.org/techniques/T1558/003/
- [2] Microsoft Security Blog – Microsoft's Guidance to Help Mitigate Kerberoasting (Oktober 2024). microsoft.com
- [3] ADSecurity.org (Sean Metcalf) – Detecting Kerberoasting Activity. adsecurity.org
- [4] TrustedSec – The Art of Detecting Kerberoast Attacks. trustedsec.com
- [5] IBM X-Force Threat Intelligence Index 2025 (zitiert via Microsoft Security Blog [2]).