Kerberoasting: Passwörter von Dienstkonten knacken, ohne den Domänencontroller je anzurühren

Bei Active-Directory-Audits gehört Kerberoasting zu den Angriffen, die systematisch geprüft werden, so effizient, schnell und unauffällig ist diese Technik. Innerhalb von Sekunden kann ein einfaches Benutzerkonto ohne jegliche Privilegien genug Material beschaffen, um offline und lautlos die Passwörter von teils sehr mächtigen Konten zu knacken. Dieser Artikel erläutert die Funktionsweise, warum der Angriff so oft gelingt und vor allem, wie man sich davor schützt.

Ein wenig Kerberos und SPN

In einer Windows-Domäne basiert die Authentifizierung auf Kerberos, einem Protokoll, das auf vom Domänencontroller ausgestellten Tickets beruht. Das Prinzip stammt aus den 1980er-Jahren (Projekt Athena am MIT), und Microsoft hat es seit Windows 2000 als Standard-Authentifizierungsmechanismus übernommen. Jeder über Kerberos erreichbare Dienst wird durch einen SPN identifiziert, kurz für Service Principal Name, eine Kennung wie MSSQLSvc/serveur.entreprise.local:1433, die einen Dienst (eine SQL-Datenbank, einen Webserver, eine Freigabe) mit einem Dienstkonto im Verzeichnis verknüpft.

Zur Erinnerung: Ein Dienstkonto ist ein Benutzerkonto, das eigens dafür bestimmt ist, eine Anwendung auszuführen. Es verfügt oft über hohe Rechte, und sein Passwort wird selten geändert, weil eine Änderung die davon abhängige Anwendung unterbrechen könnte. Ein Geheimnis, das schlecht altert.

Warum Dienstkonten so anziehend sind

Diese Konten vereinen alle Schwächen, nach denen ein Angreifer sucht. Sie wurden vor langer Zeit angelegt, oft bei der Installation einer Software, mit einem Passwort, das ein eiliger Administrator von Hand gewählt hat. Dieses Passwort läuft in der Regel nie ab, denn ein Ablauf würde einen Anwendungsausfall bedeuten. Obendrein landen diese Konten häufig in hochprivilegierten Gruppen, manchmal sogar bei den Domänen-Admins, „bis die Anwendung läuft“, und dann wird vergessen, die Änderung rückgängig zu machen. Ein Angreifer weiß das und nimmt diese SPN bevorzugt ins Visier.

Der Mechanismus des Angriffs

Der Kernpunkt lässt sich in einem Satz zusammenfassen: Jeder authentifizierte Benutzer der Domäne kann für jeden beliebigen SPN ein Dienstticket anfordern (ein TGS, für Ticket-Granting Service). Das ist völlig normales Kerberos-Verhalten, keine Schwachstelle. Ein Teil dieses Tickets ist jedoch mit einem Schlüssel verschlüsselt, der direkt vom Passwort des Dienstkontos abgeleitet ist. Wer das Ticket erhält, besitzt damit eine verschlüsselte Probe, die sich in aller Ruhe angreifen lässt.

Der Angreifer zählt die SPN des Verzeichnisses auf, fordert die entsprechenden Tickets an und extrahiert sie. Mit GetUserSPNs.py aus der Impacket-Suite genügt unter Linux ein einziger Befehl:

GetUserSPNs.py entreprise.local/utilisateur:MotDePasse -request -outputfile tickets.txt

Unter Windows erledigt das Tool Rubeus dasselbe von einem bereits kompromittierten Arbeitsplatz aus und kann gezielt die interessantesten Konten anvisieren:

Rubeus.exe kerberoast /outfile:tickets.txt

Entscheidender Punkt: Zu keinem Zeitpunkt muss der Angreifer auf den Domänencontroller schreiben oder Passwörter gegen ihn testen. Das gesamte Cracking erfolgt anschließend offline auf seinem eigenen Rechner. Es gibt also weder gesperrte Konten noch eine sichtbare Häufung fehlgeschlagener Anmeldungen in den Logs.

