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.
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/), 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. 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
Das komplette Repo findest du hier: https://github.com/VidraSec/dellicious/
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/
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 im pypykatz Repository aufgemacht. Vielen Dank an SkelSec 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
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.