Magic Quadrant™ für Privileged Access Management 2025: Netwrix zum vierten Jahr in Folge anerkannt. Laden Sie den Bericht herunter.

Plattform
Ressourcen­zentrumBlog
Extrahieren von Dienstkonten-Passwörtern mit Kerberoasting

Extrahieren von Dienstkonten-Passwörtern mit Kerberoasting

Aug 31, 2022

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:

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’
      

Image

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:

Image

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.

Image

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.

Teilen auf

Erfahren Sie mehr

Über den Autor

Ein mann in einer blauen jacke und einem karierten hemd lchelt fr die kamera

Jeff Warren

Chief Product Officer

Jeff Warren überwacht das Netwrix Produktportfolio und bringt über ein Jahrzehnt Erfahrung im sicherheitsorientierten Produktmanagement und der Entwicklung mit. Bevor er zu Netwrix kam, leitete Jeff die Produktorganisation bei Stealthbits Technologies, wo er seine Erfahrung als Software-Ingenieur nutzte, um innovative, unternehmensweite Sicherheitslösungen zu entwickeln. Mit einem praktischen Ansatz und einem Talent für die Lösung schwieriger Sicherheitsherausforderungen konzentriert sich Jeff darauf, praktikable Lösungen zu schaffen, die funktionieren. Er hat einen BS in Informationssystemen von der University of Delaware.