BYOVD: Deteção e Prevenção num Endpoint Windows 11 com Hardening

Bring Your Own Vulnerable Driver (BYOVD) continua a ser uma das formas mais fiáveis de os atacantes porem código a correr no kernel do Windows em 2026. Em vez de encontrar um exploit de kernel fresco, o atacante traz um driver legitimamente assinado mas vulnerável, carrega-o e abusa da funcionalidade exposta (normalmente via IOCTLs) para ler e escrever memória de kernel, terminar processos protegidos ou cegar e desativar as próprias defesas do endpoint.

Este artigo percorre um laboratório prático onde testámos BYOVD contra uma máquina Windows 11 totalmente gerida e protegida por EDR, e mostra que mesmo com os controlos "Block Vulnerable Drivers" ativados, um número significativo de drivers conhecidos como vulneráveis continua a carregar e a correr. Terminamos com um conjunto de mitigações e defesas que realmente fazem a diferença.

Aviso. Esta investigação foi realizada num laboratório isolado que possuímos e controlamos, para fins defensivos. Não corra drivers vulneráveis nem ferramentas de matar EDR contra sistemas que não está autorizado a testar.

Metodologia

Agrupamos os drivers vulneráveis em três categorias conforme o quão "conhecidos" são para os defensores:

• Categoria 1: Blocklisted + PoC público. Drivers já em blocklists públicas (a Vulnerable Driver Blocklist da Microsoft, LOLDrivers) com um exploit pronto a usar publicado.
• Categoria 2: Blocklisted, sem PoC público. Drivers listados como vulneráveis mas sem exploit turnkey; é preciso escrever o próprio.
• Categoria 3: Não listado / desconhecido. Drivers vulneráveis ainda não catalogados em lado nenhum. Zero-days: vulnerabilidade desconhecida, driver desconhecido, sem entrada em blocklist.

Para este laboratório usámos um fork do projeto BYOVD do BlackSnufkin, um PoC em Rust que abusa de IOCTLs de drivers para terminar processos arbitrários por PID a partir de kernel mode, com ~21 drivers vulneráveis (Categoria 1), mais um driver adicional do LOLDrivers sem exploit público (Categoria 2), e drivers descobertos em software Windows de terceiros ainda não listados em lado nenhum, para os quais desenvolvemos um PoC que abusa de um zero-day (Categoria 3). Este artigo foca a Categoria 1, porque é o caso que os defensores deviam estar melhor equipados para parar e, como veremos, muitas vezes não estão.

Ambiente de Laboratório

O endpoint está onboarded no MDE e inscrito via Intune → Endpoint security → Attack surface reduction, com o perfil de Attack Surface Reduction Rules. A regra específica é "Block abuse of exploited vulnerable signed drivers", definida para Block. É exatamente a configuração que uma organização preocupada com segurança implementaria: um SO moderno, um EDR de topo, gestão por MDM e o próprio controlo anti-BYOVD do vendor ligado.

Parte 1: Deteção à Escrita

Copiámos todos os 21 drivers do BlackSnufkin para disco em C:\drivers\BYOVD-main\. 7 drivers foram sinalizados e postos em quarentena pelo MDE no momento em que tocaram o disco, detetados como VulnerableDriver:* (e um como Trojan:Win64/KillAV):

• Ksapi64-Killer
• NSec-Killer
• PoisonX-Killer
• STProcessMonitor-Killer
• TfSysMon-Killer
• UnknownKiller
• Viragt64-Killer

Os restantes 14 drivers ficaram em disco; o Defender não os sinalizou à escrita: AppRemover-Killer, Astra64-RW, BdApiUtil-Killer, CcProtect-Killer, EnPortv-Killer, GameDriverX64-Killer, GoFlyDrv-Killer, HWAudioOs2Ec-Killer, K7Terminator, MonProcessEX-Killer, PCTcore64-Killer, Wsftprm-Killer, Xhunter1-Killer, Xkpsm-Killer.