Das Offline-Cracking

Sobald die Tickets vorliegen, übergibt der Angreifer sie einem Cracking-Tool wie hashcat. Das Kerberos-TGS-Format entspricht dem Modus 13100:

hashcat -m 13100 tickets.txt dictionnaire.txt -r regles.rule

Der Parameter -r wendet ein Regelwerk an, das menschliche Gewohnheiten nachbildet: Großbuchstabe am Anfang, Ziffer am Ende, klassische Ersetzungen. Gegen ein schwaches Passwort wie Serveur2021 liegt das Ergebnis auf einem einfachen Laptop mit Grafikkarte in wenigen Sekunden vor. Und genau hier liegt das Problem:

• Dienstkonten haben oft kurze Passwörter, die vor Jahren von einem Menschen gewählt wurden;
• sie werden fast nie erneuert;
• sie bündeln hohe Privilegien, mitunter bis zur vollständigen Administration der Domäne.

Ein einziges geknacktes schwaches Passwort, und der Angreifer erbt direkt die Rechte des Kontos, ohne Exploit und ohne zusätzliche Rechteausweitung. Eine spektakuläre Abkürzung von „ich bin irgendein Benutzer“ zu „ich kontrolliere das Verzeichnis“.

RC4, der unauffällige Treibstoff des Angriffs

Ein technisches Detail verschärft die Lage oft: Aus Kompatibilitätsgründen werden viele Tickets noch mit dem Algorithmus RC4 verschlüsselt, der vom NTLM-Hash des Passworts abgeleitet ist. RC4 eignet sich jedoch besonders gut für massenhaftes Cracking. Wird für Dienstkonten die Verwendung von AES erzwungen, verteuert sich das Cracking deutlich. Die Angriffswerkzeuge wissen das: Rubeus etwa fordert bevorzugt RC4-Tickets an, wenn sie verfügbar sind, gerade weil sie leichter zu verarbeiten sind.

Was die Praxis zeigt

Bei einem typischen Einsatz liefert die Aufzählung regelmäßig mehrere Dutzend SPN. Es genügt, dass einer davon zu einem Konto mit veraltetem Passwort gehört, um eine Lücke zu öffnen. Backup-, Monitoring- oder Datenbankkonten tauchen häufig auf, oft mit hohen Privilegien ausgestattet und durch ein Passwort geschützt, das aus dem Namen des Softwareherstellers und einer Jahreszahl besteht. Die geschäftlichen Auswirkungen sind unmittelbar: Wer ein solches Konto kontrolliert, kontrolliert die Authentifizierung des gesamten Unternehmens. Die Oxyscan BOX erkennt genau diese für Kerberoasting anfälligen Dienstkonten im gesamten Verzeichnis, sodass sie korrigiert werden können, bevor ein Angreifer sie findet.

Die Schwachstelle beheben: Umstieg auf verwaltete Dienstkonten

Da Kerberoasting keinen Softwarefehler ausnutzt, sondern die Schwäche eines Passworts, besteht die Korrektur darin, dieses Passwort unknackbar zu machen. Gruppenverwaltete Dienstkonten (gMSA, für group Managed Service Accounts) erfüllen genau diesen Zweck: Ihr Passwort wird von der Domäne zufällig erzeugt, umfasst 240 Byte und wird automatisch erneuert, ganz ohne menschliches Zutun. Ein Angreifer, der ein mit einem solchen Geheimnis verschlüsseltes Ticket erbeutet, kann so viele Grafikkarten darauf ansetzen, wie er will, er wird es nicht herausfinden.

Zur Erinnerung: Genau so verhalten sich bereits Computerkonten (deren Name auf $ endet): Ihr Passwort ist zufällig und sehr lang, was sie gegen Kerberoasting immun macht. Das gMSA überträgt dieses Prinzip lediglich auf die Konten, unter denen Anwendungsdienste laufen.

