andreisss/ksldumpKslDump — Perché portare il proprio coltello quando Defender ne ha già lasciato uno in cucina?
Ho segnalato il problema a Microsoft il 7 marzo 2026. Tuttavia, quasi 20 giorni prima, la comunità di hacking dei videogiochi lo aveva già invertito e discusso pubblicamente. Da parte mia, non seguo i loro progetti e non ero a conoscenza di nulla di tutto ciò. È anche chiaro che si tratta di due progetti completamente separati e non correlati.
Perché portare il proprio coltello quando Defender ne ha già lasciato uno in cucina?
KslDump estrae le credenziali da LSASS protetto da PPL utilizzando soli componenti firmati Microsoft. Non viene distribuito alcun exploit. Non viene caricato alcun driver. L'intera catena d'attacco è preinstallata con Windows Defender. Microsoft ha corretto la versione in esecuzione (wd\KslD.sys) azzerando MmCopyMemory, ma ha lasciato la vecchia versione vulnerabile (drivers\KslD.sys) sul disco. L'aggressore non porta nulla — si limita a reindirizzare il servizio verso ciò che Microsoft ha dimenticato di ripulire.
https://github.com/user-attachments/assets/78dfce25-56b3-4eb8-9de2-7c183601e597
KslD.sys è un driver kernel fornito con Microsoft Defender. È firmato Microsoft, caricato come modulo kernel attendibile ed espone un oggetto dispositivo \\.\KslD accessibile dalla modalità utente.
Il driver accetta l'IOCTL 0x222044 con diversi sotto-comandi che forniscono accesso illimitato alla memoria kernel e fisica a qualsiasi processo che possa aprire l'handle del dispositivo.
| SubCmd | Capacità | Impatto |
|---|---|---|
| 2 | Restituisce CR3, IDTR e altri registri di controllo della CPU alla modalità utente | Sconfitta istantanea di KASLR |
| 12 | Chiama MmCopyMemory() con indirizzo e dimensione controllati dall'aggressore | Lettura arbitraria della memoria kernel/fisica |
L'unico gate per l'handle del dispositivo è una stringa del nome del processo memorizzata in una chiave di registro (AllowedProcessName) sotto la chiave del servizio del driver. Questo valore è:
La differenza è una riga in CCommand::Initialize:
// Versione 82 KB (corretta) — cancella deliberatamente il puntatore:
v3 = MmGetSystemRoutineAddress(L"MmCopyMemory");
if (v3 >= 0) {
*(a1 + 24) = 0; // ← Lo azzera — SubCmd 12 è morto
}
// Versione 333 KB (vulnerabile) — memorizza il puntatore:
ptr = MmGetSystemRoutineAddress(L"MmCopyMemory");
if (ptr) {
*(this + 0x18) = ptr; // ← Lo mantiene — SubCmd 12 funziona
}
Gli aggiornamenti della piattaforma Defender sembrano rilasciare la versione corretta da 82 KB in drivers\wd\ e puntare ImagePath su di essa, mentre la versione più vecchia da 333 KB rimane in drivers\. Sui sistemi testati, il vecchio binario non è mai stato rimosso. L'exploit si limita a reimpostare ImagePath sulla versione vulnerabile e riavviare il servizio. Entrambi i binari sono firmati Microsoft e attendibili dal sistema operativo.
La documentazione pubblica di Microsoft mostra che KB4052623 fornisce gli aggiornamenti della piattaforma Defender, incluso uno spostamento storico dei driver Defender in System32\drivers\wd, mentre il servizio Windows mantiene i file dell'archivio componenti supportati da WinSxS tramite collegamenti reali NTFS e rimuove solo le versioni sostituite dei componenti durante la pulizia. Sul sistema testato, questo spiega perché il nuovo KslD.sys da 82 KB potrebbe arrivare attraverso il percorso di aggiornamento della piattaforma Defender mentre il vecchio KslD.sys da 333 KB in System32\drivers\ rimaneva presente come copia corrente dell'archivio componenti supportato da CBS fino a quando non sostituito da una versione CBS più recente.
Microsoft mantiene una Vulnerable Driver Blocklist (DriverSiPolicy.p7b) specificamente per prevenire attacchi BYOVD. Questa blocklist viene applicata tramite HVCI e blocca il caricamento di driver firmati noti come vulnerabili.
Dalla documentazione di Microsoft:
"La blocklist dei driver vulnerabili è progettata per aiutare a rafforzare i sistemi contro driver non sviluppati da Microsoft nell'ecosistema Windows"
I driver di Microsoft sono esclusi dalla blocklist per progettazione.
La causa principale è semplice: MmCopyMemory non rispetta PPL.
PPL (Protected Process Light) è stato progettato per prevenire il furto di credenziali bloccando le chiamate OpenProcess e ReadProcessMemory contro LSASS. Ma PPL protegge solo il percorso API della modalità utente. Non ha alcuna autorità sulle letture fisiche della memoria in modalità kernel.
KslD.sys fornisce al codice in modalità utente un percorso diretto a MmCopyMemory() — l'API kernel di Microsoft per copiare memoria tramite indirizzo fisico o virtuale. Il driver esegue:
Il risultato: un driver firmato Microsoft fornisce un bypass completo di PPL già pronto all'uso.
Il cuore della vulnerabilità è SubCmd 12 — un wrapper senza restrizioni di MmCopyMemory():
IOCTL: 0x222044
Input: struct {
DWORD SubCmd; // 12
DWORD Reserved; // 0
QWORD Address; // VA o PA di destinazione
QWORD Size; // Byte da leggere
DWORD Flags; // 1 = Fisico, 2 = Virtuale
DWORD Padding;
}
Output: Contenuto grezzo della memoria (fino a Size byte)
La lettura fisica (Flags = 1) è la primitiva critica. L'accesso alla memoria fisica non è soggetto a livelli di protezione del processo, flag EPROCESS o restrizioni API della modalità utente, questo è ciò che bypassa PPL.
La lettura virtuale (Flags = 2) legge direttamente indirizzi virtuali del kernel, utile per esaminare le strutture del kernel (EPROCESS, esportazioni ntoskrnl) senza traduzione manuale della tabella delle pagine.
┌──────────────────────────────────────────────────────────────────┐
│ Flusso d'attacco di KslDump │
├──────────────────────────────────────────────────────────────────┤
│ │
│ 1. Modifica registro ImagePath ← KslD.sys vulnerabile 333KB *│
│ │ AllowedProcessName ← nostro processo │
│ │ sc stop/start KslD │
│ ▼ │
│ 2. Bypass KASLR SubCmd 2 → CR3 + IDTR │
│ │ IDT → ISR più basso → base ntoskrnl │
│ ▼ │
│ 3. Camminata kernel PsInitialSystemProcess → SYSTEM EPROC │
│ │ ActiveProcessLinks → trova lsass.exe │
│ │ Leggi DTB di lsass da EPROCESS+0x28 │
│ ▼ (tutto tramite SubCmd 12, flags=2) │
│ │
│ 4. Lettura fisica Camminata tabella pagine usando DTB di lsass │
│ │ MmCopyMemory() legge pagine di lsass │
│ │ *** BYPASSA PPL *** │
│ ▼ (SubCmd 12, flags=1) │
│ │
│ 5. Estrazione chiavi Trova lsasrv.dll tramite PEB → LDR │
│ │ Scansiona .text per firme chiave LSA │
│ │ Segui catena BCRYPT → AES + 3DES + IV │
│ ▼ │
│ 6. Dump credenziali Cammina LogonSessionList │
│ Decifra credenziali MSV1_0 │
│ → Hash NT │
│ │
└──────────────────────────────────────────────────────────────────┘
cryptography (pip install cryptography)C:\Windows\System32\drivers\KslD.sys)L'attacco non richiede driver di terze parti, codice non firmato o exploit. Tutto è firmato Microsoft, fornito da Microsoft e già presente sul sistema. Il driver vulnerabile si trova sul disco accanto alla sua stessa correzione, escluso dalla blocklist progettata proprio per prevenire questa classe di attacchi.
Questa vulnerabilità è stata segnalata al Microsoft Security Response Center (MSRC). L'hanno chiusa come "Non una vulnerabilità" con la seguente motivazione:
"L'attacco descritto dipende da privilegi amministrativi preesistenti. Non è stata fornita alcuna prova di come siano stati ottenuti tali privilegi. I report che presuppongono accesso amministrativo o di root senza dimostrare una vulnerabilità che concede tali privilegi vengono considerati a basso impatto, poiché un aggressore con tale accesso potrebbe già eseguire azioni più gravi."
Non è stato assegnato alcun CVE. Non è stata emessa alcuna correzione.
Questo strumento è fornito esclusivamente per scopi autorizzati di test di sicurezza e ricerca. Utilizzalo solo su sistemi di tua proprietà o per i quali hai esplicita autorizzazione scritta per i test. L'accesso non autorizzato a sistemi informatici è illegale. L'autore non si assume alcuna responsabilità per un uso improprio.