Conclusão: a deteção à escrita/ao acesso só apanhou um terço de um conjunto de drivers da Categoria 1 publicamente conhecido. O resto depende de controlos ao carregamento, que testamos de seguida.

Parte 2: Registar e Arrancar os Drivers

Um driver de kernel só se torna interessante quando é registado como serviço e arrancado. Usámos um pequeno wrapper PowerShell em torno do sc.exe para registar cada .sys como serviço kernel-mode de arranque a pedido. Todos os serviços foram criados com sucesso; registar o serviço e escrever a chave HKLM\SYSTEM\CurrentControlSet\Services\<nome> não é em si bloqueado.

#Requires -RunAsAdministrator
$SC = "$env:SystemRoot\System32\sc.exe"
$DriverRoot = 'C:\drivers\BYOVD-main'

Get-ChildItem -LiteralPath $DriverRoot -Filter *.sys -Recurse -File -Force |
ForEach-Object {
    $name = $_.BaseName
    $key = "HKLM:\SYSTEM\CurrentControlSet\Services\$name"
    if (Test-Path $key) {
        & $SC delete $name 2>&1 | Out-Null
        Remove-Item $key -Recurse -Force -ErrorAction SilentlyContinue
    }
    $out = & $SC create $name binPath= $_.FullName type= kernel start= demand
    if ($LASTEXITCODE -eq 0) {
        Write-Host "[+] $name -> $($_.FullName)" -ForegroundColor Cyan
    } else {
        Write-Warning "[-] $name : $($out -join ' ')"
    }
}

A parte interessante é o sc start, que despoleta o carregamento real no kernel. Aqui as proteções em camadas finalmente entram em ação, mas só para alguns drivers:

Um driver até mostrou uma mensagem explícita: PCTcore64.sys: A security setting is detecting this as a vulnerable driver and blocking it from loading. You will need to adjust your settings to load this driver.

Apesar de todas as proteções ativadas, 9 drivers conhecidos como vulneráveis atingiram o estado RUNNING e ficaram vivos no kernel: ardrv, ASTRA64, CcProtect, EnPortv, GoFly64, HWAudioOs2Ec_1, MonProcessEX, STProcessMonitor_v114, xkpsm. Não são drivers obscuros. A maioria estava catalogada no LOLDrivers meses antes deste teste. A entrada mais antiga foi publicada em março de 2026; a 8 de agosto de 2026, quase cinco meses depois, ainda carregam e correm numa máquina totalmente atualizada e endurecida por política. Este é o achado central: a cobertura das blocklists está atrás da divulgação pública, e a lacuna mede-se em meses.

Parte 3: Abusar de um Driver Carregado para Matar o Defender

Para mostrar que um driver que "ainda carrega" não é um problema teórico, pegámos num dos drivers em execução (CcProtect.sys) e usámos o PoC BYOVD para terminar processos protegidos a partir do kernel. O PoC abre o device object do driver (\\.\CcProtect) e envia o IOCTL 0x222024 com o nome do processo-alvo; o driver, a correr em kernel mode, termina o PID correspondente, contornando a proteção de user mode (PPL) que normalmente blinda estes processos.

Apontámo-lo diretamente a todo o stack Defender / MDE:

• MsMpEng.exe - motor do Defender Antivirus
• MpDefenderCoreService.exe - serviço core do Defender
• SecurityHealthService.exe
• NisSrv.exe - serviço de inspeção de rede
• MsSense.exe, SenseIR.exe, SenseTVM.exe, SenseNdr.exe - componentes do sensor MDE

Todos correm como Protected Processes (PsProtectedSignerAntimalware-Light / PsProtectedSignerWindows-Light). As mortes sucedem. Uma ferramenta de user mode nunca conseguiria fazer isto a um processo antimalware protegido por PPL, mas um driver de kernel consegue.

Uma ressalva quanto à persistência: o Defender tem auto-recuperação. Os serviços antimalware geridos pelo MpDefenderCoreService acabam por renascer. Para manter o endpoint cego, um atacante tem de re-matar os processos continuamente ou encadear numa persistência completa SYSTEM/kernel para parar e remover os serviços de vez. De qualquer forma, o ponto mantém-se: BYOVD é uma ameaça real e atual à segurança de endpoints, mesmo com antimalware e EDR instalados e configurados.

