Hashes auslesen in Windows 11 24H2
(Aktualisiert: )
This page is also available in English.
In diesem Blogpost beschreibe ich, wie ich es in Windows 11 24H2 geschafft habe, Passwort-Hashes aus dem lsass.exe Prozessspeicher auszulesen. Da diese Version beim Schreiben dieses Posts noch sehr neu war, sind manche der Probleme auch der fehlenden Tool-Unterstützung geschuldet und sollten in Zukunft behoben sein. Dieser Post kann aber auch helfen, die Tools für spätere Windows-Versionen anzupassen.
Table of Contents
Ich war gerade dabei, eine Hacking-Demo vorzubereiten. Ich wollte ein paar Standarddinge, die man in einem Pentest macht, herzeigen. Eines davon war, den lsass.exe Prozessspeicher auszulesen, also Passwort-Hashes zu dumpen. Das habe ich bestimmt schon 100-mal gemacht. Aber diesmal wollte es einfach nicht funktionieren. Ich habe einige Abende damit verbracht, die Probleme zu isolieren, zu debuggen und zu beheben. Dieser Blogpost beschreibt mein Vorgehen.
Die Quelle aller Probleme ist Windows 11 24H2. Beim Schreiben dieses Posts ist die Version noch relativ neu und daher noch nicht wirklich von Tools unterstützt.
Außerdem gibt es noch ein paar Sicherheitsmaßnahmen, die in Windows 11 standardmäßig aktiv sind:
- LSA Protection (PPL Protection)
- Vulnerable Driver Blocklist (die war interessanterweise kein Problem, das könnte aber auch am deaktivierten Windows Defender liegen)
- Credential Guard (in Klammern, weil dieser in meiner VM wegen der fehlenden Hardwareunterstützung nicht aktiv war)
Insgesamt bedeutet das, dass wir die LSA Protection umgehen müssen. Die Vulnerable Driver Blocklist sollte das in der Theorie schwieriger machen.
Credentials aus lsass.exe auszulesen, nachdem man auf einer Workstation oder einem Server gelandet ist, gehört zu den Standardschritten in einem Internen IT-Infrastruktur-Penetrationstest, meist ist es genau dieser Schritt, der aus „einem falschen Klick“ laterale Bewegung durch die gesamte Domain macht.
Umgehung der LSA Protection
Die LSA Protection setzt vereinfacht gesagt einfach ein Flag auf den lsass.exe Prozess, das verhindert, dass auf den Prozessspeicher zugegriffen werden kann, selbst mit Local System Rechten. Die klassische Umgehungsmöglichkeit dafür ist, einen verwundbaren Kernel-Treiber zu laden, der das darf. Der muss verwundbar sein, weil ich nur dadurch meinen eigenen Code in seinem Kontext ausführen kann. Da Kernel-Treiber signiert sein müssen, kann ich nicht einfach meinen eigenen Treiber schreiben.
Hier gibt es grundsätzlich einige Möglichkeiten (siehe auch https://www.loldrivers.io/ (öffnet in neuem Tab)), aber die Vulnerable Driver Blocklist macht es uns zusätzlich schwerer. Die blockt nämlich bekannte verwundbare Treiber.
Es gibt bereits einige fertige Tools, die diesen Angriff durchführen, wie z. B. dellicious (öffnet in neuem Tab). Das ist kein Tippfehler, das Tool heißt so, weil ein verwundbarer Dell-Treiber ausgenutzt wird.
Jetzt haben wir aber ein Problem. Das Tool unterstützt kein Windows 11 24H2. Das ist zum Glück relativ leicht zu beheben, wir müssen nur die Kernel-Offsets für unsere Windows-Version herausfinden und im Code anpassen.
Das geht mit WinDBG. Dazu File > Attach to Kernel > Local öffnen. Dann mit folgenden Kommandos die Symbole laden:
.symfix
.reload
Und dann die EPROCESS Struktur anzeigen:
dt nt!_EPROCESS
Aus dem Output sucht man die Werte für UniqueProcessId, ActiveProcessLinks und SignatureLevel heraus:
+0x1d0 UniqueProcessId : Ptr64 Void
+0x1d8 ActiveProcessLinks : _LIST_ENTRY
+0x5f8 SignatureLevel : UChar
Diese fügt man nun in dellicious ein. Das habe ich in diesem Commit gemacht: https://github.com/VidraSec/dellicious/commit/56c82bb7a2901baafeb8056deb6f13d8ad24da91 (öffnet in neuem Tab)
Das komplette Repo findest du hier: https://github.com/VidraSec/dellicious/ (öffnet in neuem Tab)
Was jetzt noch fehlt, sind die verwundbaren Dell-Treiber. Die findet man nach ein bisschen Internetrecherche. Wichtig: Die Hashes sollte man vorher überprüfen.
PS> .\dellicious.exe -p 856 -e 0 -d .\driver\
[+] User provided pid: 856
[+] User provided driver directory: .\driver\
[+] Windows version found: 26100
[+] Using offsets:
UniqueProcessIdOffset = 0x1d0
ActiveProcessLinkOffset = 0x1d8
SignatureLevelOffset = 0x5f8
[+] Attempting driver install...
[+] Driver installed!
[+] Device handle has been obtained @ \\.\DBUtil_2_5
[+] Ntoskrnl base address: fffff805b9c00000
[+] PsInitialSystemProcess address: ffffc102b46a0040
[+] Target process address: ffffc102bbf61080
[+] Current SignatureLevel, SectionSignatureLevel, Type, Audit, and Signer bits (plus 5 bytes): 40c00000000000
[+] Writing flags back as: 40c00000000000
[+] Done!
[+] Removing device
[!] Clean exit! o7
Super, jetzt haben wir den lsass.exe Prozess ohne PPL. Das heißt, wir können z. B. mit dem Task-Manager einen Dump erstellen.
Auslesen der Hashes
Jetzt haben wir aber ein weiteres Problem. Weder Mimikatz noch pypykatz können die Datei parsen. Das liegt daran, wie das Parsing funktioniert.
- Das Programm sucht nach einer speziellen Bytefolge, der „Signatur“.
- Ausgehend von dieser Speicherposition findet das Programm die Pointer zu
LogonSessionListundLogonSessionListCount. - Dadurch weiß das Programm, wo in der Datei sich die Logon-Daten befinden.
Warum ich das alles weiß? Wegen dieses exzellenten Blogposts: https://www.praetorian.com/blog/inside-mimikatz-part2/ (öffnet in neuem Tab)
Diese Werte sind alle hardcoded und haben sich in Windows 11 24H2 verändert. Außerdem hat sich die Logik geringfügig geändert. Um die neuen Werte herauszufinden muss man die lsasrv.dll disassemblen (z. B. mit Ghidra).
Das muss daher alles für Windows 11 24H2 angepasst werden. Da ich in diesem Thema nicht tief genug drin bin, habe ich Hilfe gebraucht und ein Issue (öffnet in neuem Tab) im pypykatz Repository aufgemacht. Vielen Dank an SkelSec (öffnet in neuem Tab) für die schnelle Implementierung der neuen Logik.
Mit der aktuellen pypykatz Version können wir nun aus unserem Dump-File die Credentials herausziehen.
pypykatz lsa minidump ./dump.DMP
== LogonSession ==
authentication_id 278102 (43e56)
session_id 1
username highpriv
domainname WIN11
logon_server WIN11
logon_time 2025-02-27T11:44:50.975151+00:00
sid S-1-5-21-800810350-130866625-3627431900-1001
luid 278102
== MSV ==
Username: highpriv
Domain: WIN11
LM: NA
NT: 83ae0f1e4d3eebb222aee30e865b3336
SHA1: bd2f0e14880fa891001a05b5cff2fe5568bd3f7b
DPAPI: bd2f0e14880fa891001a05b5cff2fe5568bd3f7b
Credential Guard
Der war in meinem Fall nicht aktiv. Wäre er allerdings aktiv gewesen, hätte man statt der NT-Hashes nur einen verschlüsselten Blob erhalten. Um den Credential Guard zu umgehen, braucht es noch einen weiteren Schritt. Dazu kann ich diesen Blogpost empfehlen: https://research.ifcr.dk/pass-the-challenge-defeating-windows-defender-credential-guard-31a892eee22 (öffnet in neuem Tab)
Zusammenfassung
Es wäre jetzt einfach zu sagen, dass diese ganzen Sicherheitsfeatures nichts bringen, weil man sie umgehen kann. Das ist meiner Meinung nach aber zu kurz gegriffen.
Ohne diese zusätzlichen Maßnahmen ist es extrem einfach, Hashes auszulesen. Nun habe ich mehrere Stunden und viel Detailwissen gebraucht.
Daher: Ja, die Sicherheitsfeatures sollten alle aktiviert werden. Aber ein System ist nie 100 % sicher. Ich kann es den Angreifern nur so schwer wie möglich machen.
Willst du wissen, ob ein Angreifer das auch bei euch schaffen würde, und was er von dort aus noch erreichen könnte? Genau das prüft ein Interner IT-Infrastruktur-Penetrationstest. Techniken wie diese kommen auch in einer Simulation von Cyberangriffen zum Einsatz, um zu prüfen, ob euer Team einen solchen Angriff erkennt. BitLocker ist ein weiterer Windows-Client-Schutz, den es sich zu prüfen lohnt, siehe BitLocker umgehen ohne Schraubenzieher: bitpixie.
Fragen zu Windows-Client-Sicherheit, Credential-Angriffen oder Pentests? Kontaktiert VidraSec.
Ihr überlegt, euch für solche Tests externe Unterstützung zu holen? Die Checkliste zur Wahl eines Pentest-Anbieters zeigt, worauf ihr achten solltet.
Zugehörige Dienstleistungen
Zugehörige Blog Posts
- BitLocker umgehen ohne Schraubenzieher: bitpixie und was du dagegen tun kannst
- Kerberos: Wie funktioniert das Authentifizierungsprotokoll
- UAC Bypass
- BitLocker absichern: Initiales Setup und Absicherung gegen Angriffe
Termin auswählen (öffnet in neuem Tab) | martin@vidrasec.com | +43 670 3081275 | +43 670 3081275 (öffnet in neuem Tab) |