Kerberoasting- und Golden-Ticket-Angriffe

Um Kerberoasting- und Golden-Ticket-Angriffe zu verstehen, benötigen Sie ein klares Bild von der Ausstellung von Kerberos-Diensttickets. Wenn ein Client auf einen Dienst (z. B. einen SQL-Server) zugreifen möchte, legt er dem Ticket Granting Service (TGS) des Domänencontrollers sein Ticket Granting Ticket (TGT) vor. Der TGS stellt ein Dienstticket aus, das mit dem Passwort-Hash des Dienstkontos verschlüsselt ist. Der Client legt dieses Ticket dem Dienst vor, der es mit seinem eigenen Hash entschlüsselt, um seine Authentizität zu überprüfen. Das bedeutet, dass Diensttickets mit den Anmeldedaten des Zieldienstes verschlüsselt werden – ein entscheidendes Detail, das Kerberoasting ausnutzt.

Kerberoasting ist ein Angriff, der ausnutzt, dass jeder authentifizierte Domänenbenutzer ein Kerberos-Dienstticket für jeden Dienst anfordern kann, der mit einem SPN (Service Principal Name) registriert ist. Der Angreifer fordert Diensttickets für Konten mit SPNs an, fängt die verschlüsselten Ticket-Blobs ab und versucht anschließend, das Passwort des Dienstkontos offline zu knacken – ohne weitere Interaktion mit Active Directory und ohne das Risiko einer Kontosperrung. Dienstkonten haben häufig schwache Passwörter, alte Passwörter aus der Zeit vor modernen Komplexitätsanforderungen oder Passwörter, die nie ablaufen. Dadurch sind sie besonders anfällig für Offline-Angriffe zum Knacken von Passwörtern.

Die beim Kerberoasting abgefangenen Dienstticket-Hashes werden standardmäßig aus Kompatibilitätsgründen mit RC4-HMAC (NTLM-Hash) verschlüsselt. Sie lassen sich schneller knacken als AES-256-Kerberos-Tickets. Ein Angreifer übergibt die abgefangenen $krb5tgs$23$-Hashes an Hashcat oder John the Ripper, um Offline-Angriffe mit Wörterbüchern und Brute-Force durchzuführen. Gängige Wortlisten wie RockYou können zusammen mit Regelsätzen die meisten schwachen Passwörter von Dienstkonten auf handelsüblicher GPU-Hardware innerhalb von Minuten bis Stunden knacken. Sobald das Passwort geknackt ist, verfügt der Angreifer über das Passwort im Klartext des Dienstkontos und kann sich damit direkt authentifizieren.

Maßnahmen gegen Kerberoasting zielen auf drei Bereiche ab: Passwortstärke – Dienstkonten sollten über lange, zufällige Passwörter mit mindestens 25 Zeichen verfügen, die selbst dem Knacken durch GPU-Cluster standhalten; Group Managed Service Accounts (gMSA) – Windows verwaltet gMSA-Passwörter automatisch (zufällige Werte mit 240 Zeichen, die alle 30 Tage geändert werden), wodurch Kerberoasting praktisch nicht durchführbar ist; Verschlüsselung ausschließlich mit AES – konfigurieren Sie Dienstkonten so, dass sie AES-256-Tickets erfordern (msDS-SupportedEncryptionTypes), die sich exponentiell langsamer knacken lassen als RC4; sowie Erkennung – lösen Sie bei einer ungewöhnlich hohen Anzahl von TGS-Anforderungen (Ereignis-ID 4769) für Dienstkonten von nicht standardmäßigen Arbeitsstationen einen Alarm aus.

Das KRBTGT-Konto ist ein spezielles integriertes Active-Directory-Konto. Sein Passwort-Hash wird verwendet, um alle Kerberos-TGTs in der Domäne zu signieren und zu verschlüsseln. Der Domänencontroller verwendet den KRBTGT-Hash, um TGTs zu erstellen und eingehende TGTs zu validieren. Dadurch ist der KRBTGT-Hash das wertvollste einzelne Anmeldedatum in einer Active-Directory-Umgebung: Jeder, der ihn besitzt, kann beliebige, vollständig gültige Kerberos-Tickets für jeden Benutzer erstellen – auch für nicht vorhandene Benutzer –, mit beliebigen Gruppenmitgliedschaften und für eine beliebige Gültigkeitsdauer. Das KRBTGT-Passwort wurde in vielen Unternehmen üblicherweise nie geändert, da der Änderungsprozess eine sorgfältige Koordination erfordert.

Bei einem Golden-Ticket-Angriff wird mithilfe des Passwort-Hashes des kompromittierten KRBTGT-Kontos ein gefälschtes, vollständig gültiges Kerberos-TGT erstellt. Der Angreifer verwendet den Befehl kerberos::golden von Mimikatz, um ein TGT für einen beliebigen Benutzer (häufig ein gefälschtes Konto nach dem Muster eines Administratorkontos) mit beliebigen Gruppenmitgliedschaften (typischerweise einschließlich Domain Admins) und einer beliebigen Gültigkeitsdauer (häufig 10 Jahre) zu erzeugen. Dieses gefälschte Ticket ist für den Domänencontroller nicht von einem legitimen Ticket zu unterscheiden, da es kryptografisch gültig ist – es wurde mit dem echten KRBTGT-Hash signiert. Ein Golden Ticket ermöglicht vollständige, dauerhafte und uneingeschränkte Kontrolle über die Domäne.