Die Einrichtung erfordert drei PowerShell-Befehle auf dem Domänencontroller. Zunächst wird, einmalig für die gesamte Domäne, der Stammschlüssel des Schlüsselverteilungsdienstes (KDS) erzeugt:

Add-KdsRootKey -EffectiveImmediately

Trotz ihres Namens macht die Option -EffectiveImmediately den Schlüssel erst nach seiner Replikation auf alle Domänencontroller nutzbar, mit einer Sicherheitsverzögerung von bis zu zehn Stunden. Diese Wartezeit ist in der Produktion einzuhalten. Anschließend wird das verwaltete Konto angelegt, unter Angabe seines DNS-Namens und des oder der Hosts, die sein Passwort abrufen dürfen:

New-ADServiceAccount -Name sql-service -DNSHostName sql-service.exemple.local -PrincipalsAllowedToRetrieveManagedPassword "GRP-SRV-SQL$"

Danach wird das Konto auf dem Rechner installiert, der den Dienst ausführen soll:

Install-ADServiceAccount sql-service

Es bleibt nur noch, dieses Konto als Identität des Dienstes festzulegen. Im Server-Manager wird das verwaltete Konto, erkennbar am Suffix $, als benutzerdefiniertes Konto eingetragen, hier für die Identität eines IIS-Anwendungspools:

Noch nicht jede Software kann mit einem gMSA arbeiten. Für diese Restfälle gilt eine doppelte Regel: ein zufällig erzeugtes Passwort mit mindestens fünfundzwanzig Zeichen, das in einem Tresor verwahrt wird, und die strikte Einhaltung des Least-Privilege-Prinzips, denn ein Dienstkonto muss so gut wie nie Mitglied der Domänen-Admins sein. Zusätzlich wird die AES-Verschlüsselung der Tickets erzwungen, die sich deutlich schwerer knacken lässt als das veraltete RC4, und auffällig zahlreiche Anfragen nach Diensttickets werden überwacht, oft das erste Anzeichen einer laufenden Kerberoasting-Kampagne.

Fazit

Kerberoasting nutzt keinen Bug aus, sondern ein schlechtes Passwort auf einem zu mächtigen Konto. Deshalb zählt es zu den lohnendsten Techniken für einen internen Angreifer und zu den am leichtesten vernachlässigten auf Seiten der Verteidigung. Die gute Nachricht: Die Gegenmaßnahmen sind bekannt, dokumentiert (insbesondere von MITRE und der ANSSI) und wirksam.

Empfehlungen: Dienstkonten sehr lange Passwörter (25 Zeichen und mehr) zuweisen oder, besser, auf gruppenverwaltete Dienstkonten (gMSA) migrieren, deren Passwort automatisch von der Domäne erneuert wird; das Least-Privilege-Prinzip anwenden (kein Dienstkonto sollte ohne stichhaltige Begründung Domänen-Admin sein), AES-Verschlüsselung statt RC4 erzwingen und massenhafte TGS-Ticketanfragen überwachen, oft das erste Anzeichen eines laufenden Angriffs.

Weiterführende Informationen

• Cybersicherheitsberatung und Begleitung durch Oxydian, um die Härtung eines Verzeichnisses umzusetzen (gMSA, AES-Verschlüsselung, Least Privilege).
• Warum Unternehmenspasswörter bei Audits fallen, der Artikel über Offline-Cracking und den Umgang mit Geheimnissen.
• MITRE ATT&CK, Technik T1558.003 (Kerberoasting), Beschreibung, Erkennung und Gegenmaßnahmen.
• ANSSI, Empfehlungen zur Absicherung eines Active-Directory-Verzeichnisses.
• Microsoft Learn, Übersicht über gruppenverwaltete Dienstkonten (gMSA).
• hashcat, das Referenzwerkzeug für Offline-Cracking (Modus 13100 für Kerberos-Tickets).
• Impacket-Suite (GetUserSPNs.py), der Open-Source-Werkzeugkasten zum Sammeln der Tickets.