O EDR killer que aproveita um driver antigo e expõe a ameaça BYOVD no Windows

Uma pesquisa recente de Huntress revelou uma manobra que soa a déjà vu para qualquer pessoa que siga a segurança no Windows, mas que ainda funciona no mundo real: atores maliciosos aproveitaram um antigo driver legítimo de EnCase para criar um “EDR killer” capaz de identificar e apagar dezenas de ferramentas de segurança em equipamentos infectados.

Antes de entrar em detalhes, convém lembrar o que é um EDR killer. Trata-se de um programa malicioso concebido especificamente para desativar ou contornar soluções de resposta e detecção em endpoints. Eles costumam operar com privilégios de kernel porque, daí, podem desenganhar mecanismos de proteção e terminar processos de segurança que em modo usuário seriam inacessíveis. Neste caso concreto os investigadores Huntress viram como a peça maliciosa se disfarçava como uma utilidade de atualização de firmware e carregou um driver antigo chamado EnPortv.sys, pertencente a EnCase (produto de pesquisa forense agora em OpenText).

A técnica empregada não é nova e tem nome: “Bring Your Own Vulnerable Driver” ou BYOVD. Em vez de procurar um exploit no kernel atual, os atacantes introduzem um driver assinado legitimamente, mas vulnerável – ou com funcionalidades que permitem abuso – e o usam para executar operações em modo kernel. Grupos e amostras de malware exploraram BYOVD de forma recorrente; assinaturas antigas, comportamentos de assinatura de drivers e exceções nas políticas da Microsoft fizeram com que essa abordagem continue a ser eficaz. Para entender a técnica com mais profundidade vale a pena ler análise e peças de contexto sobre BYOVD, como o artigo do ESET sobre o tema aqui.

Na intrusão descrita por Huntress, o acesso inicial foi obtido mediante credenciais comprometidas de um SSL VPN da SonicWall, e a conta não tinha ativado autenticação multifator. Após o acesso dos atacantes, realizaram um reconhecimento interno intenso —pings ICMP, sondagens NetBIOS, atividade SMB e rajadas TCP de tipo SYN — e, segundo os pesquisadores, o ator provavelmente pretendia implantar ransomware embora a campanha tenha sido interrompida antes de soltar a carga final. O caso destaca uma verdade operacional: a ausência de MFA e a supervisão deficiente de registros de VPN são portas de entrada habituais para intrusos. A Microsoft tem documentado repetidamente a eficácia de MFA para reduzir compromissos; por exemplo, seu blog de segurança descreve como MFA bloqueia a grande maioria das tentativas de tomada de contas aqui.

O vetor técnico central foi o driver EnPortv.sys, um componente de EnCase. Embora o seu certificado digital tenha sido emitido em 2006, expirou em 2010 e foi revogado, o Windows continuava a permitir a sua carga por um detalhe de implementação do mecanismo de assinatura de drivers: a verificação baseia-se na verificação criptográfica e em selos de tempo, não numa consulta em tempo real a listas de revogação (CRL) para todos os casos, e existe também uma exceção que aplica a certificados emitidos antes de 29 de julho de 2015. Essa exceção, junto às diferentes políticas históricas de assinatura, abriu a porta para que o driver pudesse se instalar e se registrar como um serviço de hardware OEM falso, conseguindo persistência resistente a reinícios.

Uma vez no kernel, o malware usou a interface IOCTL do driver para ordenar ao sistema que terminasse processos de serviços de segurança, medindo proteções como Protected Process Light (PPL). Segundo Huntress a amostra vem com uma lista de 59 processos-alvo - entre agentes EDR e antivírus - e executa um ciclo de terminação cada segundo, de forma que se um processo protegido se reinicia, o killer o mata de novo instantaneamente. Essa combinação de persistência em nível kernel e a capacidade de manipular processos do sistema é o que a torna uma ameaça crítica para ambientes com controles concentrados em EDR tradicionais.

Se você quer ler a análise técnica, o relatório de Huntress descreve o fluxo completo, indicadores e mecanismos de persistência aqui. A nota pública de imprensa e coberturas adicionais, como a de BleepingComputer, ajudam a colocar o incidente no panorama mais amplo de abusos de drivers assinados.

