Extrahieren von Dienstkonto-Passwörtern mit Kerberoasting

In unserem LDAP reconnaissance post haben wir untersucht, wie ein Angreifer Reconnaissance durchführen kann, um Dienstkonten in einer Windows Active Directory (AD)-Domäne zu identifizieren, die angegriffen werden sollen. Jetzt wollen wir eine Methode betrachten, die ein Angreifer nutzen kann, um diese Konten zu kompromittieren und ihre Privilegien auszunutzen: Kerberoasting. Diese Technik ist besonders beängstigend, da sie keine Administratorrechte in der Domäne erfordert, sehr einfach durchzuführen ist und praktisch nicht nachweisbar ist.

Kerberoasting: Übersicht

Kerberoasting ist ein Angriff, der eine Funktion des Kerberos-Protokolls ausnutzt, um Passwort-Hashes für Active Directory-Benutzerkonten zu sammeln: Jeder authentifizierte Domänenbenutzer kann Servicetickets für ein Konto anfordern, indem er dessen Service Principal Name (SPN) angibt, und der Ticket Granting Service (TGS) auf dem Domain Controller wird ein Ticket zurückgeben, das mit dem NTLM-Hash des Passworts des Kontos verschlüsselt ist.

Daher kann ein Angreifer, sobald er Dienstkonten-SPNs mit einer Taktik wie LDAP reconnaissance entdeckt hat, Tickets für all diese Konten sammeln. Indem sie diese Daten offline nehmen, können sie einen Brute-Force-Angriff durchführen, um das Klartextpasswort jedes Dienstkontos zu knacken – ohne Risiko der Entdeckung oder Kontosperrung.

Es dauert nur wenige Minuten für einen Angreifer, um Zugang zu einem Domain zu erhalten, Tickets zu sammeln und den Knackprozess zu beginnen. Von dort aus ist es nur eine Frage der Zeit, bis sie ein oder mehrere Dienstkonten kompromittiert haben, die sie nutzen können, um sensible Daten zu stehlen oder zu verschlüsseln oder anderen Schaden anzurichten.

Angreifer konzentrieren sich aus mehreren Gründen auf Dienstkonten. Erstens haben diese Konten oft weitreichendere Privilegien als andere AD-Benutzerkonten, sodass deren Kompromittierung dem Angreifer mehr Zugriff gewährt. Zusätzlich ändern sich die Passwörter von Dienstkonten selten, sodass der Gegner wahrscheinlich lange Zeit Zugang behält. Um die Arten von Zugriff zu verstehen, die durch Kerberoasting erlangt werden können, schauen Sie sich die Liste der Active Directory SPNs an, die von Sean Metcalf gepflegt wird.

Kerberoasting: Wie es funktioniert

Schritt 1. Beschaffen Sie die SPNs der Dienstkonten.

Es gibt viele Möglichkeiten, diese SPNs zu erhalten, einschließlich:

• PowerShell-Abfragen und LDAP-Reconnaissance
• Active Directory-Modul für PowerShell
• GetUserSPNs-Skript im Kerberoast-Toolkit
• Get-NetUser-Befehl von PowerSploit

Schritt 2. Fordern Sie Servicetickets für Service-Account-SPNs an.

Führen Sie einfach ein paar Zeilen PowerShell aus, und ein Service-Ticket wird zurückgegeben und im Speicher Ihres Systems gespeichert.

      Add-Type –AssemblyName System.IdentityModel
New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken –ArgumentList ‘MSSQLSvc/jefflab-sql02.jefflab.local:1433’
      

Schritt 3. Extrahieren Sie Service-Tickets mit Mimikatz.

Mimikatz wird lokale Tickets extrahieren und sie auf der Festplatte speichern, um sie offline zu knacken. Installieren Sie einfach Mimikatz und geben Sie einen einzigen Befehl ein:

Schritt 4. Die Tickets knacken.

Kerberos-Tickets werden mit dem Passwort des Dienstkontos verschlüsselt, das mit dem im Ticketantrag angegebenen SPN verknüpft ist. Die Kerberoasting Tools bieten ein Python-Skript, um Tickets zu knacken und ihre Klartext-Passwörter bereitzustellen, indem ein Wörterbuch von Passwort-Hashes dagegen ausgeführt wird. Es kann einige Konfiguration erfordern, um sicherzustellen, dass Sie die erforderliche Umgebung haben, um das Skript auszuführen, aber dieser Blog behandelt diese Details.

