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 (coming soon!) übergehen.

Eine 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 seinen NT-Hash und den aktuellen Timestamp verschlüsselt an den Domain Controller (KDC) schickt.
2. Der Domain Controller (KDC) prüft das Authentifizierungspaket des Clients und erstellt ein verschlüsseltes Ticket Granting Ticket (TGT). Dieses TGT kann ausschließlich vom Domain Controller entschlüsselt werden und dient als zukünftige Basis für neue Tickets. Das ist auch der Grund, warum der Timestamp zwischen Domain Controller und Client standardmäßig maximal 5 Minuten auseinander liegen darf und soll Replay-Attacken 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)

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 den Namen des gewünschten Services (Service Principal Name) an den Domain Controller.
4. Der Domain Controller überprüft das TGT auf dessen Gültigkeit und verschlüsselt es anschließend mit dem NT-Hash des jeweiligen Services (NT-Hash des AD-Kontos). Das somit erhaltene Ticket Granting Service (TGS) Ticket wird an den Client zurückgeschickt.

Mit diesem Ticket Granting Service (TGS) Ticket ist der Client nun in der Lage, sich beim gewünschten Service zu melden. Durch das TGS hat der Domain Controller (KDC) bestätigt, dass der Client sich erfolgreich in der Domäne authentifiziert hat. Ob der Client allerdings überhaupt Zugriff auf die Resource hat, bestimmt 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 dem Fileserver). Da das TGS-Ticket mit dem NT-Hash des Fileservers verschlüsselt wurde und der Hash dem Fileserver bekannt ist, kann dieser nun selbst das Ticket auf Validität überprüfen. Ist das Ticket gültig überprüft der Service anschließend, ob der Nutzer die notwendigen Berechtigungen besitzt, um auf die Ressource zuzugreifen.

Ausschlaggebend ist bei Kerberos auch, 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, würde nicht Kerberos, sondern NTLM zum Einsatz kommen.

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 erlaubt es einen Angreifer den Angriffsvektor Kerberoasting auszunutzen.

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 (coming soon!) – eingehen.