Kerberoasting erklärt: vom normalen AD-Benutzer zum Domain Admin

Geben Sie uns ein einziges gültiges Domänenkonto in nahezu jedem Active-Directory-Netzwerk, und die Chancen stehen gut, dass wir noch vor der Mittagspause mit dem Passwort eines Dienstkontos wieder hinausgehen. Kein Exploit. Keine Malware. Keine Administratorrechte. Nur Kerberos, das genau das tut, wofür es entworfen wurde. Das ist ein Kerberoasting-Angriff, und er zählt nach wie vor zu den zuverlässigsten Wegen vom gewöhnlichen Benutzer zum Domain Admin, auf die wir bei internen Tests stoßen.

Hartnäckig macht ihn, dass es keinen Patch dagegen gibt. Die Schwachstelle ist ein ganzer Stapel von Dienstkonten mit schwachen, von Menschen gewählten Passwörtern, die nie rotiert werden und hinter einem Protokoll sitzen, das jedem authentifizierten Benutzer das Material aushändigt, das er zum Knacken braucht. Ein Kerberoasting-Angriff ist leise, geduldig und läuft fast vollständig offline ab. Genau diese Kombination ist der Grund, warum Verteidiger ihn immer wieder übersehen.

Im Folgenden gehen wir durch, wie Kerberos-Diensttickets funktionieren, warum ein Service Principal Name (SPN) Dienstkonten ins Fadenkreuz rückt, wie sich der Angriff bis zur Dominanz über die Domäne fortsetzt und welche Gegenmaßnahmen den Kontakt mit der Produktion tatsächlich überstehen. Die Technik entspricht MITRE ATT&CK T1558.003.

Wichtigste Erkenntnisse

• Ein Kerberoasting-Angriff erlaubt es jedem authentifizierten Domänenbenutzer, Kerberos-Diensttickets für Konten mit einem SPN anzufordern und diese Tickets anschließend offline zu knacken, um das Klartextpasswort zu gewinnen. Erhöhte Rechte sind nicht nötig.
• Das Ticket wird mit einem Schlüssel verschlüsselt, der aus dem Passwort des Dienstkontos abgeleitet ist. Schwache oder veraltete Passwörter fallen daher schnell gegen hashcat, vor allem wenn RC4 (Verschlüsselungstyp 0x17) noch erlaubt ist.
• Dienstkonten sind routinemäßig mit zu vielen Rechten ausgestattet, sodass ein einziges geknacktes Passwort oft lokale Administratorrechte auf vielen Hosts, Zugriff auf sensible Daten oder einen direkten Weg zum Domain Admin bedeutet.
• Die Erkennung stützt sich auf Anomalien im Kerberos-Ereignis 4769 (RC4-Anfragen, hohes Volumen von einem einzelnen Benutzer) sowie auf Honeypot-SPN-Konten, die kein echter Dienst jemals abfragen sollte.
• Die dauerhafte Lösung sind group Managed Service Accounts (gMSAs) oder zufällige Passwörter mit 25 und mehr Zeichen, die Durchsetzung von AES, das Entfernen ungenutzter SPNs und das Least-Privilege-Prinzip, gestützt durch ein Admin-Tiering.

Was ist ein Kerberoasting-Angriff?

Ein Kerberoasting-Angriff ist eine Offline-Technik zum Knacken von Passwörtern, die auf Dienstkonten in Active Directory abzielt. Jeder Domänenbenutzer kann bei einem Domain Controller ein Dienstticket für ein beliebiges Konto mit registriertem SPN anfordern. Ein Teil dieses Tickets ist mit einem Schlüssel verschlüsselt, der aus dem Passwort des Dienstkontos abgeleitet ist. Der Angreifer schnappt sich das Ticket, verschwindet und knackt das Passwort per Brute Force auf der eigenen Hardware, ohne den Domain Controller je wieder anzufassen.