Golden Tickets sind besonders gefährlich, weil sie auch dann bestehen bleiben, wenn der ursprüngliche Angriff entdeckt und bereinigt wurde. Das Ändern des Passworts des betroffenen Benutzers hat keine Wirkung – das Ticket wurde gefälscht und basiert nicht auf den tatsächlichen Anmeldedaten des Benutzers. Die einzige Abhilfemaßnahme besteht darin, das KRBTGT-Passwort zweimal zu ändern (einmal, um vorhandene Tickets ungültig zu machen, und ein weiteres Mal, weil für das fortlaufende Wechseln jederzeit zwei KRBTGT-Schlüssel vorhanden sind). Änderungen des KRBTGT-Passworts erfordern jedoch eine sorgfältige Koordination: Bei einer fehlerhaften Änderung wird die Kerberos-Authentifizierung in der gesamten Domäne unterbrochen. Viele Unternehmen scheuen diese Maßnahme, sodass Golden Tickets unbefristet gültig bleiben.

Ein Silver Ticket ähnelt einem Golden Ticket, ist aber in seinem Umfang eingeschränkter. Es verwendet den Hash des Ziel-Dienstkontos (anstelle von KRBTGT), um ein Dienstticket ausschließlich für diesen bestimmten Dienst zu fälschen. Mit dem Hash des Dienstkontos eines SQL-Servers kann ein Angreifer beispielsweise ein Dienstticket fälschen, das ihm beliebigen Zugriff auf diesen SQL-Server gewährt. Silver Tickets sind schwerer zu erkennen als Golden Tickets, da sie den Domänencontroller vollständig umgehen: Das gefälschte Ticket wird direkt vom Angreifer an den Dienst übermittelt, ohne Kontakt zum KDC. Zur Abwehr müssen Dienstkonto-Hashes geschützt und ungewöhnliche Zugriffsmuster auf sensible Dienste überwacht werden.

Angreifer erlangen den KRBTGT-Hash mithilfe des DCSync-Angriffs, der das legitime Domänenreplikationsprotokoll von Active Directory missbraucht. Der Directory Replication Service (DRS) ermöglicht es Domänencontrollern, AD-Daten einschließlich Passwort-Hashes untereinander zu synchronisieren. Ein Angreifer mit DCSync-Berechtigungen (typischerweise Domain Admin, Enterprise Admin oder ein beliebiges Konto mit Replicating Directory Changes All-Berechtigungen) kann sich als Domänencontroller ausgeben und die Hash-Replikation für jedes Konto anfordern. Der Mimikatz-Befehl lsadump::dcsync führt diesen Angriff vollständig über das Netzwerk aus – auf dem DC selbst muss kein Code ausgeführt werden.

Die Verwendung von Golden Tickets zu erkennen, ist schwierig, aber möglich, indem nach Anomalien in den Metadaten von Kerberos-Tickets gesucht wird: Tickets mit ungewöhnlich langen Gültigkeitsdauern (echte Tickets haben eine TGT-Gültigkeitsdauer von 10 Stunden, Golden Tickets werden häufig auf 10 Jahre gesetzt); Ereignis-ID 4769, bei der der Verschlüsselungstyp des Tickets RC4 (0x17) ist, obwohl AES-256 (0x12) der Standard der Domäne ist; Kontonamen in Tickets, die in AD nicht vorhanden sind; sowie eine fehlende Ereignis-ID 4768 (TGT-Anforderung) vor Ereignis-ID 4769 (Anforderung eines Diensttickets). Golden Tickets überspringen die TGT-Anforderungsphase, da das TGT selbst gefälscht ist. Eine Regel in Microsoft Sentinel oder Defender for Identity kann diese Muster automatisch markieren.

Eine mehrschichtige Abwehr gegen Kerberos-Angriffe umfasst Folgendes: Verwenden Sie gMSA für alle Dienstkonten, um Kerberoasting praktisch unmöglich zu machen; aktivieren Sie die Verschlüsselung ausschließlich mit AES für alle Konten, insbesondere für hochwertige Dienstkonten, um den Aufwand zum Knacken zu maximieren; beschränken Sie DCSync-Berechtigungen – prüfen Sie Konten mit Replikationsberechtigungen und entfernen Sie alle nicht erforderlichen Berechtigungen; aktivieren Sie Microsoft Defender for Identity (früher ATA), das eine Kerberos-bewusste Bedrohungserkennung einschließlich Echtzeitwarnungen zu Golden Tickets, Kerberoasting und DCSync bietet; und implementieren Sie ein Modell der gestaffelten Administration, damit ein kompromittiertes Tier-2-Konto nicht dazu verwendet werden kann, Anmeldedaten auf DC-Ebene zu erreichen.

In dieser Lektion haben Sie Folgendes gelernt: Kerberoasting fordert Diensttickets für SPN-registrierte Konten an und knackt sie offline – dagegen helfen gMSA, starke Passwörter und die Verschlüsselung ausschließlich mit AES; Golden-Ticket-Angriffe verwenden den KRBTGT-Hash, um uneingeschränkte TGTs zu fälschen, die eine dauerhafte Kontrolle über die Domäne ermöglichen und so lange bestehen bleiben, bis das KRBTGT-Passwort zweimal zurückgesetzt wurde; außerdem replizieren DCSync-Angriffe den KRBTGT-Hash über das Netzwerk, ohne Code auf dem DC auszuführen – daher ist eine strenge Prüfung der DCSync-Berechtigungen erforderlich. Als Nächstes untersuchen wir das MITRE-ATT&CK-Framework zur Zuordnung von Angreifertechniken zu Abwehrmaßnahmen.