Regras de Deteção Personalizadas no Microsoft Defender XDR

Como a blocklist integrada falha drivers desconhecidos e ainda assinados, podemos fechar parte da lacuna com uma regra de deteção personalizada no Microsoft Defender XDR que alerta sobre qualquer novo registo de driver de kernel, vulnerável ou não. Uma abordagem ingénua vigiaria sc.exe create ... type= kernel, mas isso é trivialmente contornável: um atacante pode registar o driver diretamente via Service Control Manager API, via NtLoadDriver ou com syscalls indiretas, nada do qual toca o sc.exe. Filtrar por caminhos de ficheiro suspeitos é igualmente fraco.

O chokepoint robusto é o registry. Todas essas técnicas (incluindo NtLoadDriver) continuam a exigir uma chave de serviço sob ...\CurrentControlSet\Services\<nome> com um ImagePath a apontar para o .sys. Detetamos essa escrita em qualquer caminho e aplicamos um modelo default-deny: alertar sobre todo o registo de driver de kernel exceto os que estiverem numa baseline known-good mantida.

// Alerta sobre QUALQUER novo registo de serviço de driver de kernel, independentemente da ferramenta ou caminho.
// A escrita em Services\<name>\ImagePath é o invariante pelo qual sc.exe, a SCM API
// e o NtLoadDriver passam todos.
DeviceRegistryEvents
| where ActionType in ("RegistryValueSet", "RegistryKeyCreated")
| where RegistryKey has @"\CurrentControlSet\Services\"
| where RegistryValueName == "ImagePath" and RegistryValueData endswith ".sys"
// default-deny: manter apenas o que NÃO está na baseline aprovada.
// Manter KnownGoodDrivers como watchlist, idealmente keyed por hash/signer em vez de caminho.
| where RegistryValueData !in~ (KnownGoodDrivers)
| project Timestamp, DeviceName, RegistryKey, RegistryValueData,
    InitiatingProcessFileName, InitiatingProcessCommandLine,
    InitiatingProcessAccountName

Guarde como regra de deteção personalizada no Advanced Hunting; defina frequência, severidade e as entidades de máquina/ficheiro a mapear para que um evento correspondente levante um alerta e, opcionalmente, despolete uma resposta automatizada. Um registo a apontar para fora de \Windows\System32\drivers\ merece severidade mais alta.

Mitigações e Defesas

Nenhum controlo isolado para o BYOVD; é preciso defence-in-depth. Aproximadamente por ordem de impacto:

