Kerberoasting – Angriff auf TGS-Tickets erklärt

Im ersten Teil haben wir uns angeschaut, wie Kerberos im Allgemeinen funktioniert. In diesem Artikel geht es nun um die Ausnutzung des bekannten Angriffsvektors „Kerberoasting“ und wie schwerwiegend dieser Angriff in einer Active Directory Umgebung tatsächlich sein kann. Außerdem schauen wir uns Vorkehrungen an, damit es gar nicht erst so weit kommt.

TGS-Ticket als Einfallstor

Wie funktioniert ein TGS-Ticket?

Da das Thema nicht ganz trivial ist, nochmal ein schneller Exkurs in Richtung „Wie funktioniert eigentlich Kerberos“. Im ersten Schritt holt sich der Client (normalerweise unsere domain-joined Workstation) bei der Anmeldung des Nutzers ein TGT (Ticket Granting Ticket) beim Domain Controller (AS-REQ/AS-REP). Mit diesem TGT hat sich der User erfolgreich an der Domäne authentifiziert.

Im nächsten Schritt möchte der Nutzer auf einen Service zugreifen, beispielsweise einen SQL-Server. Damit das möglich ist, kontaktiert der Client erneut den Domain Controller und fordert mit dem TGT ein Ticket für den jeweiligen Service an (TGS-REQ). Der Domain Controller stellt dem Nutzer daraufhin ein sogenanntes TGS-Ticket (Ticket Granting Service) aus (TGS-REP). Wichtig dabei, und das haben wir in Teil 1 bereits herausgearbeitet: Der Domain Controller prüft an dieser Stelle nicht, ob der anfragende User überhaupt berechtigt ist, auf den jeweiligen Service zuzugreifen. Jeder authentifizierte, auch unprivilegierte, Domänen-Nutzer kann für jedes Konto mit einem registrierten SPN ein TGS anfordern.

Das ausgestellte TGS-Ticket wird mit einem Schlüssel verschlüsselt, der aus dem Passwort des Service-Kontos abgeleitet wird (bei RC4 der NT-Hash, bei modernen Umgebungen der AES-Schlüssel). Und genau hier kann es zum Kerberoasting kommen. Klassischerweise laufen Dienste unter einem Computer-Konto. Dessen Passwort wird automatisch generiert und rotiert regelmäßig, ein Knacken ist damit praktisch aussichtslos. Kerberoasting wird aber genau dann gefährlich, wenn ein Service stattdessen unter einem regulären Benutzerkonto mit SPN läuft, zum Beispiel bei SQL-Server- oder sonstigen Anwendungsdienstkonten. Und das ist in der Praxis erschreckend häufig der Fall.

Wie entsteht der Angriffsvektor?

Dadurch, dass der Domain Controller nicht prüft, ob der Nutzer überhaupt berechtigt ist, für den jeweiligen Service ein TGS-Ticket anzufordern, kann der Angreifer für beliebige Services mit registriertem SPN Tickets anfordern. Das allein reicht aber noch nicht aus.

Wie wir in Teil 1 gesehen haben, kann der Domain Controller für ein TGS-Ticket nur Verschlüsselungstypen verwenden, für die er auch tatsächlich einen Schlüssel des Zielkontos besitzt (gesteuert über das msDS-SupportedEncryptionTypes Attribut). Aus der Schnittmenge dieser verfügbaren Typen und der vom Client im TGS-REQ angebotenen Liste wählt der Domain Controller den stärksten gemeinsamen Typ aus. Als Angreifer kann ich aber problemlos vorgeben, dass mein Client beispielsweise nur RC4 unterstützt. Sofern RC4 auf dem Ziel-Konto nicht explizit deaktiviert wurde, bleibt dem Domain Controller gar nichts anderes übrig, als das TGS-Ticket auch tatsächlich mit RC4 zu verschlüsseln.

Und wo liegt nun das eigentliche Problem? RC4 gilt mittlerweile als unsicher und veraltet. Der aus dem Kennwort abgeleitete Schlüssel entspricht dabei nur einer einzigen Iteration des MD4-Hashes, ganz ohne Salt. Das macht jeden einzelnen Cracking-Versuch um das Vielfache teurer. Genau dieser Unterschied ist der Grund, warum sich der RC4-Downgrade für Angreifer überhaupt lohnt.

