Seu EDR parou de reportar. O dashboard está verde. Nada alertou. Mas o encryptor já está rodando.
Reconstrua de trás pra frente. Um IOCTL foi enviado a um driver kernel recém-carregado, assinado e vulnerável. Com acesso à memória física, o atacante terminou os processos do EDR via ZwTerminateProcess e removeu os kernel callbacks. O agente aparece ativo, não vê nada. Nós da Tech86 já vimos esse cenário — e ele é mais comum do que parece.
BYOVD: bring your own vulnerable driver
BYOVD é uma técnica onde o atacante traz seu próprio driver vulnerável para o alvo. O driver tem assinatura válida da Microsoft — é um driver legítimo de um vendor legítimo, só que com uma vulnerabilidade explorável. O Windows permite o carregamento porque a assinatura é válida. Uma vez no kernel, o driver expõe IOCTLs que permitem leitura e escrita direta em memória física.
Com acesso à memória física, o atacante opera abaixo das proteções do sistema operacional. Termina os processos do EDR via ZwTerminateProcess. Remove os kernel callbacks que o EDR usa para monitorar criação de processos, acesso a arquivos, e injeção de threads. O agente do EDR continua rodando — aparece ativo no dashboard — mas está cego. Não vê nada porque os olhos dele foram arrancados de dentro do kernel.
The Gentlemen, Storm-2697 e a escala do problema
A assinatura é The Gentlemen, um grupo que surgiu de uma disputa no Qilin RaaS em 2025. A Microsoft rastreia como Storm-2697. Segundo a ESET, o grupo acumulou 480+ vítimas em 66 países, com 250+ na América Latina — uma concentração regional que sugere foco deliberado no nosso mercado.
Em 7 de julho de 2026, o grupo listou a Mercado Libre no leak site do dark web. Reivindicação, não incidente confirmado. Sem sample, breach não confirmado. A distinção importa: uma listagem no leak site é uma afirmação do atacante, não uma evidência de comprometimento. Mas a escala do grupo — 480+ vítimas em 66 países segundo a ESET — torna cada reivindicação digna de investigação.
Os dois EDR killers: ThrottleBlood.sys e ktapi.sys
Dois EDR killers se destacam na operação. O primeiro é ThrottleBlood.sys — na verdade, o ThrottleStop.sys renomeado, um utilitário de overclock legítimo. Tem CVE-2025-7771 atribuído, com CVSS 8.7. O driver expõe IOCTLs para leitura e escrita em memória física via MmMapIoSpace, bypassando SMEP e SMAP. Com isso, mata os principais EDRs do mercado.
O segundo é ktapi.sys, da Kontron. Zero-day sem CVE atribuído. O driver mapeia memória kernel diretamente no espaço do atacante e bypassa PatchGuard, SMAP e SMEP. A diferença crítica: ktapi.sys estava ausente dos blocklists quando foi descoberto. Blocklist é reativo — você só bloqueia o que conhece. Um zero-day sem CVE não está em nenhuma lista.
Por que PPL e blocklists não bastam
PPL (Protected Process Light) resiste a terminação via user-mode, mas não via kernel-mode. Um driver vulnerável carregado no kernel tem privilégios suficientes para terminar processos PPL. A proteção assume que o kernel é confiável — quando o kernel é comprometido via BYOVD, PPL não ajuda.
Driver blocklists são igualmente limitados. Eles bloqueiam drivers conhecidos após a vulnerabilidade ser descoberta e divulgada. Mas entre a descoberta da vulnerabilidade e a atualização do blocklist, há uma janela de exposição. E um zero-day sem CVE — como o ktapi.sys da Kontron — não está em nenhuma lista. A defesa não pode depender de conhecer todas as ameaças.
Defesa em camadas: HVCI, WDAC, canaries e IR offline
A defesa contra BYOVD é em camadas porque nenhuma camada única é suficiente. HVCI (Hypervisor-Protected Code Integrity) opera em Ring -1, abaixo do kernel, e bloqueia violações W^X no nível do hypervisor. Mesmo que um driver vulnerável obtenha acesso à memória kernel, o hypervisor impede a execução de código não assinado.
WDAC (Windows Defender Application Control) com allowlisting de drivers é proativo: apenas drivers explicitamente aprovados carregam no kernel. Blocklist é reativo; allowlisting é preventivo. Quando um novo driver vulnerável aparece, ele já está bloqueado por padrão.
Monitore kernel callbacks para detectar tampering e implante EDR canaries como tripwires. Se o callback que monitora os canaries desaparecer, você sabe que houve manipulação. E assuma cegueira do EDR: mantenha IR offline e teste cópias de segurança regularmente. Quando o encryptor está rodando e o EDR está cego, a cópia de segurança testada é a última linha de defesa.
Na Tech86, o SOC 24/7 humano sobrevive ao tampering com threat hunting proativo. Red Team simula o kill-chain completo do BYOVD — do acesso inicial via infostealer até o encryptor. IAM e Zero Trust reduzem o credential theft que dá ao atacante o acesso inicial necessário para carregar o driver.
Conclusão: o dashboard verde não significa seguro
O dashboard verde não significa seguro. Significa que você pode ter parado de ver. Quando o EDR é silenciado via BYOVD, a ausência de alertas é o sintoma mais perigoso — não a evidência de um ambiente saudável.
Nós repetimos: assuma que o EDR pode ser cego. HVCI, WDAC, kernel callbacks, EDR canaries, IR offline, cópias de segurança testadas, IAM e Zero Trust — cada camada existe porque a anterior pode falhar. Na Tech86, nós ajudamos empresas a construir defesa em camadas que sobrevive ao tampering — porque o dashboard verde é a mentira mais cara da segurança.