O que pode fazer uma equipe de segurança para reduzir esse tipo de risco? Primeiro, há que atacar a causa mais direta do acesso: as contas de acesso remoto. Activar o MFA em todos os acessos remotos, monitorar logs de VPN e limitar privilégios de contas são passos que costumam parar o avanço inicial dessas campanhas. Em segundo lugar, é conveniente aproveitar as mitigações que a Microsoft oferece para drivers e isolamento do kernel: habilitar HVCI/Memory Integrity (parte da "core isolation" no Windows) ajuda a aplicar a lista de drivers vulneráveis bloqueados pela Microsoft; a documentação técnica de Virtualization-based Security e HVCI oferece contexto sobre como este isolamento funciona. aqui e o guia Microsoft sobre Windows Defender Application Control (WDAC) explica como controlar quais binários e drivers são permitidos em uma frota aqui.

Além de HVCI e WDAC, existem regras e controles nas soluções de segurança modernas pensadas para reduzir a exposição a drivers assinados que foram revogados ou que funcionam de forma maliciosa. Implementar regras de Attack Surface Reduction (ASR), monitorar a criação de serviços kernel que se façam passar por OEM/hardware e bloquear assinaturas conhecidas problemáticas São medidas que Huntress também recomenda. A documentação da ASR na Microsoft Defender for Endpoint é um bom ponto de partida para equipamentos que gerem ambientes Windows aqui.

Não é apenas uma questão de tecnologia: a detecção precoce de movimentos horizontais e inteligência sobre atividade incomum na rede interna são críticas. No caso analisado, os intrusos realizaram barridos ICMP, sondagens NetBIOS e tráfego SMB ruídos; monitorar esses padrões e alertar sobre rajadas anómalas – como altas taxas de SYN – pode interromper uma operação antes de o ator implantar suas ferramentas de persistência. Além disso, é importante preparar respostas que incluam isolamento de segmentos afetados e revisão forense de credenciais expostas.

Para equipamentos que gerem soluções forenses ou que usam ferramentas de terceiros assinadas há anos, convém rever inventário e telemetria: Quais drivers com assinaturas antigas estão implantados no seu parque? Aparecem drivers instalados que se registram como componentes OEM e não coincidem com hardware real? Bloquear e revisar drivers assinados com certificados emitidos há muito tempo ou revogados reduz a superfície para ataques BYOVD. A política de assinaturas da Microsoft para drivers no modo kernel e as excepções históricas estão documentadas na documentação para desenvolvedores e assinaturas de drivers; ler essa regulamentação ajuda a entender por que antigos certificados ainda são aceitos por algumas versões do Windows aqui.

Este incidente volta a colocar sobre a mesa uma lição importante: as defesas modernas requerem camadas. Confiar apenas em um EDR sem controles de acesso fortes, sem isolamento de kernel e sem políticas que restrinjam drivers assinados não é suficiente. Um bom plano de defesa combina controles preventivos (MFA, políticas de assinatura e bloqueio de drivers), detecção (telemetria de rede e endpoints) e resposta (procedimentos para desacoplar, conter e analisar).

Se você gerencia infra-estruturas Windows, verifique primeiro as contas com acesso remoto e obriga MFA. Abaixo avalia a possibilidade de ativar HVCI/Memory Integrity, configurar WDAC/ASR segundo seu risco e auditar a presença de drivers historicamente assinados em seus equipamentos. Para detalhes técnicos e indicadores de compromisso do incidente, consulte o relatório de Huntress aqui e, para contexto sobre BYOVD, a pesquisa da ESET aqui.

A boa notícia é que as defesas existem e estão se fortalecendo. A má é que a compatibilidade histórica, o uso legítimo de ferramentas forenses ou de administração e a complexidade do ecossistema de drivers continuam a fornecer resquícios que os atacantes aproveitam. Ter uma política clara sobre drivers, supervisão ativa e controle de acesso robustos reduz significativamente a possibilidade de um ator tornar uma vulnerabilidade histórica num incidente devastador.