Da der Domain Controller das TGS-Ticket lediglich an den Client übergibt, ohne selbst weitere Kontrolle darüber zu haben, kann der Angreifer damit machen, was er möchte. Klassischerweise übernimmt der Angreifer das Ticket auf ein Offline-System und versucht es via Brute-Force oder Rainbow-Tables zu knacken. Da das alles außerhalb der Domäne passiert, bekommen wir als Administratoren davon nichts mit. Wurde im Vorfeld ein schwaches Kennwort für das Service-Konto gewählt, kann das Kennwort unter Umständen vergleichsweise leicht geknackt werden. Hat der Angreifer das Kennwort erst einmal herausgefunden, kann er sich anschließend damit unbemerkt in der Domäne authentifizieren. Besitzt das Service-Konto dann noch administrative Berechtigungen, ist eine Übernahme der Domäne vorprogrammiert.

Wie sieht ein solcher Angriff aus?

In der Regel läuft ein Kerberoasting-Angriff nach folgendem High-Level-Schema ab:

1. Der Angreifer verschafft sich Zugriff auf ein normales Nutzerkonto ohne administrative Berechtigungen. Das kann über schwache Kennwörter der Nutzer oder Phishing-Versuche gelingen. Dieser Low-Level-Account reicht in den meisten Fällen bereits aus, um sich in der Domäne umzuschauen und Services bzw. deren Konten ausfindig zu machen.
2. Anschließend durchsucht der Angreifer per LDAP-Abfrage gegen den Domain Controller die Domäne nach Benutzerkonten mit gesetztem servicePrincipalName-Attribut. Tools wie PowerView oder Impacket automatisieren das. Gibt es interessante Ziele? Welche SPNs sind konfiguriert? Haben die jeweiligen Service-Konten ggf. sogar administrative Berechtigungen? Letzteres lässt sich mit Tools wie BloodHound besonders gut sichtbar machen, da diese die Berechtigungspfade innerhalb der Domäne grafisch aufbereiten.
3. Wurde ein solches Ziel ausgemacht, fordert der Angreifer ein TGS-Ticket an und gibt dabei, wie im vorherigen Kapitel beschrieben, gezielt nur RC4 als unterstützten Verschlüsselungstyp an. Das so verschlüsselte Ticket wird anschließend auf ein Offline-System des Angreifers übernommen.
4. Nun wird versucht, mittels Brute-Force oder Rainbow-Tables das Ticket zu knacken, etwa mit Hashcat oder John the Ripper. War dieser Prozess erfolgreich, hat der Angreifer das Klartextkennwort für das jeweilige Service-Konto ermittelt.
5. Mit dem Klartextkennwort des Service-Kontos kann sich der Angreifer nun innerhalb der Domäne authentifizieren und die damit einhergehenden privilegierten Berechtigungen für Lateral Movement oder, im schlimmsten Fall, für die vollständige Übernahme der Domäne ausnutzen.

Welche Vorkehrungen kann ich treffen?

Die wirksamste Vorkehrung gegen Kerberoasting sind starke, lange und zufällige Kennwörter für Service-Konten. Im Idealfall über sogenannte Group Managed Service Accounts. Dabei generiert und rotiert Windows automatisch ein bis zu 120 Zeichen langes Kennwort, das praktisch nicht zu knacken ist. Unabhängig davon, mit welchem Verschlüsselungstyp das TGS-Ticket am Ende verschlüsselt wird. Das ist der entscheidende Punkt: RC4 macht das Offline-Cracking dramatisch günstiger. Allerdings bleibt selbst ein AES-verschlüsseltes Ticket angreifbar, wenn das zugrunde liegende Kennwort schwach genug ist.

Wo eine Umstellung auf gMSA nicht möglich ist, sollte zusätzlich RC4 innerhalb der Domäne deaktiviert werden, um wenigstens die besonders kostengünstige Cracking-Variante zu unterbinden. Sollte dies nicht domänenweit umsetzbar sein, sollte RC4 zumindest für administrative Service-Konten über das Attribut msDS-SupportedEncryptionTypes deaktiviert werden.

Genauso wichtig: Service-Konten sollten konsequent nach dem Prinzip der geringsten Rechte konfiguriert werden. Ein geknacktes Kennwort ist deutlich weniger kritisch, wenn das betroffene Konto keine administrativen Berechtigungen besitzt und sich damit kein Lateral Movement oder gar eine Domain-Übernahme realisieren lässt.

Wie man prüft, ob RC4 noch verwendet wird und welche Policies dabei unterstützen, schauen wir uns im nächsten Artikel dazu an (Coming Soon). Windows Server 2025 deaktiviert RC4 übrigens standardmäßig und das kann gerade in alten Domänen Probleme verursachen. Solltest du dich dafür interessieren, kann ich dir den folgenden Blogpost empfehlen.