andreisss/ksldumpKslDump — Warum ein eigenes Messer mitbringen, wenn Defender bereits eines in der Küche hinterlassen hat?
Ich habe das Problem am 7. März 2026 an Microsoft gemeldet. Allerdings hatte die Game-Hacking-Community fast 20 Tage zuvor bereits Reverse Engineering betrieben und es öffentlich diskutiert. Von meiner Seite aus verfolge ich deren Projekte nicht und war mir dessen nicht bewusst. Es ist auch klar, dass es sich um zwei völlig separate und unabhängige Projekte handelt.
Warum ein eigenes Messer mitbringen, wenn Defender bereits eines in der Küche liegen gelassen hat?
KslDump extrahiert Anmeldeinformationen aus dem PPL-geschützten LSASS unter ausschließlicher Verwendung von Microsoft-signierten Komponenten. Es wird kein Exploit eingesetzt. Es wird kein Treiber geladen. Die gesamte Angriffskette ist mit Windows Defender vorinstalliert. Microsoft hat die laufende Version (wd\KslD.sys) gepatcht, indem MmCopyMemory auf null gesetzt wurde, aber die alte anfällige Version (drivers\KslD.sys) auf der Festplatte belassen. Der Angreifer bringt nichts mit – er zeigt den Dienst nur auf das zurück, was Microsoft zu bereinigen vergessen hat.
https://github.com/user-attachments/assets/78dfce25-56b3-4eb8-9de2-7c183601e597
KslD.sys ist ein Kernel-Treiber, der mit Microsoft Defender ausgeliefert wird. Er ist Microsoft-signiert, als vertrauenswürdiges Kernelmodul geladen und stellt ein Geräteobjekt \\.\KslD bereit, das aus dem Benutzermodus zugänglich ist.
Der Treiber akzeptiert IOCTL 0x222044 mit mehreren Unterbefehlen, die uneingeschränkten Kernel- und physischen Speicherzugriff für jeden Prozess bieten, der das Gerätehandle öffnen kann.
| SubCmd | Fähigkeit | Auswirkung |
|---|---|---|
| 2 | Gibt CR3, IDTR und andere CPU-Steuerregister an den Benutzermodus zurück | Sofortige KASLR-Umgehung |
| 12 | Ruft MmCopyMemory() mit vom Angreifer kontrollierten Adress- und Größenparametern auf | Beliebiges Lesen von Kernel-/physischem Speicher |
Das einzige Tor zum Gerätehandle ist eine Prozessnamenszeichenfolge, die in einem Registrierungsschlüssel (AllowedProcessName) unter dem Dienstschlüssel des Treibers gespeichert ist. Dieser Wert ist:
Der Unterschied liegt in einer Zeile in CCommand::Initialize:
// 82 KB version (patched) — deliberately clears the pointer:
v3 = MmGetSystemRoutineAddress(L"MmCopyMemory");
if (v3 >= 0) {
*(a1 + 24) = 0; // ← NULLs it — SubCmd 12 is dead
}
// 333 KB version (vulnerable) — stores the pointer:
ptr = MmGetSystemRoutineAddress(L"MmCopyMemory");
if (ptr) {
*(this + 0x18) = ptr; // ← Keeps it — SubCmd 12 works
}
Defender-Plattformupdates scheinen die gepatchte 82-KB-Version in drivers\wd\ abzulegen und ImagePath darauf zu setzen, während die ältere 333-KB-Version in drivers\ verbleibt. Auf getesteten Systemen wurde die alte Binärdatei nie entfernt. Der Exploit schaltet einfach ImagePath zurück auf die anfällige Version und startet den Dienst neu. Beide Binärdateien sind Microsoft-signiert und werden vom Betriebssystem als vertrauenswürdig eingestuft.
Die öffentliche Dokumentation von Microsoft zeigt, dass KB4052623 Defender-Plattformupdates liefert, einschließlich einer historischen Verschiebung von Defender-Treibern nach System32\drivers\wd, während Windows-Wartung WinSxS-gestützte Komponentenspeicherdateien über NTFS-Hardlinks behält und überholte Komponentenversionen nur während der Bereinigung entfernt. Auf dem getesteten System erklärt dies, warum die neuere 82-KB-Version von KslD.sys über den Defender-Plattformupdate-Pfad eintreffen konnte, während die ältere 333-KB-Version von System32\drivers\KslD.sys als aktuelle CBS-gestützte Kopie im Komponentenspeicher verblieb, bis sie durch eine neuere CBS-Version ersetzt wurde.
Microsoft unterhält eine Blockliste für anfällige Treiber (DriverSiPolicy.p7b), um speziell BYOVD-Angriffe zu verhindern. Diese Blockliste wird über HVCI erzwungen und blockiert das Laden bekannter anfälliger signierter Treiber.
Aus der eigenen Dokumentation von Microsoft:
"Die Blockliste für anfällige Treiber soll dazu beitragen, Systeme gegen nicht von Microsoft entwickelte Treiber im gesamten Windows-Ökosystem zu härten"
Microsofts eigene Treiber sind von der Blockliste von Natur aus ausgeschlossen.
Die Grundursache ist einfach: MmCopyMemory respektiert PPL nicht.
PPL (Protected Process Light) wurde entwickelt, um den Diebstahl von Anmeldeinformationen zu verhindern, indem es OpenProcess- und ReadProcessMemory-Aufrufe gegen LSASS blockiert. Aber PPL schützt nur den Benutzermodus-API-Pfad. Es hat keine Autorität über Kernel-Mode-Reads des physischen Speichers.
KslD.sys gibt Code im Benutzermodus einen direkten Pfad zu MmCopyMemory() – Microsofts eigener Kernel-API zum Kopieren von Speicher nach physischer oder virtueller Adresse. Der Treiber führt durch:
Das Ergebnis: Ein Microsoft-signierter Treiber bietet sofort eine vollständige PPL-Umgehung.
Der Kern der Sicherheitslücke ist SubCmd 12 – ein uneingeschränkter MmCopyMemory()-Wrapper:
IOCTL: 0x222044
Input: struct {
DWORD SubCmd; // 12
DWORD Reserved; // 0
QWORD Address; // Target VA or PA
QWORD Size; // Bytes to read
DWORD Flags; // 1 = Physical, 2 = Virtual
DWORD Padding;
}
Output: Raw memory contents (up to Size bytes)
Physisches Lesen (Flags = 1) ist das kritische Primitiv. Der Zugriff auf den physischen Speicher unterliegt keinen Prozessschutzebenen, EPROCESS-Flags oder Beschränkungen der Benutzermodus-API, was PPL umgeht.
Virtuelles Lesen (Flags = 2) liest Kernel-Virtualadressen direkt, nützlich zum Durchlaufen von Kernel-Strukturen (EPROCESS, ntoskrnl-Exporte) ohne manuelle Seitentabellenübersetzung.