Alternativ können Sie Kerberos-Tickets mit dem GetUserSPNs-Skript sammeln und sie mit dem Hashcat-Passwortwiederherstellungstool knacken.

Schutz vor Kerberoasting-Angriffen

Die primäre Milderung für Kerberoasting-Angriffe besteht darin, sicherzustellen, dass alle Dienstkonten lange, komplexe Passwörter verwenden, die schwerer zu knacken sind, und diese regelmäßig zu ändern, um die Zeit zu minimieren, in der das Konto von einem Angreifer verwendet werden könnte, der es schafft, ein Passwort zu knacken. Die Verwendung von gruppenverwaltete dienstkonten ist eine bewährte Methode, um zufällige, komplexe Passwörter zuzuweisen, die automatisch geändert werden können.

Da Angreifer die Tickets offline knacken, führt der Prozess zu keinem Netzwerkverkehr, was diesen Teil des Angriffs nicht nachweisbar macht. Aber Sie können die früheren Schritte erkennen, indem Sie Active Directory mit einer soliden Sicherheitslösung überwachen. Insbesondere werden Dienstkonten normalerweise von denselben Systemen auf dieselbe Weise verwendet, also achten Sie auf anomale Authentifizierungsanfragen. Überwachen Sie außerdem Spitzen bei den Anfragen von Diensttickets.

Schließlich empfehlen Sicherheitsspezialisten auch, die auf RC4 basierende Verschlüsselung zu deaktivieren. Andernfalls kann ein Angreifer, selbst wenn ein Benutzerkonto AES-Verschlüsselung unterstützt, ein RC4-verschlüsseltes Ticket anfordern, das einfacher zu knacken ist als eines, das mit AES-Verschlüsselung erstellt wurde.

Kerberoasting ermöglicht es einem Angreifer mit einem beliebigen Standard-Domänenkonto, verschlüsselte Tickets für Dienstkonten anzufordern und deren Passwörter offline zu knacken, wo keine Sperr-Richtlinie gilt und der Domänencontroller nicht beteiligt ist.

Was ist Kerberoasting?

Es schlägt bei schwach geschützten Konten zu, und 76 % der Organisationen verwalten oder überwachen nicht vollständig nicht-menschliche Identitäten, einschließlich Dienstkonten, laut dem Netwrix 2026 Data and Identity Security Report.

Der Angriff beginnt mit einer Liste dieser Konten, die ein Angreifer durch LDAP reconnaissance.

Kerberoasting ist ein Active Directory (AD)-Angriff, der eine normale Kerberos-Funktion in eine Gelegenheit zum Knacken von Passwörtern verwandelt. Kerberos erlaubt jedem authentifizierten Benutzer, ein Dienstticket von einem Domänencontroller anzufordern, und das Ticket wird mit einem Schlüssel verschlüsselt, der vom Passwort des Dienstkontos abgeleitet ist.

Wie Angreifer Servicekonto-Passwörter mit Kerberoasting extrahieren

Die Extraktion erfolgt in vier Schritten, wobei Rubeus und Impackets GetUserSPNs.py die ersten drei zu einem Befehl zusammenfassen, während Hashcat den vierten übernimmt.

1. Finden Sie die Konten, die SPNs haben

2. Fordern Sie Service-Tickets für die SPNs an

Ein Angreifer, der diese Tickets sammelt, kann offline Passwörter dagegen erraten, bis eines entschlüsselt wird. Die Ziele sind Benutzerkonten mit service principal names (SPNs), einschließlich der meisten service accounts. Der Angriff benötigt keine erhöhten Rechte zum Start.

Ein Angreifer mit jedem Domänenkonto kann Konten mit SPNs über eine LDAP-Abfrage, eine PowerShell-Abfrage oder das Active Directory-Modul für PowerShell auflisten. Rubeus und GetUserSPNs.py listen auch eigenständig kerberoastbare Konten auf, und Rubeus kann Statistiken darüber melden, ohne Ticketanfragen zu senden.

