Introdução, quando o defensor vira a arma

A Check Point Research documentou um cenário que devia tirar o sono de qualquer time de segurança: um driver assinado pela própria Microsoft, parte integrante do Microsoft Defender, pode ser instrumentado para remover arquivos e chaves de registro de outros produtos de segurança, antes mesmo de o Windows terminar de inicializar.

Vale destacar de imediato o que isso não é. Não é uma vulnerabilidade de memória corrompida, não é um driver de terceiros mal escrito, não é uma falha de assinatura digital contornada. É abuso de design. O driver funciona exatamente como projetado, exposto a chamadas exatamente como documentado, só que fora do contexto para o qual foi concebido, e sem verificação suficiente de quem está do outro lado da chamada.

Neste post, vamos cobrir a mecânica da técnica, por que ela representa uma evolução em relação ao clássico BYOVD, o que isso significa para a superfície de ataque de qualquer endpoint Windows, e como times de detecção e resposta devem reagir a essa classe de problema.

O que é o BTR.sys (Boot Time Removal Tool)

BTR.sys é a Boot Time Removal Tool, um driver de kernel que faz parte do arsenal do Microsoft Defender. Sua função original é remediar malware persistente que resiste à remoção em tempo de execução normal, rootkits, bootkits e ameaças que se ancoram em estágios muito baixos da cadeia de boot, antes que o sistema operacional e os mecanismos de proteção em user-mode estejam totalmente operacionais.

Para cumprir esse papel, o driver precisa de privilégios elevados: capacidade de manipular arquivos e chaves de registro em nível de kernel, agindo em uma janela do boot onde a maioria das proteções do SO ainda não subiu. É uma ferramenta de remediação de última instância, pensada para operar num momento em que praticamente nada mais consegue.

E, como faz parte do Microsoft Defender, o driver carrega uma assinatura da Microsoft. Isso significa que ele passa sem atrito por qualquer mecanismo de verificação de integridade de driver, por políticas de Driver Signature Enforcement, e por qualquer heurística que trate “driver assinado pela Microsoft” como sinônimo de “confiável”. Essa confiança implícita é exatamente o que torna o abuso possível.

A Mecânica da Técnica de Abuso

Como um processo em user-mode instrumenta o driver

O driver expõe uma interface de IOCTLs que um processo em user-mode pode chamar para solicitar operações de remoção, arquivos e entradas de registro apontados como alvo são removidos com privilégios de kernel. O problema é que essa interface não distingue adequadamente entre um chamador legítimo, operando dentro do fluxo de remediação para o qual o driver foi desenhado, e um processo arbitrário que simplesmente sabe como formatar a chamada certa.

Na prática, isso permite que um agente com privilégios suficientes para carregar/acionar o driver direcione operações de exclusão contra arquivos e chaves de registro de qualquer produto instalado no sistema, incluindo, claro, soluções concorrentes de EDR e antivírus. A operação acontece no estágio de boot, aproveitando exatamente a janela de privilégio elevado e visibilidade reduzida para a qual o BTR.sys foi originalmente projetado.

A Check Point Research reportou que a técnica afeta um escopo amplo de versões do Windows, do Windows 7 até o Windows 11 25H2, o que dá a dimensão da superfície exposta: não é uma falha pontual em uma build recente, é um comportamento presente ao longo de gerações do sistema operacional.

Por que nenhuma CVE foi necessária

Esse ponto merece ênfase porque muda o modelo mental de resposta. Não há exploit de memória envolvido, não há necessidade de trazer um driver vulnerável externo para o sistema (o padrão clássico de BYOVD), não há sequer um bug de lógica no sentido tradicional. O driver faz o que sempre fez. A “vulnerabilidade”, entre aspas, é o gap entre o contexto de uso pretendido, remediação controlada, disparada pelo próprio Defender em condições específicas, e o contexto de uso possível, que é qualquer chamador capaz de invocar a interface exposta.

Isso é relevante para quem espera que esse tipo de achado gere um patch e resolva o problema em um ciclo de atualização. A natureza do achado é estrutural, não pontual.

Leia também: Firmware Security: Revelando Vulnerabilidades Ocultas e Fortalecendo a Segurança, para entender como camadas de confiança abaixo do sistema operacional seguem sendo um ponto cego recorrente em arquiteturas de segurança.

BTR.sys vs. BYOVD Clássico, uma evolução mais perigosa

BYOVD (Bring Your Own Vulnerable Driver) é uma técnica já bem mapeada pela indústria: o atacante traz consigo um driver de terceiros, legitimamente assinado mas com uma vulnerabilidade conhecida, e o carrega no sistema-alvo para obter execução em kernel. A defesa padrão para isso existe e é razoavelmente madura, listas de bloqueio de drivers vulneráveis (driver blocklist), Hypervisor-protected Code Integrity (HVCI) e mecanismos de allowlisting que impedem o carregamento desses binários específicos.

O caso do BTR.sys quebra esse modelo de defesa por um motivo simples: não há driver externo para bloquear. O binário já está presente, por padrão, em praticamente todo endpoint Windows com Microsoft Defender ativo, que é a esmagadora maioria do parque instalado no planeta. Não existe lista de bloqueio capaz de vetar um componente nativo do próprio produto de segurança do sistema operacional sem quebrar a funcionalidade legítima que ele entrega.

Isso força uma mudança de cálculo para quem constrói e opera soluções de EDR. A pergunta não é mais “como impeço que um driver malicioso seja carregado”, mas “como distingo uma chamada legítima de remediação de uma chamada abusiva a um driver que já está lá, assinado, confiável e ativo por design”.

Por que Isso Importa Agora

A ascensão das táticas EDR-killer

Técnicas de “security software tampering”, desabilitar, cegar ou remover agentes de detecção antes de avançar no ataque, deixaram de ser um detalhe operacional e se tornaram pré-requisito comum em cadeias de ataque modernas, particularmente em operações de ransomware. Neutralizar a telemetria de segurança antes da fase de impacto reduz drasticamente a janela de detecção e resposta, e operadores têm investido tempo de engenharia especificamente nisso.

Um driver nativo do sistema operacional, assinado pela Microsoft, capaz de apagar artefatos de outros produtos de segurança em estágio de boot, é exatamente o tipo de primitivo que se encaixa nesse objetivo. Ele não precisa ser “descoberto” como uma vulnerabilidade de dia zero tradicional para ser valioso, precisa apenas ser conhecido e reutilizado.

Leia também: DeepBlueMagic: uma nova cepa de ransomware, um exemplo de grupo que já demonstrou foco deliberado em desabilitar proteções antes de executar sua carga útil, ilustrando por que esse tipo de primitivo tem valor prático imediato para operadores de ransomware.