• 1. Imponha a Microsoft Vulnerable Driver Blocklist e não dependa só dela. Ligue-a (vem ativada com HVCI/SAC no Windows moderno), mas trate-a como necessária-mas-insuficiente. Como mostrado acima, a blocklist segue a divulgação pública com meses de atraso e falhou 9 de 21 drivers bem conhecidos aqui.
• 2. Ative VBS, HVCI/Memory Integrity e Device Guard. O Hypervisor-Enforced Code Integrity (HVCI) corre a code integrity de kernel mode dentro de um ambiente isolado por VBS e força validação de assinatura e verificação de revogação de certificados ao carregamento. É o single passo de hardening de plataforma mais valioso. Faça rollout primeiro para um anel de testes; drivers incompatíveis podem causar falhas de arranque.
• 3. Mude para uma allow-list com App Control for Business (WDAC). Em vez de bloquear o known-bad, permitir apenas o known-good: whitelist de publishers, signers e hashes específicos de drivers. É a única abordagem que também endereça os drivers da Categoria 3 (desconhecidos/zero-day), porque um driver não listado é negado por defeito.
• 4. Imponha requisitos modernos de assinatura de drivers (EV / WHQL) e bloqueie drivers legados. Muitos drivers abusados são binários antigos cross-signed. Impor assinatura moderna fecha uma fatia grande do catálogo das Categorias 1/2.
• 5. Restrinja quem pode registar e carregar drivers. O carregamento de drivers exige admin local / SeLoadDriverPrivilege. Imponha least privilege e admin JIT/JEA para as equipas de IT.
• 6. Audite e remova drivers de terceiros arriscados. Anti-cheats de gaming, utilitários de overclocking de GPU/CPU e velhas ferramentas de informação de sistema dos vendors são reincidentes em endpoints de produção. Faça patch ou proíba software que agregue versões de drivers conhecidas como vulneráveis.
• 7. Mantenha assinaturas, motor e blocklist atualizados. Garanta que a proteção cloud do MDE e a blocklist de drivers se atualizam automaticamente. Uma blocklist desatualizada é exatamente o modo de falha ilustrado acima.
• 8. Mantenha o ASR em modo Block. Use primeiro Audit para estabelecer baseline e depois passe a Block para "Block abuse of exploited vulnerable signed drivers" acompanhado do conjunto alargado de regras ASR.
• 9. Vigie o comportamento, não apenas o binário. Sysmon Event ID 6 (driver load) correlacionando hash, estado da assinatura e caminho; Event ID 7045 (novo serviço instalado); novas escritas de registry de serviços kernel; eventos de bloqueio WDAC (3023 / 3033). Alerte sobre carregamentos a partir de caminhos escrevíveis pelo utilizador (\AppData\, \Temp\, \ProgramData\) e cruze os hashes com o loldrivers.io.
• 10. Vigie o impacto. Pedidos IOCTL anómalos a um device object recém-carregado, remoção de callbacks de kernel e terminação de processos PPL/antimalware iniciada no kernel são sinais de alta fidelidade de que uma morte já está em curso. Configure alertas imediatos sobre terminação de processos de segurança e falhas de heartbeat do sensor no portal do MDE.
• 11. Valide continuamente e planeie a falha. Assuma que algum driver vai passar. Corra simulações BYOVD e exercícios de red team, isole hosts com atividade de kernel suspeita e garanta que os planos de backup e recuperação contemplam o cenário em que a prevenção falhou.

Onde as Blocklists Ficam Curtas

O tema consistente é que bloquear por reputação é sempre reativo. Um driver tem de ser descoberto, analisado, catalogado e empurrado para a blocklist antes de ser parado, e todos os dias nessa janela ele carrega sem problemas. Os drivers das Categorias 2 e 3 nunca entram nessa janela. Eis como cada controlo se sai no caso mais difícil: um driver vulnerável validamente assinado mas desconhecido (Categoria 3 / zero-day):

Os controlos de assinatura e reputação são estruturalmente cegos a um driver desconhecido-mas-assinado. Só a autorização de carregamento (allow-listing) e a deteção comportamental o endereçam, e mesmo o allow-listing falha se o driver vulnerável for um que legitimamente aprovou, deixando a deteção comportamental do impacto (mortes PPL inesperadas, remoção de callbacks, IOCTLs suspeitosos) como última linha.

É por isso que a resposta mais duradoura é detetar e controlar o ato de carregar um driver, vulnerável ou não, em vez de comparar contra uma lista de maus. Na próxima parte desta série aprofundamos exatamente isso: personalizar a lógica de deteção EDR/XDR (Defender Advanced Hunting KQL e queries análogas em Elastic) mais allow-listing WDAC, para trazer à superfície qualquer evento de carregamento de driver e decidir sobre ele por política, fechando a lacuna que as defesas BYOVD baseadas em assinaturas e blocklists deixam aberta.

Referências

• Microsoft: Enable memory integrity (HVCI / VBS)
• Microsoft: Strategies to monitor and prevent vulnerable driver attacks
• BlackSnufkin: BYOVD project
• LOLDrivers
• Check Point Research: Breaking Boundaries: Investigating Vulnerable Drivers and Mitigating Risks
• Cisco Talos: Exploring vulnerable Windows drivers
• CrowdStrike: Falcon Prevents Vulnerable Driver Attacks in a Real-World Intrusion