Ein SPN benennt eine Dienstinstanz in drei Teilen, wie bei MSSQLSvc/jefflab-sql02.jefflab.local:1433Expand, was die Dienstklasse, den Host und den Port angibt. Die Dienstklasse gibt Hinweise darauf, was ein kompromittiertes Konto erreichen kann, wie z. B. Datenbankzugriff für MSSQLSvc.

Zwei PowerShell-Zeilen fordern ein Ticket für einen benannten SPN an, und Windows speichert es im Speicher.

Rubeus automatisiert die Anforderung für jedes kerberoastbare Konto und kann die Ergebnisse in eine Datei schreiben.

Kerberos bestätigt die Identität und überlässt die Autorisierung dem Dienst (RFC 4120), sodass der Domänencontroller nicht prüft, ob der Anforderer den Dienst vor der Ausstellung eines Tickets nutzen darf. Jeder authentifizierte Benutzer erhält daher ein Ticket, das mit einem Schlüssel verschlüsselt ist, der vom Passwort des Dienstkontos abgeleitet wurde.

3. Die Service-Tickets extrahieren

Impacket's GetUserSPNs.py macht dasselbe mit der Option -request, die Tickets in einem Format ausgibt, das John the Ripper und Hashcat akzeptieren.

Wenn ein Konto mit deaktivierter Kerberos-Vorauthentifizierung existiert, fordert die /nopreauth-Option von Rubeus Diensttickets an, indem AS-REQ (Authentication Service Request)-Nachrichten darüber gesendet werden.

4. Knacken Sie die Tickets

Ein mit den obigen PowerShell-Zeilen angeforderter Ticket verbleibt im Speicher, bis der Angreifer es exportiert. Mimikatz listet die Tickets in der aktuellen Sitzung auf und schreibt sie mit einem einzigen Befehl in Dateien für das Offline-Knacken.

Rubeus und GetUserSPNs.py mit -request überspringen diesen Schritt, da sie direkt crackbare Hashes ausgeben.

Warum der Typ der Ticketverschlüsselung wichtig ist

Das Cracking läuft auf der Hardware des Angreifers, daher gilt keine Sperrpolitik, und der Domänencontroller sieht nach der Ticketanfrage nichts. Hashcat testet Passwortvermutungen gegen jedes Ticket und stellt das Klartextpasswort wieder her, wenn eine Vermutung es entschlüsselt. Es akzeptiert das Format, das GetUserSPNs.py ausgibt, und hat für jeden Verschlüsselungstyp einen eigenen Modus.

Netwrix Threat Prevention blockiert DCSync-, Kerberoasting- und Pass-the-Hash-Angriffe auf Active Directory in Echtzeit. Fordern Sie eine Demo an.

RC4-Tickets werden am schnellsten geknackt

Der Verschlüsselungstyp eines Tickets, RC4 (Rivest Cipher 4) oder AES (Advanced Encryption Standard), bestimmt, wie schnell ein Angreifer es erraten kann, und Microsoft hat die Standardwerte 2026 geändert.

Angreifer können RC4 für Konten anfordern, die AES unterstützen

AES-Tickets verlangsamen das Erraten, fallen aber trotzdem bei schwachen Passwörtern

Der Schlüssel eines RC4-Tickets ist der NT LAN Manager (NTLM)-Hash des Kontos, ein ungesalzener Hash des Passworts (RFC 4757). Ohne Salt erzeugt dasselbe Passwort für jedes Konto denselben Schlüssel, und jeder Versuch kostet eine Hash-Berechnung.

Rubeus fordert standardmäßig den höchsten unterstützten Verschlüsselungstyp für jedes Konto an, aber die Option /usetgtdeleg fordert RC4-Tickets für Konten, die AES unterstützen, und die Option /rc4opsec überspringt AES-aktivierte Konten.

GetUserSPNs.py von Impacket fordert standardmäßig ebenfalls RC4 an, sofern nicht -no-rc4 gesetzt ist. Das Entfernen von RC4 aus den unterstützten Verschlüsselungstypen des Dienstkontos schließt diesen Downgrade-Pfad.

Alle drei Typen sind knackbar, daher entscheiden Passwortlänge und Zufälligkeit über das Ergebnis.

Das Update vom April 2026 hat den Standard-Domänencontroller geändert

