Kerberoasting – Wie funktioniert Kerberos

In diesem Artikel beschäftigen wir uns mit dem Authentifizierungsdienst Kerberos und dem in aller Munde befindlichen Angriffsvektor Kerberoasting. Mittels Kerberoasting kann es einem Angreifer gelingen, das Passwort eines privilegierten Benutzers innerhalb einer Active Directory Domäne zu knacken. Die dafür zu überwindende Hürde ist relativ gering. Es reicht schon eine schlecht konfigurierte Active Directory Domäne, sowie ein nicht-privilegierter AD Benutzer und genügend Zeit.

Da ich der Überzeugung bin, dass ein Administrator auch immer die Hintergrundinformationen kennen sollte, starten wir mit einem kleinen Deep Dive in die Kerberosauthentifizierung. Wer diesen Part überspringen möchte, kann direkt zu Teil 2 übergehen.

Ein kurzer Einblick zu Kerberos

Was ist Kerberos?

Kerberos wurde am MIT entwickelt und von Microsoft erstmalig in Windows 2000 implementiert. Gemeinsam mit NTLM bildet es die Schnittstelle zur Authentifizierung innerhalb einer Active Directory Domäne. Im Gegensatz zu NTLM (siehe dazu mehr in diesem Post) basiert Kerberos auf einer ticketbasierten Authentifizierung. Die Tickets werden vor der Übertragung verschlüsselt und sind somit besser gegen Pass-the-Hash, sowie Replay-Attacken geschützt.

Der Domain Controller fungiert als Key Distribution Center (KDC) und stellt Tickets für Clients, als auch Services (Ressourcen) aus. Die Authentifizierung beim jeweiligen Service erfolgt ausschließlich über die durch den KDC zuvor ausgestellten Tickets. Das eigentliche Passwort des Users ist für den Service somit nicht einsehbar. Gegenteilig zu NTLM, bei dem der NT-Hash immer vom User an den Service übermittelt wird.

Dir ist jetzt noch nicht klar, wie die Kommunikation abläuft? Keine Sorge, schauen wir uns die Funktionsweise gleich im nächsten Kapitel an.

Wie funktioniert Kerberos?

Um den Angriffsvektor von Kerberoasting besser zu verstehen, schauen wir uns zuerst die Funktionsweise von Kerberos anhand eines vereinfachten Beispiels an. Stellen wir uns also vor, ich bin auf meiner Windows-Workstation angemeldet und möchte nun auf den Fileserver zugreifen. Mein Client initiiert nun folgende Kommunikation.

Ticket Granting Ticket (TGT)

Zu Beginn möchte der Client ein sogenanntes Ticket Granting Ticket (TGT) vom Domain Controller (KDC) erhalten. Nach Erhalt des TGTs wird es im lokalen Speicher des Clients abgelegt.

1. Der Client initiiert die Verbindung, indem er den aktuellen Timestamp verschlüsselt mit dem aus seinem Kennwort abgeleiteten Schlüssel an den Domain Controller (KDC) schickt (AS-REQ). Dabei teilt er dem KDC auch mit, welche Verschlüsselungstypen er unterstützt – typischerweise in Präferenzreihenfolge AES256, AES128 und, falls noch aktiviert, RC4.
2. Der Domain Controller (KDC) prüft das Authentifizierungspaket des Clients. Da der KDC für jedes Konto den aus dem Kennwort abgeleiteten Schlüssel gespeichert hat (RC4/NT-Hash oder, in modernen Umgebungen, den AES-abgeleiteten Schlüssel), kann er das übermittelte Paket damit entschlüsseln. Hätte der Nutzer im ersten Schritt ein falsches Kennwort verwendet, wäre keine sinnvolle Entschlüsselung möglich, und der Timestamp-Vergleich würde fehlschlagen. Anschließend generiert der KDC ein TGT und schickt es zusammen mit einer Session-Key-Information an den Client zurück (AS-REP).
   Entscheidend dabei: Das TGT selbst wird nicht mit dem Schlüssel des anfragenden Nutzers verschlüsselt, sondern mit dem Schlüssel des krbtgt-Kontos – eines speziellen Kontos, das pro Domäne genau einmal existiert und dessen Schlüssel auf alle Domain Controller der Domäne repliziert wird. Deshalb kann jeder DC ein TGT validieren, unabhängig davon, welcher DC es ursprünglich ausgestellt hat. Welchen Verschlüsselungstyp der KDC dafür verwendet, hängt von den für das krbtgt-Konto verfügbaren Schlüsseln ab. Das TGT dient als Basis für alle zukünftigen Ticket-Anfragen. Der enthaltene Timestamp darf zwischen Domain Controller und Client standardmäßig maximal 5 Minuten auseinanderliegen; dies soll Replay-Angriffe verhindern.

Die ersten beiden Schritte passieren bereits direkt beim Login auf der Workstation. An dieser Stelle haben wir noch gar nicht bekanntgegeben, dass wir auf den Fileserver zugreifen möchten.

Ticket Granting Service Ticket (TGS) ausstellen

Mit dem zuvor ausgestellten TGT ist der Client nun in der Lage, sich beim Domain Controller sogenannte Ticket Granting Service (TGS) Tickets ausstellen zu lassen. Mit diesen findet dann der eigentliche Zugriff auf den jeweiligen Service (bspw. Fileserver) statt.

