Driver legítimo do Microsoft Defender pode ser transformado em arma contra EDR e antivírus
Pesquisadores da Check Point Research demonstraram uma técnica capaz de transformar um componente legítimo e assinado do Microsoft Defender em uma ferramenta para executar operações privilegiadas no kernel do Windows e, potencialmente, neutralizar soluções de Endpoint Detection and Response (EDR) e antivírus.
A descoberta envolve o BTR.sys (Boot-Time Removal Tool), driver utilizado pelo Microsoft Defender durante processos de remediação que precisam ocorrer durante a inicialização do Windows.
O aspecto mais relevante da pesquisa é que não estamos diante de uma vulnerabilidade convencional. Não é necessário explorar corrupção de memória, executar um exploit contra uma CVE ou introduzir um driver vulnerável de terceiros.
O próprio componente confiável da Microsoft pode ser reutilizado de maneira ofensiva.
O que é o BTR.sys?
O BTR.sys faz parte da infraestrutura de remediação do Microsoft Defender e está incorporado ao MpEngine.dll.
Quando o Defender precisa executar determinadas ações que não podem ser concluídas enquanto o Windows está funcionando normalmente — como remover arquivos bloqueados — o driver é extraído, gravado temporariamente no sistema e configurado para executar durante a inicialização.
Segundo a Check Point Research, o BTR.sys funciona como um driver do tipo one-shot: ele é carregado, processa uma lista de operações, registra o resultado e solicita seu próprio descarregamento.
Durante uma investigação de resposta a incidentes, os pesquisadores observaram um comportamento que inicialmente parecia atividade maliciosa:
- driver com nome aleatório;
- criação de serviço temporário;
- utilização de criptografia RC4;
- configuração armazenada em Alternate Data Stream (ADS);
- execução privilegiada;
- mecanismos automáticos de limpeza.
A análise revelou, porém, que esse comportamento fazia parte do funcionamento legítimo do Microsoft Defender. Foi justamente essa descoberta que levou os pesquisadores a realizar engenharia reversa completa do mecanismo.
De mecanismo defensivo a primitive de kernel
A engenharia reversa mostrou que o BTR.sys recebe uma estrutura contendo instruções que determinam as operações que devem ser executadas.
Essa configuração utiliza dados criptografados com RC4 e verificações de integridade baseadas em CRC-32 modificado.
Uma vez compreendido o protocolo, os pesquisadores conseguiram criar transações aceitas pelo driver.
O resultado é particularmente relevante porque o BTR.sys opera em Ring 0, o nível de privilégio do kernel do Windows.
Entre as operações identificadas estão:
- exclusão de arquivos;
- exclusão de diretórios;
- movimentação de arquivos;
- exclusão de chaves do Registro;
- exclusão de valores do Registro;
- criação ou alteração de valores do Registro.
Isso transforma um componente criado originalmente para remover malware em uma espécie de mecanismo genérico para realizar operações privilegiadas no sistema.
BTR_CLI demonstra a possibilidade de weaponization
Para validar a descoberta, os pesquisadores desenvolveram uma Proof of Concept (PoC) denominada BTR_CLI.
A ferramenta reproduz o protocolo utilizado pelo Defender e demonstra que é possível instruir o BTR.sys a executar operações privilegiadas.
Os testes realizados pela Check Point abrangeram versões do Windows desde o Windows 7 Build 7601 até o Windows 11 25H2 totalmente atualizado, considerando o ambiente disponível em julho de 2026.
Um aspecto especialmente relevante é a longevidade do mecanismo. Os pesquisadores analisaram 18 versões distintas e assinadas pela Microsoft do BTR.sys e verificaram que a estrutura de transações permaneceu compatível entre elas.
Por que isso é diferente de um ataque BYOVD?
Ataques conhecidos como Bring Your Own Vulnerable Driver (BYOVD) normalmente dependem da introdução de um driver legítimo, porém vulnerável, no sistema comprometido.
O atacante explora as funcionalidades ou vulnerabilidades desse driver para obter acesso ao kernel, desativar mecanismos de segurança ou realizar outras operações privilegiadas.
Essa técnica já é conhecida em operações de ransomware e pós-exploração.
No caso do BTR.sys existe uma diferença importante:
o atacante não precisa necessariamente trazer um driver vulnerável de terceiros.
O BTR.sys é:
- componente do Microsoft Defender;
- assinado pela Microsoft;
- destinado legitimamente a operações privilegiadas;
- incorporado ao mecanismo antimalware;
- autorizado a operar no kernel.
Por isso, a Check Point classifica a técnica como utilização de um Living-off-the-Land Driver (LOLDriver), e não simplesmente como BYOVD tradicional.
Essa distinção é importante para defesa: bloquear apenas drivers conhecidos como vulneráveis não resolve completamente o problema.
A “Golden Window” durante o boot do Windows
Um dos pontos mais interessantes da pesquisa é o que os pesquisadores chamaram de Golden Window.
O BTR.sys precisa acessar o sistema de arquivos para executar suas operações. Por isso, ele não funciona como um driver Boot Start (Start=0), mas pode operar como System Start (Start=1).
Quando associado ao grupo de carregamento Boot Bus Extender, o driver consegue executar muito cedo no processo de inicialização.
Nesse momento:
o kernel e o sistema de arquivos já estão operacionais, mas diversos componentes das soluções de segurança ainda não foram completamente inicializados.
Nos testes realizados em Windows 11 25H2, o BTR.sys executou suas operações antes da inicialização do principal serviço do Microsoft Defender (MsMpEng.exe).
A Check Point denominou esse intervalo de Golden Window, porque cria uma janela temporal na qual operações privilegiadas podem ocorrer antes que toda a inteligência e os mecanismos de proteção em user mode estejam disponíveis.
Impacto sobre EDR e antivírus
A pesquisa demonstrou que o mecanismo pode ser utilizado para interferir na própria infraestrutura de segurança.
Nos testes controlados, os pesquisadores demonstraram capacidade para manipular componentes e configurações associados ao Microsoft Defender antes que determinados serviços fossem inicializados.
Também foi demonstrada a possibilidade de modificar chaves críticas do Registro a partir do kernel.
Isso cria um cenário particularmente preocupante para soluções EDR.
Se um atacante já obteve privilégios administrativos suficientes e consegue carregar o driver, ele pode potencialmente utilizar um componente confiável para interferir nos mecanismos que deveriam detectar suas próximas ações.
Em termos de cadeia de ataque:
Comprometimento → privilégio administrativo → abuso do BTR.sys → neutralização de controles → redução da visibilidade → pós-exploração
É importante, entretanto, não interpretar a pesquisa como uma forma de comprometimento inicial. O abuso descrito pressupõe que o atacante já possua privilégios elevados, especificamente capacidade associada ao SeLoadDriverPrivilege.
Assinatura digital não significa comportamento confiável
A pesquisa também evidencia uma questão arquitetural importante para estratégias modernas de segurança:
Confiar apenas na assinatura digital de um executável ou driver não é suficiente para determinar se sua utilização é legítima.
O BTR.sys é assinado pela própria Microsoft.
Portanto, controles baseados exclusivamente em reputação, hash ou assinatura podem não distinguir uma operação legítima do Defender de uma utilização ofensiva do mesmo componente.
É uma extensão do conceito de Living off the Land (LotL): componentes legítimos do sistema podem ser utilizados fora de seu contexto operacional esperado.
Nesse cenário, a pergunta deixa de ser apenas:
“O driver é confiável?”
e passa a incluir:
“Quem carregou esse driver, em qual contexto, com qual sequência de eventos e o que aconteceu depois?”
Detecção: comportamento e contexto tornam-se essenciais
A Check Point propõe que a detecção seja baseada principalmente em contexto comportamental.
Entre os eventos particularmente úteis estão os registros do Sysmon.
Sysmon Event ID 15 — FileCreateStreamHash
O BTR.sys utiliza um Alternate Data Stream denominado :changelist para armazenar sua configuração.
A criação de um ADS associado a um arquivo .sys pode, portanto, constituir um importante sinal para investigação.
Sysmon Event ID 6 — DriverLoad
Permite acompanhar o carregamento de drivers.
O ponto crítico não é simplesmente detectar um driver assinado pela Microsoft, mas verificar sua origem e linhagem de execução.
Um BTR.sys iniciado pelo ecossistema normal do Defender pode representar atividade legítima.
O mesmo componente sendo preparado por PowerShell, shell de comando ou executável desconhecido exige investigação.
Sysmon Event IDs 12 e 13 — RegistryEvent
A criação de chaves de serviço com características relacionadas ao BTR.sys pode fornecer outro indicador comportamental.
A ausência de um evento normal de instalação de serviço também pode ser relevante quando correlacionada aos demais eventos.
Sysmon Event IDs 11 e 23 — criação e exclusão de arquivos
A criação e rápida remoção do arquivo BootClean.log, combinada com carregamento do driver e operações executadas pelo processo System, pode contribuir para uma regra de detecção de maior fidelidade.
Microsoft não classificou o caso para correção imediata
Segundo a Check Point Research, o caso foi comunicado ao Microsoft Security Response Center (MSRC).
A Microsoft concluiu que a técnica não atende aos critérios para correção imediata porque sua exploração pressupõe privilégios administrativos preexistentes, especificamente a capacidade de carregar drivers.
Essa classificação é tecnicamente importante.
O problema não deve ser tratado simplesmente como uma “nova vulnerabilidade crítica do Microsoft Defender”.
A pesquisa descreve principalmente abuso de funcionalidade legítima e de uma fronteira de confiança arquitetural, e não uma vulnerabilidade convencional que permita a um usuário sem privilégios comprometer o kernel.
Há ataques utilizando a técnica?
Até a publicação da pesquisa, não havia evidência identificada pela Check Point de utilização do BTR.sys dessa maneira em ataques reais.
Isso também precisa ser destacado.
A técnica foi demonstrada experimentalmente e uma PoC foi desenvolvida, mas isso não significa que grupos de ransomware ou outros atores de ameaça já estejam explorando o mecanismo.
Por outro lado, a divulgação pública da pesquisa aumenta a relevância de implementar mecanismos preventivos de detecção antes que técnicas semelhantes apareçam em campanhas reais.
Recomendações para organizações
A principal lição não é simplesmente tentar bloquear o BTR.sys — ele possui função legítima dentro do Windows Defender.
A estratégia mais adequada é aplicar defesa em profundidade, com foco no contexto de utilização de componentes privilegiados.
Entre as medidas recomendadas estão:
- aplicar rigorosamente o princípio do menor privilégio;
- restringir e monitorar o
SeLoadDriverPrivilege; - monitorar carregamento de drivers, inclusive aqueles assinados por fornecedores confiáveis;
- coletar eventos do Sysmon relacionados a DriverLoad, RegistryEvent e Alternate Data Streams;
- detectar drivers de segurança executados fora de sua linhagem normal;
- correlacionar eventos de driver com alterações posteriores em arquivos e configurações de segurança;
- monitorar alterações de serviços e componentes durante o processo de boot;
- utilizar políticas de Application Control quando aplicável;
- incorporar técnicas de LOLBins e LOLDrivers às estratégias de Threat Hunting;
- evitar utilizar assinatura digital isoladamente como indicador de legitimidade.
Uma mudança importante no modelo de confiança
A pesquisa sobre o BTR.sys demonstra um problema mais amplo para arquiteturas modernas de segurança.
Durante anos, uma das principais premissas de segurança do Windows foi distinguir código confiável de código não confiável por meio de mecanismos como assinatura digital, reputação e controle de drivers.
O problema é que atacantes modernos nem sempre precisam executar componentes maliciosos.
Eles podem procurar maneiras de utilizar componentes legítimos de forma maliciosa.
Nesse cenário, confiança precisa ser determinada não apenas pela identidade do software, mas também pelo seu comportamento, contexto, origem da execução e sequência de eventos.
Para SOCs e equipes de Blue Team, a conclusão é especialmente relevante: um binário assinado pode ser legítimo; sua utilização pode não ser.
Referências
Check Point Research — pesquisa original
BTR Reforged: Weaponizing Defender’s Remediation Driver as a Kernel Operation Primitive — Jiří Vinopal, 20 de agosto de 2026.
Acessar pesquisa da Check Point Research
Cybersecurity News
Microsoft Defender Driver Can Be Weaponized to Disable EDR and AV From Windows Kernel — 20 de agosto de 2026.
Acessar matéria do Cybersecurity News
Check Point Research — Black Hat USA 2026
Resumo da apresentação BTR Reforged: The Driver Nobody Had Looked At, apresentada durante a Black Hat USA 2026.
Acessar cobertura da Black Hat 2026
Microsoft — contexto sobre BYOVD e proteção de drivers
A documentação técnica da Microsoft descreve ataques BYOVD como cenários em que adversários com privilégios administrativos utilizam drivers legitimamente assinados para obter capacidade privilegiada e interferir em processos de segurança.
Contexto histórico — BTR.sys
O BTR.sys já havia sido objeto de pesquisa de segurança anteriormente. Em 2021 foi divulgada uma vulnerabilidade diferente no mesmo componente, CVE-2021-24092, corrigida pela Microsoft. Esse caso anterior não deve ser confundido com a técnica BTR Reforged apresentada em 2026.
Clique e fale com representante oficial Netwrix Endpoint Protector
Veja também:
- Shadow AI: 47% do uso corporativo de IA ocorre em contas pessoais
- Cibersegurança: 95% das equipes enfrentam lacunas de habilidades
- Credenciais móveis avançam como pilar da segurança bancária
- Ransomware mira backups em 96% dos ataques
- Criminosos criam marketplace de dados pessoais para aplicar golpes na internet
- Violações de dados mais que dobram com avanço dos agentes de IA
- CertiK Intel3D – A Era das PSAVs e o Novo Padrão de Segurança do Brasil
- América Latina é a segunda região mais exposta a ciberameaças industriais
- IA amplia desafio de segurança e governança nas redes corporativas
- Falsas promessas de emprego na Meta, Disney, Coca-Cola e Spotify
- Sem guardrails, a autonomia da IA se torna um risco
- IA eleva taxa de sucesso de phishing para 54%
Be the first to comment