Es ist mittlerweile mehr als zehn Jahre her, dass Tim Medin die sogenannten Kerberoasting-Angriffe vorgestellt hat. Und auch heute noch ist Kerberoasting eine zuverlässige Angriffstechnik gegen Microsoft Active Directory, die gerne von Penetration Testern und Red Teamern ausgenutzt wird. Mit einem gültigen Domänenkonto lässt sich der Angriff in einer Active-Directory-Umgebung ohne erweiterte Privilegien durchführen. Anschliessend kann in Ruhe versucht werden, die Passwörter von Dienstkonten offline zu knacken.
Zwar gibt es bereits eine Vielzahl von Artikeln und Anleitungen zum Thema Kerberoasting, doch die meisten davon konzentrieren sich auf die Extraktion von Hashes und gehen nur oberflächlich darauf ein, wie die gesammelten Hashes effektiv gecrackt werden können. Genau diese Lücke möchten wir mit diesem Artikel schliessen: Der Schwerpunkt soll auf intelligenten Cracking-Strategien liegen, mit denen sich Hashes effizient knacken lassen.
Table of contents
- Was ist Kerberoasting?
- Kerberoasting-Angriffe in der Praxis
- Association Attacks – die intelligente Hash-Cracking-Methode
- Wörterbuchangriffe: den Unternehmenskontext effektiv nutzen
- Verwendung von Passwortlisten für generische Wörterbuchangriffe
- Welche Abwehrmassnahmen schützen vor Kerberoasting?
- Fazit: effizienter Hash-Cracken dank systematischem Vorgehen
Was ist Kerberoasting?
Beim Kerberoasting handelt es sich um eine Angriffstechnik gegen Microsoft Active Directory, die eine Schwachstelle im Kerberos-Authentifizierungsprotokoll ausnutzt. Das Ziel sind Konten, denen ein Service Principal Name (SPN) zugewiesen ist. Betroffen sind somit beispielsweise Accounts, unter denen Dienste wie SQL-Server, IIS oder andere Applikationen laufen. Der Angriff ist möglich, da jeder authentifizierte Domänenbenutzer berechtigt ist, Ticket-Granting-Service(TGS)-Tickets für beliebige SPNs anzufordern. Diese Tickets sind mit dem NTLM-Hash des Passworts des Dienstkontos verschlüsselt. Und genau hier liegt die Schwachstelle.
Angreifer können diese Tickets extrahieren und offline versuchen, das Passwort zu knacken, ohne dass eine weitere Interaktion mit dem Domänencontroller notwendig ist. Im Gegensatz zu anderen Angriffstechniken löst Kerberoasting keine Account-Sperrungen aus und generiert nur minimale Event-Logs. Die einzige Voraussetzung ist ein gültiges Domänenkonto. Dabei genügt bereits ein Standardbenutzer ohne besondere Rechte.
Besonders attraktiv sind Dienstkonten, da sie häufig mit erhöhten Privilegien ausgestattet sind und ihre Passwörter selten geändert werden. Administratoren setzen oft Passwörter, die bestimmten bekannten Mustern entsprechen und nie ablaufen – eine ideale Kombination für erfolgreiche Hash-Cracking-Angriffe.
Kerberoasting-Angriffe in der Praxis
Die Durchführung von Kerberoasting ist denkbar einfach und mit wenigen Befehlen erledigt:
Unter Windows
Auf Windows-Systemen hat sich Rubeus als Standardwerkzeug etabliert. Mit folgendem Befehl lassen sich alle verfügbaren SPNs identifizieren und die zugehörigen TGS-Tickets anfordern:
.\Rubeus.exe kerberoast /outfile:hashes.txt
Rubeus extrahiert die Tickets automatisch und speichert sie in einem Hashcat-kompatiblen Format. Optional kann die Ausgabe mit dem Parameter /user:serviceaccount auf spezifische Accounts beschränkt werden.
Unter Linux
Auf Linux-Systemen ist Impacket die erste Wahl. Das Python-Skript GetUserSPNs.py ermöglicht Kerberoasting von einem System aus, das nicht an die Domäne angebunden ist, sofern Netzwerkzugriff zum Domänencontroller besteht.
GetUserSPNs.py -request -dc-ip IP domain.local/username:password -outputfile hashes.txt
Der Parameter -request fordert die TGS-Tickets an, während -outputfile die Hashes direkt im Hashcat-Format speichert. Alternativ kann auch die NTLM-Authentifizierung mit dem Parameter -hashes verwendet werden.
Die extrahierten Hashes haben typischerweise eines der folgenden Formate (je nach Verschlüsselung):
$krb5tgs$23$*...(RC4-verschlüsselt, Hashcat-Modus 13100)$krb5tgs$17$*...(AES128-verschlüsselt, Hashcat-Modus 19600)$krb5tgs$18$*...(AES256, Hashcat-Modus 19700)
RC4-Hashes sind deutlich schneller zu knacken und in vielen Umgebungen leider immer noch der Standard. Aber auch AES-verschlüsselte Hashes lassen sich knacken, wenn ein schwaches Passwort verwendet wird. Mit diesen Hashes in der Hand beginnt nun die eigentliche Arbeit: das Cracken der Hashes. Dazu setzen wir im nachfolgenden das Tool hashcat ein.
Association Attacks – die intelligente Hash-Cracking-Methode
Auch wenn häufig direkt mit grossen Wörterlisten gestartet wird, empfiehlt sich eher ein strategischerer Ansatz. Im ersten Schritt und als «Quick Win» sollten zunächst Association Attacks (Hashcat-Angriffsmodus -a9) zum Einsatz kommen. Diese liefern oft schon erste Erfolge, bevor zeitaufwändigere Methoden überhaupt notwendig werden.
Association Attacks gehören zu den effizientesten Strategien beim Hash-Cracking. Anstatt mit riesengroßen generischen Wörterlisten zu starten, die Millionen oder gar Milliarden von Einträgen enthalten, werden hochgradig kontextspezifische Kandidatenlisten erstellt. Diese Methode kommt zum Einsatz, wenn bereits eine Vermutung über das Passwort oder einzelne Komponenten des Passworts besteht, die mit einem spezifischen Hash korrelieren.
Das bedeutet, dass eine Wörterliste erstellt wird, die für jeden Hash ein bestimmtes Wort enthält. Die Reihenfolge muss dabei mit der Reihenfolge in der Hashliste identisch sein. Die Association Attack testet dann jedes Wort der Wörterliste gegen genau einen Hash und nicht gegen alle. Das würde wie folgt aussehen:
Hash1 → Wort1
Hash2 → Wort2
Hash3 → Wort3
Es werden also nicht für jeden Hash alle Wörter durchprobiert, wie das bei einem normalen Wörterbuchangriff (Hashcat-Angriffsmodus -a0) der Fall ist.
Die Idee dahinter ist simpel, aber wirkungsvoll: Passwörter werden selten völlig zufällig gewählt, sondern folgen erkennbaren Mustern, die oft in direktem Zusammenhang mit dem Namen des Dienstkontos oder des zugehörigen Dienstes stehen. Ein SQL-Service-Account mit dem Namen «svc_mssql» hat oft (oder zumindest häufiger, als man hoffen würde) ein Passwort wie «MSSQL2025!», «mssql@123» oder «MSSQL_P@ssw0rd».
Die Wörterliste sollte stets mit Regelsets kombiniert werden, um aus einem einzelnen Wort eine ganze Reihe von Variationen zu generieren, beispielsweise durch das Verändern der Gross- und Kleinschreibung, durch das Ersetzen von Buchstaben durch Ziffern und Sonderzeichen (sogenannte Leetspeak-Substitution) oder durch das Hinzufügen von Zeichenketten am Anfang und/oder Ende des Wortes. Später gehen wir noch etwas mehr auf Regelsets ein.
Beispielsweise können mit folgendem Befehl automatisch die Kontonamen aus den extrahierten Hashes ermittelt werden:
cat hashes.txt | cut -d'$' -f4 > usernames.txt
Die Ausgabe lässt sich dann in einer Association Attack verwendetn, um Passwörter zu knacken, die den Namen des Kontos enthalten:
hashcat -m 19700 hashes.txt -a 9 usernames.txt -r path/to/ruleset.txt
Oftmals ist es empfehlenswert, Sonderzeichen und Ziffern am Anfang und am Ende von Benutzernamen zu entfernen, damit beispielsweise aus dem Benutzernamen «SVC_MSSQL037» die Zeichenkette «SVC_MSSQL» wird. Dies kann mit folgendem Befehl erreicht werden:
cat hashes.txt | cut -d'$' -f4 | sed 's/^[^a-zA-Z]*//; s/[^a-zA-Z]*$//' > username-stems.txt
Auch diese Ausgabe kann dann gleichermassen in einer Association Attack verwendet werden:
hashcat -m19700 hashes.txt -a9 username-stems.txt -r path/to/ruleset.txt
Unserer Praxiserfahrung nach stammen die ersten geknackten Hashes fast immer aus Association Attacks, da Administratoren dazu neigen, Passwörter von Dienstkonten an solchen Mustern auszurichten. Oft sind diese Passwörter nur als «temporäre» Lösung beim initialen Aufsetzen des Kontos gedacht. Dabei ist nichts beständiger als ein temporäres Passwort.
Wörterbuchangriffe: den Unternehmenskontext effektiv nutzen
Wenn Association Attacks nicht zum Erfolg führen oder weitere Passwörter geknackt werden sollen, ist der nächste logische Schritt der Einsatz gezielter Wörterbuchangriffe. Dabei geht es nicht um generische Wörterlisten, sondern um Listen von kontextspezifischen Passwortkandidaten, die auf das jeweilige Unternehmen zugeschnitten sind.
Tools wie Targinator, elpscrk oder CUPP (Common User Passwords Profiler) helfen dabei, basierend auf spezifischen Keywörtern massgeschneiderte Wörterlisten zu erstellen. Folgende Informationen können beispielsweise verwendet werden:
- Name des Unternehmens
- Adresse der Unternehmensstandorte (Strassenname, Stadt, Postleitzahl)
- Geografische Besonderheiten (nahegelegene Berge, Flüsse, Seen usw.)
- Lokaler Fussballclub (Vereinsname, Spielernamen, Gründungsjahr usw.)
Um auch branchenspezifische Begriffe und Produkte des Unternehmens einzubeziehen, kann zur Erstellung einer massgeschneiderten Wörterliste die Unternehmenswebseite gecrawlt werden. Dabei helfen Tools wie CeWL (Custom Word List Generator) oder spider.
Beispiel mit spider:
spider -url ‘https://www.oneconsult.com/’ -crawl 3 -timeout 5 -delay 10 -sort -o wordlist.txt
Die resultierende Wörterliste kann anschliessend in folgendem Wörterbuchangriff verwendet werden:
hashcat -m19700 hashes.txt -a0 wordlist.txt -r path/to/ruleset.txt
Dabei sollte man sich jedoch nicht nur auf einzelne Wörter beschränken, die auf der Webseite vorkommen, sondern auch Kombinationen aus zwei, drei oder mehr Wörtern, sogenannte N-Grams, einbeziehen. Auch dafür lässt sich das Tool spider nutzen:
spider -url «https://www.oneconsult.com/" -ngram 1-4 -crawl 3 -timeout 5 -delay 10 -sort -o wordlist-ngrams.txt
Mit dem Parameter -ngram kann angegeben werden, welche N-Grams extrahiert werden sollen.
Wenn N-Grams in einem Wörterbuchangriff verwendet werden, empfiehlt es sich, zuerst ein Regelset zu verwenden, das Kandidaten mit unterschiedlichen Trennzeichen zwischen den einzelnen Wörtern sowie mit unterschiedlicher Gross- und Kleinschreibung generiert. Dazu kann beispielsweise das Regelset von initstring verwendet werden:
hashcat -m19700 hashes.txt -a0 wordlist-ngrams.txt -r passphrase-rule1.rule -r passphrase-rule2.rule
Verwendung von Passwortlisten für generische Wörterbuchangriffe
Erst wenn kontextspezifische Wörterlisten ausgeschöpft sind, ist es an der Zeit, auf bewährte auf realen Datenlecks basierende generische Passwortlisten zurückzugreifen. Diese Listen enthalten Millionen bis Milliarden von tatsächlich verwendeten Passwörtern und decken die häufigsten menschlichen Passwortmuster ab.
Oft wird die Datei rockyou.txt als Standardpasswortliste verwendet. Doch diese Liste stammt aus einem Datenleck von 2009 und ist inzwischen veraltet. Auch die neueren Varianten davon («RockYou2021» und «RockYou2024») sind nicht empfehlenswert, da sie mit künstlichen Passwörtern (also solchen, die nicht tatsächlich von irgendjemandem verwendet wurden) aufgebläht sind.
Wir empfehlen stattdessen die Passwortlisten auf HashMob. Diese werden wöchentlich automatisch generiert und basieren auf gesammelten und gecrackten Passworthashes. Die Wörterlisten sind in verschiedenem Umfang verfügbar und nach Häufigkeit sortiert, wobei die am häufigsten beobachteten Passwörter oben stehen.
Auch diese Passwortlisten sollten stets mit Regelsets kombiniert werden, die systematische Mutationen an jedem einzelnen Passwort durchführen. Hashcat liefert bereits einige Regelsets im Ordner rules/ mit, z. B. best66.rule oder dive.rule.
Eine umfangreichere Sammlung von Regelsets findet sich im GitHub Repository von caeksec. Bei der Auswahl des passenden Regelsets hilft das Google-Sheet von PenguinKeeper, das verschiedene Regelsets (und Wörterlisten) vergleicht und bewertet. Zu beachten ist jedoch, dass nicht alle Regelsets öffentlich verfügbar sind.
Beispiel für einen Wörterbuchangriff:
hashcat -m19700 hashes.txt -a0 hashmob.net_2025-11-23.small.found -r Fordyv4b.rule
Die Wahl von Passwortliste und Regelset muss dabei durch das Ausprobieren von verschiedenen Kombinationen stets an die verfügbaren Hardware-Ressourcen und die verfügbare Zeit angepasst werden. Damit sollte dann hoffentlich noch das ein oder andere weitere Passwort geknackt werden.
Welche Abwehrmassnahmen schützen vor Kerberoasting?
Auch wenn Kerberoasting tief in der Active-Directory-Architektur verwurzelt ist und nicht einfach so behoben werden kann, gibt es effektive Massnahmen, um das Risiko zu reduzieren oder einen Angriff zumindest erheblich zu erschweren.
Lange, komplexe Passwörter und Managed Service Accounts
Die effektivste Verteidigung gegen Kerberoasting ist simpel: die Verwendung von langen und komplexen Passwörtern für Dienstkonten mit SPNs, die nicht in gängigen Wörterlisten vorkommen oder auf bekannten Mustern basieren. Die Passwörter sollten mindestens 20 Zeichen umfassen und komplett zufällig aus Gross- und Kleinbuchstaben, Zahlen sowie Sonderzeichen generiert werden. Dies macht Hash-Cracking unmöglich.
Noch besser sind Group Managed Service Accounts (gMSAs). Bei dieser von Microsoft eingeführten Lösung werden automatisch komplexe, lange Passwörter generiert und regelmässig rotiert – und das ganz ohne administrativen Aufwand. gMSAs eliminieren das Kerberoasting-Risiko nahezu vollständig, da die Passwörter zu komplex und zu kurzlebig sind, um geknackt zu werden.
AES-Verschlüsselung statt RC4
Standardmässig nutzen viele Active-Directory-Umgebungen noch die RC4-Verschlüsselung für Kerberos-Tickets. Diese lässt sich deutlich schneller berechnen als AES. Die AES256-Verschlüsselung ist um einiges langsamer und sollte daher bevorzugt werden. Dies verhindert Kerberoasting nicht grundsätzlich, macht das Hash-Cracking aber erheblich aufwändiger und zeitintensiver.
Die bevorzugten Verschlüsselungstypen können über Gruppenrichtlinien auf Domänenebene festgelegt werden. In der Group Policy Management Console (gpmc.msc) kann unter Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options die Einstellung Network security: Configure encryption types allowed for Kerberos bearbeitet werden. Dort sollten die Optionen AES128_HMAC_SHA1, AES256_HMAC_SHA1 und Future encryption types aktiviert und die Option RC4_HMAC_MD5 deaktiviert werden.
Die Umstellung auf AES sollte sorgfältig getestet werden, da ältere Systeme oder Anwendungen möglicherweise nur RC4 unterstützen.
Monitoring und Detektion
Kerberoasting lässt sich nur schwer erkennen, da das Anfordern von TGS-Tickets ein legitimes Verhalten darstellt. Dennoch gibt es Event-IDs, die bei auffälligen Mustern Alarm schlagen sollten:
- Event-ID 4769: «A Kerberos service ticket was requested» – besonders verdächtig bei vielen Ticket-Anfragen in kurzer Zeit von einem einzelnen Account.
- Event-ID 4768: «A Kerberos authentication ticket (TGT) was requested» – kann auf eine initiale Kompromittierung hinweisen.
Die Erkennung erfordert zunächst eine Baseline der normalen Ticket-Anforderungsmuster pro Benutzer. Auf Basis dessen kann eine Anomalie-Erkennung implementiert werden, die bei ungewöhnlichen Mustern Alarm schlägt, beispielsweise, wenn ein Account plötzlich Dutzende von TGS-Tickets innerhalb weniger Minuten anfordert. Auch Honeypot-Accounts können hilfreich sein. Diese Dummy-Dienstkonten mit SPNs sollten nie legitim angefragt werden und erlauben es so, jede Ticket-Anfrage sofort als verdächtig einzustufen.
Fazit: effizienter Hash-Cracken dank systematischem Vorgehen
Auch über zehn Jahre nach seiner Entdeckung bleibt Kerberoasting eine beliebte Angriffstechnik gegen Active-Directory-Umgebungen. Die niedrige Einstiegshürde (ein einfacher Domänenbenutzer genügt) sowie die Möglichkeit, den Angriff grösstenteils offline durchzuführen, machen diese Technik besonders gefährlich.
Wie dieser Artikel zeigt, ist beim Cracken von Passwörtern ein methodischer Ansatz entscheidend – von Association Attacks als «Quick Win» über kontextspezifische Wörterlisten aus unternehmensspezifischen Begriffen bis hin zu generischen Wörterbuchangriffen mit Passwortlisten aus bekannten Datenlecks. Eine solche gestaffelte Vorgehensweise maximiert die Erfolgsquote beim Cracken der Hashes.
Für Unternehmen ist es essenziell, die Verwundbarkeit ihrer Active-Directory-Umgebung gegen solche Angriffe zu verstehen. Oneconsult kann Ihnen dabei helfen:
- Unser Active Directory Security Assessment deckt Schwachstellen wie anfällige Dienstkonten, veraltete Verschlüsselungsmethoden und fehlende Härtungsmassnahmen im Active Directory auf.
- Ergänzend zeigt ein Passwort-Audit auf, wie viele Ihrer Unternehmenspasswörter gegen moderne Cracking-Techniken standhalten würden.