3. Der Client sendet das zuvor erhaltene TGT inklusive des Namens des gewünschten Services (Service Principal Name, SPN) an den Domain Controller (TGS-REQ).
4. Der Domain Controller entschlüsselt und prüft das TGT auf dessen Gültigkeit (mit dem ihm bekannten krbtgt-Schlüssel) und generiert daraufhin ein neues Ticket – das Ticket Granting Service (TGS) Ticket. Dieses wird nun aber mit dem Schlüssel des Ziel-Service-Kontos verschlüsselt (also z. B. dem NT-Hash oder AES-Schlüssel des Fileserver-Kontos), nicht mit dem Schlüssel des Clients. Welcher Verschlüsselungstyp dabei zum Einsatz kommt, bestimmt einzig das msDS-SupportedEncryptionTypes-Attribut des Service-Kontos. Hat dieses Konto nur einen RC4-Schlüssel hinterlegt, wird das TGS zwangsläufig mit RC4 verschlüsselt. Wichtig: Der KDC prüft an dieser Stelle nicht, ob der anfragende Client überhaupt berechtigt ist, auf den Service zuzugreifen. Jeder authentifizierte Domänen-Nutzer kann für jedes Konto mit einem registrierten SPN ein TGS anfordern – unabhängig von späteren Zugriffsrechten. Das TGS wird an den Client zurückgeschickt (TGS-REP).

Ticket Granting Service Ticket (TGS) verwenden

Mit diesem TGS ist der Client nun in der Lage, sich beim gewünschten Service zu melden. Durch das TGS hat der Domain Controller (KDC) lediglich bestätigt, dass sich der Client erfolgreich in der Domäne authentifiziert hat. Ob der Client tatsächlich Zugriff auf die Ressource hat, bestimmt ausschließlich der Service selbst – der Domain Controller und das TGS geben darüber keinerlei Auskunft.

5. Der Client schickt das TGS-Ticket an den Service, in unserem Beispiel den Fileserver (AP-REQ). Da das TGS mit dem Schlüssel des Fileserver-Kontos verschlüsselt wurde und dieser Schlüssel dem Fileserver bekannt ist, kann er das Ticket selbst entschlüsseln und auf Gültigkeit überprüfen. Ist das Ticket gültig, prüft der Service anschließend, ob der Nutzer die notwendigen Berechtigungen besitzt, um auf die Ressource zuzugreifen.

Genau diese beiden Eigenschaften: keine Autorisierungsprüfung durch den KDC bei der TGS-Ausstellung, und die Verschlüsselung des TGS mit dem Schlüssel des Ziel-Service-Kontos statt dem des Clients, sind die Grundlage dafür, warum Kerberoasting funktioniert. Dazu aber später mehr.

Ausschlaggebend ist bei Kerberos außerdem, dass die Kommunikation nur funktioniert, wenn mittels DNS-Auflösung gearbeitet wird. Würde ich als Nutzer den Fileserver nicht bei seinem DNS-Namen, sondern via IP ansprechen, käme nicht Kerberos, sondern NTLM zum Einsatz.

Welche Encryption Technologien gibt es?

Kerberos gibt es seit den frühen Windows Tagen (Windows 2000) und genießt dadurch natürlich eine lange Historie. Mit der Zeit haben sich aber unter anderem auch die Verschlüsselungsprotokolle geändert und verbessert. Protokolle, die zu Beginn State-of-the-Art waren, gelten mittlerweile als unsicher und sollten nicht mehr verwendet werden. Windows unterstützt durch seine Historie eine breite Palette dieser Protokolle und ein Großteil davon ist standardmäßig aktiviert.

Wie man an dieser Tabelle sehr gut erkennen kann, bringt Windows standardmäßig auch unsichere Verschlüsselungsprotokolle mit. Und genau das, in Kombination mit dem TGS-Ticket, erlaubt es einen Angreifer den Angriffsvektor Kerberoasting auszunutzen.

Nähere Informationen zu Encryption Types in Zusammenhang mit AD-Objekten findest du in diesem Blogpost.

Kerberos Ticket am Client

Alle Kerberos Tickets, welche für einen Client ausgestellt wurden, können direkt auf der Workstation in einer CMD abgerufen werden. Dazu dient der Befehl „klist„.

Loggt man sich auf einer Workstation neu ein, hat diese genau ein Ticket im Cache und zwar das TGT:

C:\Users\kschweiger>klist

Current LogonId is 0:0x1ec5e67d

Cached Tickets: (1)

#0>     Client: kschweiger @ TEST.SYSTEMS
        Server: krbtgt/TEST.SYSTEMS @ TEST.SYSTEMS
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0xe10000 -> renewable initial pre_authent name_canonicalize
        Start Time: 2/21/2025 20:16:48 (local)
        End Time:   2/22/2025 6:16:48 (local)
        Renew Time: 2/28/2025 20:16:48 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96
        Cache Flags: 0x1 -> PRIMARY
        Kdc Called: DC01

Würde ich nun auf den Fileserver zugreifen, würde mir der Domain Controller wie im Beispiel oben beschrieben ein TGS-Ticket ausstellen. Greift man im Laufe seines Arbeitstages also auf verschiedene Dienste zu und authentifiziert sich mittels Kerberos, speichert der Client für jeden Zugriff ein zusätzliches TGS-Ticket im Cache.

Und genau diese sich im Cache befindlichen Tickets dienen unter bestimmten Voraussetzungen als Angriffsvektor für Kerberoasting.

Fazit

Wir verwenden Kerberos tagtäglich, ohne zu wissen, wie es im Hintergrund eigentlich funktioniert. Ich hoffe, ich konnte mit diesem „oberflächlichen“ Deep Dive einen kleinen und verständlichen Einblick gewähren. Da wir nun die Basics geklärt haben, können wir im nächsten Artikel auf das eigentliche Thema – Kerberoasting – eingehen.