Die Gefahr liegt in der Asymmetrie. Ein Ticket anzufordern ist eine ganz normale Handlung, die jede Arbeitsstation hunderte Male am Tag ausführt, also geht sie im Grundrauschen unter. Das Knacken geschieht auf der Hardware des Angreifers, unsichtbar für Ihre Protokolle. Und die Konten, die am ehesten einen SPN tragen, etwa SQL Server, IIS-Anwendungspools und diverse HTTP- oder MSSQL-Dienste, sind meist genau jene mit dem weitesten Zugriff und den ältesten Passwörtern. Das ist die denkbar schlechteste Kombination.

Wie funktionieren Kerberos-Diensttickets eigentlich?

Die Kerberos-Authentifizierung hat drei bewegliche Teile: den Client, das Key Distribution Center (KDC, das auf jedem Domain Controller läuft) und den Zieldienst. Wenn Sie sich anmelden, sendet der Client einen AS-REQ und erhält im AS-REP ein Ticket Granting Ticket (TGT) zurück. Das TGT ist der Nachweis, wer Sie sind.

Wenn Sie einen Dienst erreichen wollen, legt der Client dieses TGT vor und sendet einen TGS-REQ, der den SPN benennt, etwa MSSQLSvc/db01.acme-corp.local:1433. Das KDC antwortet mit einem TGS-REP, das ein Dienstticket enthält. Hier kommt das entscheidende Detail: Das Ticket wird mit dem langfristigen Schlüssel des Kontos verschlüsselt, dem der SPN gehört. Bei RC4 ist dieser Schlüssel buchstäblich der NT-Hash des Kontos. Bei AES ist es ein Schlüssel, der aus dem Passwort und einem Salt abgeleitet wird.

Jetzt der Teil, den Angreifer lieben. Das KDC prüft nie, ob Sie den Dienst überhaupt nutzen dürfen. Es bestätigt nur, dass Sie ein gültiges TGT besitzen, und gibt dann ein Ticket zurück, das mit dem Schlüssel des Dienstkontos verschlüsselt ist. Die Autorisierung erfolgt erst später, beim Dienst selbst. Das KDC überreicht also bereitwillig jedem authentifizierten Benutzer einen verschlüsselten Blob, der aus dem Passwort eines beliebigen Dienstkontos abgeleitet ist. Man muss nur höflich fragen, und es sagt Ja.

Was ist ein SPN, und warum sind Dienstkonten das Ziel?

Ein Service Principal Name ist eine eindeutige Zeichenkette, die eine Dienstinstanz mit dem Konto verknüpft, unter dem sie läuft, damit Kerberos weiß, wessen Schlüssel es beim Verschlüsseln des Tickets verwenden muss. Auch Computerkonten haben SPNs, doch ihre Passwörter sind lange Zufallszeichenketten, die von selbst rotieren, was sie praktisch unknackbar macht. Die weichen Ziele sind Benutzerkonten mit SPNs: die Dienstkonten der Domäne, die ein Mensch von Hand angelegt und konfiguriert hat.

Genau dort sammelt sich das Risiko. In unseren Projekten finden wir regelmäßig Dienstkonten mit Passwörtern, die vor fünf oder mehr Jahren gesetzt wurden, ausgewählt von einem Administrator, der sich etwas Merkbares wünschte, und häufig über mehrere Umgebungen hinweg wiederverwendet. Ausnahmen von der Passwortrichtlinie sind hier die Regel, weil “die Anwendung kaputtgeht, wenn das Passwort rotiert.” Diese Konten zu finden ist für jedes Domänenmitglied trivial, denn SPNs sind lesbare Verzeichnisattribute. Eine einzige Zeile fördert sie zutage:

