andreisss/ksldumpKslDump — Por que trazer sua própria faca se o Defender já deixou uma na cozinha?
Relatei o problema à Microsoft em 7 de março de 2026. No entanto, quase 20 dias antes, a comunidade de hacking de jogos já havia feito engenharia reversa e discutido publicamente. Do meu lado, não acompanho os projetos deles e não tinha conhecimento disso. Também está claro que são dois projetos completamente separados e não relacionados.
Por que trazer sua própria faca se o Defender já deixou uma na cozinha?
KslDump extrai credenciais do LSASS protegido por PPL usando apenas componentes assinados pela Microsoft. Nenhum exploit é implantado. Nenhum driver é carregado. Toda a cadeia de ataque é pré-instalada com o Windows Defender. A Microsoft corrigiu a versão em execução (wd\KslD.sys) anulando MmCopyMemory, mas deixou a versão antiga vulnerável (drivers\KslD.sys) no disco. O atacante não traz nada — ele apenas aponta o serviço de volta para o que a Microsoft esqueceu de limpar.
https://github.com/user-attachments/assets/78dfce25-56b3-4eb8-9de2-7c183601e597
KslD.sys é um driver de kernel fornecido com o Microsoft Defender. É assinado pela Microsoft, carregado como um módulo de kernel confiável e expõe um objeto de dispositivo \\.\KslD acessível do modo de usuário.
O driver aceita o IOCTL 0x222044 com vários subcomandos que fornecem acesso irrestrito à memória do kernel e física para qualquer processo que possa abrir o manipulador do dispositivo.
| SubCmd | Capacidade | Impacto |
|---|---|---|
| 2 | Retorna CR3, IDTR e outros registradores de controle da CPU para o modo de usuário | Derrota instantânea do KASLR |
| 12 | Chama MmCopyMemory() com endereço e tamanho controlados pelo atacante | Leitura arbitrária de memória do kernel/física |
A única barreira para o manipulador do dispositivo é uma string de nome de processo armazenada em uma chave de registro (AllowedProcessName) na chave de serviço do driver. Este valor é:
A diferença é uma linha em 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
}
As atualizações da plataforma Defender parecem colocar a versão corrigida de 82 KB em drivers\wd\ e apontar ImagePath para ela, enquanto a versão mais antiga de 333 KB permanece em drivers\. Em sistemas testados, o binário antigo nunca foi removido. O exploit simplesmente troca o ImagePath de volta para a versão vulnerável e reinicia o serviço. Ambos os binários são assinados pela Microsoft e confiáveis pelo sistema operacional.
A documentação pública da Microsoft mostra que o KB4052623 fornece atualizações da plataforma Defender, incluindo uma movimentação histórica dos drivers do Defender para System32\drivers\wd, enquanto a manutenção do Windows mantém arquivos do repositório de componentes com backup do WinSxS via links físicos NTFS e só remove versões de componentes substituídas durante a limpeza. No sistema testado, isso explica por que o novo KslD.sys de 82 KB poderia chegar pelo caminho de atualização da plataforma Defender enquanto o KslD.sys mais antigo de 333 KB em System32\drivers\ permanecia presente como a cópia atual do repositório de componentes com backup do CBS até ser substituído por uma versão mais recente do CBS.
A Microsoft mantém uma Lista de Bloqueio de Drivers Vulneráveis (DriverSiPolicy.p7b) especificamente para impedir ataques BYOVD. Esta lista de bloqueio é aplicada via HVCI e impede o carregamento de drivers assinados conhecidamente vulneráveis.
Da própria documentação da Microsoft:
"A lista de bloqueio de drivers vulneráveis foi projetada para ajudar a fortalecer sistemas contra drivers não desenvolvidos pela Microsoft em todo o ecossistema Windows"
Os próprios drivers da Microsoft são excluídos da lista de bloqueio por design.
A causa raiz é simples: MmCopyMemory não respeita o PPL.
PPL (Protected Process Light) foi projetado para impedir o roubo de credenciais bloqueando chamadas OpenProcess e ReadProcessMemory contra o LSASS. Mas o PPL protege apenas o caminho da API do modo de usuário. Ele não tem autoridade sobre leituras de memória física no modo kernel.
KslD.sys dá ao código do modo de usuário um caminho direto para MmCopyMemory() — a própria API de kernel da Microsoft para copiar memória por endereço físico ou virtual. O driver realiza:
O resultado: um driver assinado pela Microsoft fornece uma bypass completa do PPL pronta para uso.
O núcleo da vulnerabilidade é o SubCmd 12 — um wrapper irrestrito de MmCopyMemory():
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)
Leitura física (Flags = 1) é a primitiva crítica. O acesso à memória física não está sujeito a níveis de proteção de processo, flags EPROCESS ou quaisquer restrições de API do modo de usuário, isso é o que contorna o PPL.
Leitura virtual (Flags = 2) lê endereços virtuais do kernel diretamente, útil para percorrer estruturas do kernel (EPROCESS, exports do ntoskrnl) sem tradução manual da tabela de páginas.
┌──────────────────────────────────────────────────────────────────┐
│ Ataque do KslDump │
├──────────────────────────────────────────────────────────────────┤
│ │
│ 1. Editar Registro ImagePath ← versão vulnerável 333KB │
│ │ KslD.sys * │
│ │ AllowedProcessName ← nosso processo │
│ │ sc stop/start KslD │
│ ▼ │
│ 2. Bypass KASLR SubCmd 2 → CR3 + IDTR │
│ │ IDT → ISR mais baixo → base ntoskrnl │
│ ▼ │
│ 3. Walk do Kernel PsInitialSystemProcess → EPROC SYSTEM│
│ │ ActiveProcessLinks → encontrar lsass │
│ │ Ler DTB do lsass de EPROCESS+0x28 │
│ ▼ (tudo via SubCmd 12, flags=2) │
│ │
│ 4. Leitura Física Caminhada na tabela de páginas usando│
│ │ DTB do lsass │
│ │ MmCopyMemory() lê páginas do lsass │
│ │ *** CONTORNA PPL *** │
│ ▼ (SubCmd 12, flags=1) │
│ │
│ 5. Extração de Chaves Encontrar lsasrv.dll via PEB → LDR │
│ │ Escanear .text por assinaturas LSA │
│ │ Seguir cadeia BCRYPT → AES + 3DES + IV│
│ ▼ │
│ 6. Dump de Credenciais Percorrer LogonSessionList │
│ Descriptografar credenciais MSV1_0 │
│ → Hashes NT │
│ │
└──────────────────────────────────────────────────────────────────┘
cryptography (pip install cryptography)C:\Windows\System32\drivers\KslD.sys)O ataque não requer drivers de terceiros, código não assinado ou exploits. Tudo é assinado pela Microsoft, fornecido pela Microsoft e já está no sistema. O driver vulnerável está no disco ao lado de sua própria correção, excluído da lista de bloqueio destinada a impedir exatamente essa classe de ataque.
Esta vulnerabilidade foi relatada ao Microsoft Security Response Center (MSRC). Eles a fecharam como "Não é uma Vulnerabilidade" com a seguinte justificativa:
"O ataque descrito depende de privilégios administrativos pré-existentes. Nenhuma evidência foi fornecida mostrando como esses privilégios foram obtidos. Relatórios que assumem acesso administrativo ou root sem demonstrar uma vulnerabilidade que conceda esses privilégios são considerados de menor impacto, pois um atacante com tal acesso já poderia realizar ações mais severas."
Nenhum CVE foi atribuído. Nenhuma correção foi emitida.
Esta ferramenta é fornecida apenas para fins autorizados de teste de segurança e pesquisa. Use-a apenas em sistemas que você possui ou para os quais tenha permissão explícita por escrito para testar. O acesso não autorizado a sistemas de computador é ilegal. O autor não assume nenhuma responsabilidade pelo uso indevido.