Schutz von Dienstkonten vor Kerberoasting

AES-Schlüssel stammen aus einer gesalzenen Schlüsselableitung, die standardmäßig 4.096 Iterationen durchführt (RFC 3962), was jeden Versuch teurer macht. Die /aes-Option von Rubeus zielt auf AES-aktivierte Konten und fordert deren AES-Tickets an, und Hashcat hat einen separaten Modus für jeden Ticket-Verschlüsselungstyp.

Die Änderung betrifft keine Konten, die RC4 über dieses Attribut ausdrücklich erlauben, und ein explizit gesetzter Domänenstandard wird wie geschrieben beibehalten. Diese Konten können weiterhin RC4-Tickets erhalten, daher sind sie zuerst zu finden.

Das Microsoft-Update KB5073381 begann im Januar 2026 mit Audit-Ereignissen. Am 14. April 2026 wurde die Standard-Einstellung des Domänencontrollers geändert, sodass Konten ohne expliziten msDS-SupportedEncryptionTypes-Wert nur AES-SHA1 unterstützen, und Updates, die ab Juli 2026 veröffentlicht wurden, unterstützen nicht mehr den Registrierungswert, mit dem Administratoren die Änderung rückgängig machen konnten.

Jede Kontrolle begrenzt einen anderen Teil des Angriffs, und alle verwenden native Active Directory- und Windows-Funktionen.

Dienstkonten auf verwaltete Konten verschieben

Setzen Sie lange zufällige Passwörter für den Rest

Passwörter zurücksetzen und AES durchsetzen

Netwrix-Forschung zum BadSuccessor-Angriff, der dMSAs für Privilegienerweiterung missbraucht, empfiehlt, vor der Bereitstellung zu prüfen, wer die Rechte CreateChild, WriteProperty, WriteDACL, GenericAll und WriteOwner für Organisationseinheiten besitzt.

Gruppenverwaltete Dienstkonten (gMSAs) verwenden 120-stellige Zufallspasswörter, die Active Directory rotiert, sodass Angreifer nichts Schwaches zum Erraten haben. Delegierte verwaltete Dienstkonten (dMSAs) werden ebenfalls von Active Directory verwaltet.

Für Konten, die nicht verschoben werden können, MITRE ATT&CK empfiehlt idealerweise Passwörter mit 25 oder mehr Zeichen. Die zufällige Generierung ist genauso wichtig wie die Länge, da Cracking-Wordlists aus Passwörtern erstellt werden, die Menschen wählen.

AES-Schlüssel werden generiert, wenn ein Passwort gesetzt oder geändert wird. Ein Konto, dessen Passwort vor der AES-Unterstützung erstellt wurde, hat keine Schlüssel, bis es zurückgesetzt wird, und ein reines AES-Konto ohne Schlüssel kann keine Tickets erhalten.

Entfernen Sie SPNs, die Konten nicht benötigen

Testen Sie jeden Dienst, bevor Sie ihn einschränken, da Dienste, die AES nicht unterstützen, einschließlich einiger Nicht-Windows-Geräte, die Authentifizierung einstellen, sobald RC4 entfernt wird.

Setzen Sie zuerst das Passwort zurück, prüfen Sie dann das Attribut msDS-SupportedEncryptionTypes des Kontos auf explizite RC4-Einstellungen und beschränken Sie es auf AES128 und AES256 (Wert 24).

Jeder SPN auf einem Benutzerkonto macht dieses Konto anforderbar, also listen Sie alle auf und vergleichen Sie jeden mit einem laufenden Dienst.

Steuern Sie, wer SPNs hinzufügen kann

Dienstkonto-Berechtigungen einschränken

Service-Ticket-Anfragen protokollieren

Das Konto krbtgt erscheint absichtlich in den Ergebnissen und sollte nicht geändert werden. Für jeden anderen SPN, der auf einen stillgelegten Host oder eine außer Betrieb genommene Anwendung verweist, prüfen Sie ihn mit setspn -L <account>Expand und löschen Sie ihn mit setspn -D <SPN> <account>Expand.

