Kerberos und Kerberoasting

Kerberos ist ein ticketbasiertes Authentifizierungsprotokoll. Anstatt Passwörter zu übertragen, legen Clients kryptografische Tickets vor, die vom Key Distribution Center (KDC) ausgestellt werden, das auf jedem Domain Controller ausgeführt wird.

• Der Authentication Server (AS) stellt ein Ticket Granting Ticket (TGT) aus.
• Der Ticket Granting Server (TGS) stellt Service-Tickets aus.
• Dienste validieren Tickets, ohne den DC zu kontaktieren.

Kerberos umfasst drei Nachrichtenaustausche. Wenn Sie diese verstehen, erkennen Sie, an welcher Stelle die verschiedenen Angriffe ansetzen.

• AS-REQ / AS-REP: Der Client weist seine Identität nach (Pre-Authentifizierung) und erhält ein mit dem krbtgt-Schlüssel verschlüsseltes TGT.
• TGS-REQ / TGS-REP: Der Client legt das TGT vor, um ein Service-Ticket (TGS) anzufordern.
• AP-REQ / AP-REP: Der Client legt dem Dienst das TGS vor.

AS-REP-Roasting greift den ersten Austausch an, Kerberoasting den zweiten.

Ein Service Principal Name (SPN) ordnet eine Dienstinstanz dem Konto zu, unter dem sie ausgeführt wird. Wenn Sie ein TGS für einen SPN anfordern, ist das resultierende Ticket teilweise mit dem Passwort-Hash des Dienstkontos verschlüsselt.

Das ist der Kern von Kerberoasting: Jeder authentifizierte Benutzer kann Tickets für Dienstkonten anfordern und sie anschließend offline knacken, um das Passwort im Klartext wiederherzustellen.

Kerberoasting verursacht wenig auffälligen Datenverkehr, da das Anfordern eines TGS ein normales Verhalten ist. Die Angriffsschritte sind:

• Benutzerkonten mit SPNs aufzählen.
• TGS-Tickets für diese SPNs anfordern.
• Die verschlüsselten Ticketdaten extrahieren.
• Sie offline mit einer Wortliste knacken; während des Knackens ist keine Interaktion mit dem DC erforderlich.

Das erfasste Ticket verwendet das Passwort des Dienstkontos als Schlüssel. Beim Offline-Knacken werden so lange mögliche Passwörter ausprobiert, bis eines das Ticket korrekt entschlüsselt.

Dienstkonten haben häufig schwache Passwörter, die nie geändert werden, sodass sie schnell geknackt werden können.

Die für das Ticket verwendete Verschlüsselung beeinflusst die Geschwindigkeit des Knackens.

• RC4 (etype 23) lässt sich schnell knacken und ist ein Warnsignal, wenn es noch zugelassen ist.
• AES (etype 17/18) ist deutlich langsamer per Brute-Force zu knacken.
• Angreifer können Anforderungen mit /tgtdeleg oder durch den Missbrauch von msDS-SupportedEncryptionTypes auf RC4 herabstufen.

Verteidiger sollten RC4 in der gesamten Domäne deaktivieren und AES erzwingen.

Ein verwandter Angriff zielt auf Konten, bei denen die Kerberos-Pre-Authentifizierung deaktiviert ist (DONT_REQ_PREAUTH). Ohne Pre-Authentifizierung enthält die AS-REP Daten, die mit dem Passwort-Hash des Benutzers verschlüsselt sind und ohne jegliche Zugangsdaten abgerufen werden können.

Kerberoasting ist aufgrund struktureller Schwächen erfolgreich, nicht wegen Fehlern im Protokoll.

• Jeder authentifizierte Prinzipal kann designbedingt jedes Service-Ticket anfordern.
• Dienstkonten werden häufig einmalig mit einem schwachen Passwort eingerichtet, das anschließend nie geändert wird.
• Viele laufen mit weitreichenden Rechten, etwa SQL-Dienstkonten in Domain Admins.
• Das Knacken erfolgt vollständig offline, sodass keine Kontosperrung ausgelöst wird.

Verteidiger können Roasting anhand der Telemetrie zu TGS-Anforderungen erkennen.

• Überwachen Sie Ereignis 4769 auf RC4-Ticketanforderungen (0x17), insbesondere wenn ein Konto diese in kurzen Abständen gebündelt stellt.
• Lösen Sie einen Alarm aus, wenn ein einzelner Prinzipal in kurzer Zeit viele unterschiedliche SPNs anfordert.
• Setzen Sie Honeypot-SPN-Konten ein, die von keinem legitimen Dienst verwendet werden. Jede Anforderung ist dann bösartig.

Die nachhaltige Lösung besteht darin, die Bedingungen zu beseitigen, unter denen Tickets geknackt werden können.

• Verwenden Sie Group Managed Service Accounts (gMSA) mit automatisch wechselnden Passwörtern mit mindestens 120 Zeichen.
• Erzwingen Sie lange, komplexe Passwörter für alle verbleibenden klassischen Dienstkonten.
• Deaktivieren Sie RC4 und verlangen Sie AES-Verschlüsselungstypen.
• Entfernen Sie nicht benötigte SPNs und konfigurieren Sie die Konten nach dem Prinzip der geringsten Rechte.

Führen Sie während autorisierter Tests Ticket-Knackversuche in einer isolierten Umgebung durch und exfiltrieren Sie niemals Zugangsdaten im Klartext über den Umfang des Auftrags hinaus. Berichten Sie, welche Konten geknackt wurden und wie schnell, damit der Kunde die Migration zu gMSA priorisieren kann.

Behandeln Sie geknackte Passwörter als vertraulich: Speichern Sie sie verschlüsselt und löschen Sie sie nach der Berichterstattung.

Bestätigen Sie Ihr Verständnis der Funktionsweise von Kerberoasting.

Sie haben gelernt, wie Kerberos Tickets ausstellt und wie dieser Mechanismus missbraucht wird.

• SPN-Tickets werden mit den Hashes von Dienstkonten verschlüsselt, wodurch Offline-Knacken möglich wird.
• RC4-Tickets lassen sich schnell knacken; AES und gMSA bieten Schutz.
• AS-REP-Roasting erfordert keine Zugangsdaten, wenn die Pre-Authentifizierung deaktiviert ist.
• Honeypot-SPNs und die Überwachung von 4769 auf RC4 erkennen den Angriff.

Als Nächstes behandeln wir die Wiederverwendung gestohlener Zugangsdaten mit Pass-the-Hash und Pass-the-Ticket.