andreisss/ksldumpKslDump — Pourquoi apporter votre propre couteau quand Defender en a déjà laissé un dans la cuisine ?
J'ai signalé le problème à Microsoft le 7 mars 2026. Cependant, près de 20 jours plus tôt, la communauté du game-hacking avait déjà fait de la rétro-ingénierie et en avait discuté publiquement. De mon côté, je ne suis pas leurs projets et je n'étais au courant de rien de tout cela. Il est également clair qu'il s'agit de deux projets complètement séparés et sans rapport.
Pourquoi apporter son propre couteau alors que Defender en a déjà laissé un dans la cuisine ?
KslDump extrait les informations d'identification du LSASS protégé par PPL en utilisant uniquement des composants signés par Microsoft. Aucun exploit n'est déployé. Aucun pilote n'est chargé. Toute la chaîne d'attaque est préinstallée avec Windows Defender. Microsoft a corrigé la version en cours d'exécution (wd\KslD.sys) en mettant à zéro MmCopyMemory, mais a laissé l'ancienne version vulnérable (drivers\KslD.sys) sur le disque. L'attaquant n'apporte rien — il se contente de pointer le service vers ce que Microsoft a oublié de nettoyer.
https://github.com/user-attachments/assets/78dfce25-56b3-4eb8-9de2-7c183601e597
KslD.sys est un pilote noyau livré avec Microsoft Defender. Il est signé par Microsoft, chargé en tant que module noyau de confiance, et expose un objet de périphérique \\.\KslD accessible depuis l'espace utilisateur.
Le pilote accepte l'IOCTL 0x222044 avec plusieurs sous-commandes qui fournissent un accès illimité à la mémoire noyau et physique à tout processus pouvant ouvrir le handle du périphérique.
| Sous-Cmd | Capacité | Impact |
|---|---|---|
| 2 | Retourne CR3, IDTR et d'autres registres de contrôle CPU à l'espace utilisateur | Contournement instantané de KASLR |
| 12 | Appelle MmCopyMemory() avec une adresse et une taille contrôlées par l'attaquant | Lecture mémoire noyau/physique arbitraire |
La seule porte d'accès au handle du périphérique est une chaîne de nom de processus stockée dans une clé de registre (AllowedProcessName) sous la clé de service du pilote. Cette valeur est :
La différence tient à une ligne dans 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
}
Les mises à jour de la plateforme Defender semblent déposer la version corrigée de 82 Ko dans drivers\wd\ et pointer ImagePath vers celle-ci, tandis que l'ancienne version de 333 Ko reste dans drivers\. Sur les systèmes testés, l'ancien binaire n'a jamais été supprimé. L'exploit se contente de basculer ImagePath vers la version vulnérable et de redémarrer le service. Les deux binaires sont signés par Microsoft et considérés comme fiables par le système d'exploitation.
La documentation publique de Microsoft montre que KB4052623 fournit des mises à jour de la plateforme Defender, y compris un déplacement historique des pilotes Defender vers System32\drivers\wd, tandis que le service Windows conserve les fichiers du magasin de composants sauvegardés par WinSxS via des liens physiques NTFS et ne supprime les versions de composants obsolètes que lors du nettoyage. Sur le système testé, cela explique pourquoi le nouveau KslD.sys de 82 Ko a pu arriver via le chemin de mise à jour de la plateforme Defender tandis que l'ancien System32\drivers\KslD.sys de 333 Ko restait présent en tant que copie actuelle du magasin de composants sauvegardé par CBS jusqu'à ce qu'il soit remplacé par une version plus récente de CBS.
Microsoft maintient une liste de blocage des pilotes vulnérables (DriverSiPolicy.p7b) spécifiquement pour empêcher les attaques BYOVD. Cette liste de blocage est appliquée via HVCI et empêche le chargement des pilotes signés connus comme vulnérables.
D'après la propre documentation de Microsoft :
« La liste de blocage des pilotes vulnérables est conçue pour aider à renforcer les systèmes contre les pilotes non développés par Microsoft dans l'écosystème Windows »
Les propres pilotes de Microsoft sont exclus de la liste de blocage par conception.
La cause racine est simple : MmCopyMemory ne respecte pas PPL.
PPL (Protected Process Light) a été conçu pour empêcher le vol d'informations d'identification en bloquant les appels OpenProcess et ReadProcessMemory contre LSASS. Mais PPL ne protège que le chemin de l'API espace utilisateur. Il n'a aucune autorité sur les lectures de mémoire physique en mode noyau.
KslD.sys donne au code espace utilisateur un chemin direct vers MmCopyMemory() — la propre API noyau de Microsoft pour copier la mémoire par adresse physique ou virtuelle. Le pilote effectue :
Le résultat : un pilote signé par Microsoft fournit un contournement complet de PPL dès sa sortie de boîte.
Le cœur de la vulnérabilité est SubCmd 12 — un wrapper MmCopyMemory() sans restriction :
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)
La lecture physique (Flags = 1) est la primitive critique. L'accès à la mémoire physique n'est pas soumis aux niveaux de protection des processus, aux flags EPROCESS, ni à aucune restriction de l'API espace utilisateur, c'est ce qui contourne PPL.
La lecture virtuelle (Flags = 2) lit directement les adresses virtuelles du noyau, utile pour parcourir les structures du noyau (EPROCESS, exports ntoskrnl) sans traduction manuelle de la table des pages.
┌──────────────────────────────────────────────────────────────────┐
│ KslDump Attack Flow │
├──────────────────────────────────────────────────────────────────┤
│ │
│ 1. Registry Edit ImagePath ← vulnerable 333KB KslD.sys *│
│ │ AllowedProcessName ← our process │
│ │ sc stop/start KslD │
│ ▼ │
│ 2. KASLR Bypass SubCmd 2 → CR3 + IDTR │
│ │ IDT → lowest ISR → ntoskrnl base │
│ ▼ │
│ 3. Kernel Walk PsInitialSystemProcess → SYSTEM EPROC │
│ │ ActiveProcessLinks → find lsass.exe │
│ │ Read lsass DTB from EPROCESS+0x28 │
│ ▼ (all via SubCmd 12, flags=2) │
│ │
│ 4. Physical Read Page table walk using lsass DTB │
│ │ MmCopyMemory() reads lsass pages │
│ │ *** BYPASSES PPL *** │
│ ▼ (SubCmd 12, flags=1) │
│ │
│ 5. Key Extraction Find lsasrv.dll via PEB → LDR │
│ │ Scan .text for LSA key signatures │
│ │ Follow BCRYPT chain → AES + 3DES + IV │
│ ▼ │
│ 6. Credential Dump Walk LogonSessionList │
│ Decrypt MSV1_0 credentials │
│ → NT hashes │
│ │
└──────────────────────────────────────────────────────────────────┘
cryptography (pip install cryptography)C:\Windows\System32\drivers\KslD.sys)L'attaque ne nécessite aucun pilote tiers, aucun code non signé, aucun exploit. Tout est signé par Microsoft, livré par Microsoft et déjà présent sur le système. Le pilote vulnérable se trouve sur le disque à côté de son propre correctif, exclu de la liste de blocage destinée à empêcher exactement cette classe d'attaques.
Cette vulnérabilité a été signalée au Microsoft Security Response Center (MSRC). Ils l'ont fermée en tant que « Ce n'est pas une vulnérabilité » avec la justification suivante :
« L'attaque décrite dépend de privilèges administratifs préexistants. Aucune preuve n'a été fournie montrant comment ces privilèges ont été obtenus. Les rapports qui supposent un accès administrateur ou root sans démontrer une vulnérabilité qui accorde ces privilèges sont considérés comme ayant un impact moindre, car un attaquant disposant d'un tel accès pourrait déjà effectuer des actions plus graves. »
Aucun CVE n'a été attribué. Aucun correctif n'a été publié.
Cet outil est fourni uniquement à des fins de test de sécurité et de recherche autorisées. Utilisez-le uniquement sur des systèmes que vous possédez ou pour lesquels vous avez une autorisation écrite explicite pour tester. L'accès non autorisé aux systèmes informatiques est illégal. L'auteur décline toute responsabilité en cas d'utilisation abusive.