# Native, no tooling required
setspn -Q */*

# Impacket, from a non-domain-joined attacker box
GetUserSPNs.py acme-corp.local/lowpriv:'Password123' -dc-ip 10.0.0.10 -request

# Or on-host with Rubeus
Rubeus.exe kerberoast /outfile:hashes.txt

Wie läuft der Kerberoasting-Angriff Schritt für Schritt ab?

Der Angriff ist kurz und braucht nichts weiter als ein funktionierendes Domänenkonto. Konten mit einem SPN aufzählen, für jedes ein TGS anfordern, den verschlüsselten Teil jedes Tickets extrahieren und ihn dann offline knacken. Vier Schritte, und nur die ersten beiden berühren das Netzwerk.

In der Anforderungsphase erledigen Rubeus und Impackets GetUserSPNs ihre Arbeit. Sie durchsuchen das Verzeichnis nach Benutzerobjekten mit gesetztem servicePrincipalName, feuern für jedes einen TGS-REQ ab und formatieren die zurückgegebenen Tickets in hashcat-fertige Strings. Die meisten Werkzeuge lassen einen zudem RC4 erzwingen, um den schnellsten Hash-Typ zurückzubekommen, und genau dieses Verhalten kann ein Verteidiger beobachten. Ein RC4-Kerberoast-Hash beginnt mit $krb5tgs$23$; AES256 kommt als $krb5tgs$18$ zurück.

Die Knackphase ist reine Offline-Rechenarbeit. RC4-Tickets nutzen den hashcat-Modus 13100. AES-Tickets sind langsamer, zerbröseln aber immer noch an einer ordentlichen Wortliste, und zwar mit den Modi 19600 (AES128) und 19700 (AES256).

# RC4 (etype 23 / 0x17) - fastest to crack
hashcat -m 13100 hashes.txt rockyou.txt -r rules/best64.rule

# AES256 (etype 18) - slower, still viable against weak passwords
hashcat -m 19700 hashes.txt rockyou.txt

Beachten Sie, dass während des Knackens nichts mehr an den Domain Controller zurückmeldet. Sind die Tickets erst einmal erfasst, kann der Angreifer das Netzwerkkabel ziehen und einfach weiterrechnen. Ein kurzes oder wörterbuchbasiertes Passwort kann in Minuten fallen. Deshalb entscheidet die Stärke des Dienstkonto-Passworts über das ganze Spiel.

Warum machen schwache Dienstkonto-Passwörter das so gefährlich?

Weil die gesamte Verteidigung des verschlüsselten Tickets allein auf der Entropie des Passworts beruht, auf sonst nichts. Kerberos begrenzt das Raten im Offline-Betrieb nicht. Es gibt keine Kontosperrung. Es gibt keine Warnung, sobald das Ticket das KDC verlassen hat. Ein Passwort aus zehn Zeichen, gebaut aus einem Wörterbuchwort und zwei Ziffern, ist für eine moderne GPU keine Bremsschwelle. Ein wirklich zufälliges Passwort mit 25 Zeichen ist eine Mauer.

Wiederverwendung und Überalterung verschlimmern es. Passwörter von Dienstkonten ändern sich fast nie, sodass eines, das Sie heute knacken, seit Jahren gültig sein kann und zugleich in Test, Staging und Produktion. Wir haben erlebt, wie ein einziges geknacktes Konto Dutzende Server aufschloss, nur weil es auf jeder Maschine, auf der es lief, in die lokale Gruppe der Administratoren aufgenommen worden war.

Wie führt Kerberoasting in einer Kette zum Domain Admin?

Das Knacken des Passworts ist der Wendepunkt, nicht das Ziel. Was danach kommt, hängt davon ab, wie privilegiert das Konto ist, und Dienstkonten sind berüchtigt für schleichende Rechteausweitung. Die Ketten, die wir am häufigsten sehen, sehen so aus:

• Das Konto ist auf vielen Hosts lokaler Administrator, also erhalten wir Codeausführung und ziehen auf jedem davon weitere Anmeldedaten aus LSASS, wobei wir unterwegs zwischengespeicherte Domain-Admin-Sitzungen einsammeln.
• Das Konto wurde direkt in Domain Admins oder eine ähnlich mächtige Gruppe aufgenommen, meist “vorübergehend” während einer Migration, und dann nie wieder entfernt. Das ist das ganze Projekt in einer einzigen Zeile.
• Das Konto besitzt gefährliche Verzeichnisrechte, etwa die Möglichkeit, die Passwörter anderer Benutzer zurückzusetzen oder die Mitgliedschaft in einer Gruppe zu schreiben, was BloodHound als Pfad in Tier 0 einzeichnet.

Der Punkt ist, dass ein Kerberoasting-Angriff selten bei einem einzigen Konto endet. Er ist ein Standbein, das sich in laterale Bewegung und dann in Rechteausweitung verwandelt, und die kürzesten Wege zum Domain Admin sind fast immer jene, von denen niemand wusste, dass es sie gibt. BloodHound macht diese Wege schnell auffindbar, für den Angreifer wie für Sie.

Wie erkennt man einen Kerberoasting-Angriff?

Die Erkennung dreht sich um Anfragen nach Kerberos-Diensttickets, die auf Domain Controllern als Ereignis 4769 protokolliert werden. Für sich genommen sind diese Ereignisse reines Rauschen. Das Signal steckt im Muster. Achten Sie auf ein einzelnes Benutzerkonto, das in einem engen Zeitfenster Tickets für eine große Zahl unterschiedlicher SPNs anfordert, und besonders auf Anfragen, die RC4 (Ticket-Verschlüsselungstyp 0x17) in einer Umgebung verlangen, die eigentlich AES verwenden sollte. Moderne Clients handeln standardmäßig AES aus, daher ist ein Schwall von RC4-Anfragen ein klassischer Kerberoasting-Fingerabdruck.

Die aussagekräftigste Maßnahme, die wir empfehlen, ist ein Honeypot-SPN. Richten Sie ein Köder-Benutzerkonto ein, hängen Sie ihm einen SPN an, der auf keinen echten Dienst verweist, geben Sie ihm ein langes Zufallspasswort und rühren Sie es nie wieder an. Kein legitimer Prozess sollte jemals dessen Ticket anfordern, sodass ein einziges 4769-Ereignis, das dieses Konto nennt, ein nahezu sicherer Einbruchsindikator mit fast keinen Fehlalarmen ist. Kombinieren Sie das mit einer Warnung bei ungewöhnlichem RC4-Volumen, und Sie fangen das meiste opportunistische Roasting ab, noch bevor das Knacken überhaupt fertig ist.

Wie verhindert man Kerberoasting?

Prävention läuft darauf hinaus, die beiden Zutaten zu beseitigen: schwache Passwörter und unnötige Angriffsfläche. In der Reihenfolge der Priorität raten wir unseren Kunden zu Folgendem.

• Wechseln Sie zu gMSAs. Group Managed Service Accounts erhalten lange Zufallspasswörter, die die Domäne von selbst rotiert, sodass ihre Tickets praktisch unknackbar sind. Migrieren Sie jedes Dienstkonto, das eines unterstützen kann.
• Verwenden Sie lange Zufallspasswörter, wo gMSAs nicht passen. Für Konten, die Standard-Benutzerobjekte bleiben müssen, setzen Sie ein Zufallspasswort mit 25 und mehr Zeichen. Bei dieser Länge lohnt sich selbst ein RC4-Ticket nicht mehr zum Knacken.
• Erzwingen Sie AES und stellen Sie RC4 ein. Setzen Sie msDS-SupportedEncryptionTypes auf ausschließlich AES und schaffen Sie RC4 domänenweit ab. Das verlangsamt jeden Knackversuch und verwandelt jede verbliebene RC4-Anfrage in ein sauberes Erkennungssignal.
• Wenden Sie das Least-Privilege-Prinzip an. Nehmen Sie Dienstkonten aus Domain Admins und anderen Tier-0-Gruppen heraus, gewähren Sie nur die Rechte, die der Dienst wirklich braucht, und prüfen Sie die Mitgliedschaft in lokalen Administratorgruppen.
• Entfernen Sie veraltete SPNs. Jeder SPN auf einem Benutzerkonto ist Angriffsfläche. Streichen Sie SPNs von Konten, die den betreffenden Dienst nicht mehr betreiben.
• Führen Sie ein Admin-Tiering ein. Isolieren Sie Tier-0-Identitäten, damit ein geknacktes Anwendungs-Dienstkonto Domänencontroller oder Domain-Admin-Anmeldedaten gar nicht erst erreichen kann.

Wie CyberXplore hilft

Kerberoasting gehört zu den ersten Dingen, nach denen unser Team bei jedem internen Projekt greift, denn es ist schnell, leise und funktioniert so oft. Unser Active Directory Security Assessment bildet Ihre realen Angriffspfade so ab, wie es ein Eindringling täte: Es zählt SPNs auf, prüft die Passwortstärke von Dienstkonten und verfolgt jede Kette, die beim Domain Admin endet, und übergibt Ihnen anschließend eine priorisierte Liste von Gegenmaßnahmen rund um gMSAs, AES-Durchsetzung und Tiering. Wenn Sie wissen wollen, ob ein einziger per Phishing kompromittierter Benutzer Ihre gesamte Domäne übernehmen könnte, fordern Sie ein Angebot an, und wir zeigen Ihnen genau, wie weit es reicht.

FAQ

Benötigt ein Kerberoasting-Angriff Administratorrechte?

Nein, und genau deshalb ist er überall zu finden. Jedes authentifizierte Domänenkonto, einschließlich eines Benutzers mit geringen Rechten oder eines kompromittierten Dienstes, kann SPNs aufzählen und Diensttickets anfordern. Das KDC prüft vor der Ausstellung des Tickets keine Autorisierung, sodass keine besonderen Rechte nötig sind, um mit knackbarem Material davonzukommen.

Stoppt der Umstieg auf AES Kerberoasting vollständig?

Nein, aber es hilft erheblich. AES-Tickets lassen sich weitaus langsamer knacken als RC4, sodass ein starkes Passwort hinter AES praktisch sicher ist. Dennoch kann ein schwaches Passwort hinter AES immer noch fallen, weshalb AES kein Ersatz für lange Zufallspasswörter oder gMSAs ist. Es durchzusetzen verwandelt zudem jede übrig gebliebene RC4-Anfrage in ein nützliches Erkennungssignal.

Wie lange dauert es, einen Kerberoast-Hash zu knacken?

Das hängt ganz von der Passwortstärke und dem Verschlüsselungstyp ab. Ein schwaches RC4-Ticket, das auf einem Wörterbuchwort beruht, kann auf einer modernen GPU in Sekunden bis Minuten fallen. Ein wirklich zufälliges Passwort mit 25 Zeichen oder ein gMSA-Passwort lässt sich in keinem praktikablen Zeitraum knacken. Es gibt keine serverseitige Sperre, die den Angreifer ausbremst, also ist Entropie die einzige Verteidigung, die zählt.

Was ist der Unterschied zwischen Kerberoasting und AS-REP-Roasting?

Beide knacken Kerberos-Material offline, treffen aber Unterschiedliches. Kerberoasting (T1558.003) greift Dienstkonten mit SPNs an, indem es Diensttickets knackt. AS-REP-Roasting (T1558.004) zielt auf Konten, bei denen die Kerberos-Vorauthentifizierung deaktiviert ist, und knackt stattdessen das AS-REP. AS-REP-Roasting lässt sich ganz ohne gültige Anmeldedaten durchführen, solange man einen Zielbenutzernamen kennt.

Sind gMSAs wirklich immun gegen Kerberoasting?

Für die Praxis ja. Ein gMSA-Passwort ist ein langer Zufallswert, den die Domäne automatisch rotiert, sodass sein Ticket zwar angefordert und erfasst werden kann, das Knacken aber undurchführbar ist. Der eine Vorbehalt: Wer das Recht erhält, das verwaltete Passwort des gMSA zu lesen, kann es direkt abrufen, also hüten Sie diese Berechtigung sorgfältig.

Wie kann ich testen, ob meine Domäne verwundbar ist?

Führen Sie eine kontrollierte Aufzählung der Konten mit SPNs durch und bewerten Sie deren Passwortstärke, idealerweise als Teil einer vollständigen Active-Directory-Bewertung. Impackets GetUserSPNs oder Rubeus fördern jedes roastbare Konto zutage, und Honeypot-SPNs plus die Überwachung von Ereignis 4769 sagen Ihnen, ob bereits Versuche im Gange sind. Wenn Sie das als autorisierte Übung tun, erhalten Sie dieselbe Sicht wie ein Angreifer, bevor er sie sich nimmt.