Beim targeted Kerberoasting fügt ein Angreifer mit GenericAll-, GenericWrite-, WriteProperty- oder Validated Write-Rechten für Service Principal Name einem Konto einen SPN hinzu, wodurch das Konto angreifbar wird. Überprüfen Sie die Zugriffskontrolllisten bei Dienstkonten und entfernen Sie diese Rechte von Personen, die das Konto nicht verwalten. Mitglieder der integrierten Gruppe Account Operators besitzen diese Rechte meist.

Aktivieren Sie die Unterkategorie Audit Kerberos Service Ticket Operations auf Domänencontrollern, die jede Anfrage als Ereignis-ID 4769 protokolliert. MITRE empfiehlt, auf anomale Anfragen mit RC4 zu achten, angezeigt als Ticket Encryption Type 0x17, während AES-Tickets 0x11 oder 0x12 zeigen.

Roasting über ein Konto ohne Vor-Authentifizierung sendet stattdessen AS-REQ-Nachrichten, sodass diese Anfragen als Ereignis-ID 4768 protokolliert werden und dieselbe RC4-Prüfung auf sie angewendet wird.

Ein geknacktes Passwort gibt einem Angreifer alle Rechte, die das Konto hat. Entfernen Sie Dienstkonten aus privilegierten Gruppen wie Domain Admins und gewähren Sie nur die Rechte, die der Dienst benötigt, nach dem Prinzip der geringsten Rechte. Diese Arbeit gehört zur umfassenderen Sicherheitsverstärkung von Active Directory.

Das Kerberos-Crypto-Repository von Microsoft enthält ein Get-KerbEncryptionUsage.ps1-Skript, das beide Ereignistypen liest. Wird es mit -Encryption RC4 und -SearchScope AllKdcs ausgeführt, listet es RC4-Anfragen auf allen Domänencontrollern auf.

Wie Netwrix beim Schutz gegen Kerberoasting hilft

Blockieren Sie Kerberoasting-Versuche in Echtzeit

Netwrix-Produkte fügen drei Kontrollen über die nativen Windows-Einstellungen hinaus hinzu: Angriff blockieren, Folgendes erkennen und Active Directory auf ausgenutzte Schwachstellen prüfen.

Identitätsbasierte Angriffe erkennen

Netwrix Threat Prevention stoppt Kerberoasting-, DCSync- und Pass-the-Hash-Versuche gegen Active Directory, bevor sie erfolgreich sind. Das gibt Teams einen Durchsetzungspunkt zum Zeitpunkt des Angriffs, den eine Protokollüberprüfung nicht bieten kann.

Active Directory-Sicherheitslage bewerten

Beginnen Sie mit den Konten, die noch RC4 erlauben

Netwrix Threat Manager erkennt Diebstahl von Anmeldeinformationen, laterale Bewegungen und Privilegienerweiterungen, die Identitäts-basierte Angriffe sind und auf ein geknacktes Dienstkonto-Passwort folgen können. Es erkennt auch, wenn einem privilegierten Konto ein SPN hinzugefügt wird, den Einrichtungsschritt des gezielten Kerberoastings.

Kerberoasting benötigt nur ein schwaches Dienstkonto-Passwort, daher funktioniert die Verteidigung am besten als sequenzielle Anwendung Konto für Konto.

Netwrix PingCastle bewertet die Sicherheit von Active Directory und erkennt Fehlkonfigurationen, Angriffswege und Privilegienexposition.

Konten, die nicht in verwaltete Konten umgewandelt werden können, benötigen lange, zufällige Passwörter, um Offline-Raten zu überdauern. Die Ticketanfrage ist der einzige Schritt, den Verteidiger noch beobachten können, daher deckt das Protokollieren ab, was Passwort-Hygiene nicht kann.

Nach der Standardänderung von Microsoft im April 2026 können Konten, die RC4 explizit erlauben, entweder auf Kontoebene oder durch eine explizit gesetzte Domänen-Standardvorgabe, weiterhin RC4-Tickets erhalten und haben somit Vorrang. Verschieben Sie, was verschoben werden kann, auf verwaltete Konten, setzen Sie dann den Rest zurück und beschränken Sie diese auf AES.

Fordern Sie eine Demo an und sehen Sie, wie Netwrix Threat Prevention Kerberoasting-Versuche gegen Ihre Active Directory-Dienstkonten stoppt, bevor sie erfolgreich sind.