O driver legítimo de Remoção em Tempo de Boot (BTR.sys) do Microsoft Defender pode ser reaproveitado para realizar operações de arquivo e registro em nível de kernel poderosas, potencialmente permitindo que atacantes com privilégios administrativos neutralizem as proteções de segurança de endpoint.
Descoberta da Check Point Research
A pesquisa da Check Point não descreve uma vulnerabilidade convencional ou falha de corrupção de memória; em vez disso, expõe como um componente de remediação confiável e assinado pela Microsoft pode se tornar um driver Living-off-the-Land quando seu protocolo de transação não documentado é reproduzido. O BTR.sys está embutido no MpEngine.dll do Microsoft Defender e é implantado quando o Defender precisa completar uma tarefa de remediação após a reinicialização, como remover um arquivo bloqueado pelo sistema operacional.
Durante a atividade legítima, o driver pode aparecer com um nome de arquivo e nome de serviço gerados aleatoriamente, usar um Fluxo de Dados Alternativo (ADS) chamado :changelist para sua configuração criptografada, executar suas operações em fila e depois limpar. Esses comportamentos podem se assemelhar à técnica de carregador de kernel durante uma investigação de resposta a incidentes, apesar de fazer parte da arquitetura de remediação normal do Defender.
Protocolo de transação e janela dourada
De acordo com as descobertas de engenharia reversa compartilhadas pela Check Point Research, o formato de transação proprietário do driver depende de um blob de configuração criptografado RC4 protegido por verificações de integridade. A configuração pode conter instruções para excluir arquivos e diretórios, mover arquivos, excluir chaves e valores de registro e escrever dados de registro. Em efeito, uma transação válida pode direcionar um driver assinado da Microsoft para realizar operações privilegiadas do Ring 0.
A equipe de pesquisa criou o BTR_CLI, uma ferramenta de prova de conceito que constrói transações aceitas e prepara o driver para execução. A principal preocupação de segurança é o tempo. O BTR.sys opera como um driver de início de sistema em vez de um driver de início de boot porque precisa acessar o sistema de arquivos e os caminhos do Windows durante a inicialização.
Quando atribuído ao grupo de ordem de carregamento "Boot Bus Extender" inicial, ele pode ser executado após o sistema de arquivos estar disponível, mas antes que muitos componentes de segurança do modo de usuário sejam inicializados. Os pesquisadores chamam esse intervalo de "janela dourada", durante a qual o driver poderia remover binários de segurança ou modificar as configurações de registro de serviço relacionadas antes que a pilha de proteção completa de um antivírus ou produto EDR seja iniciada.
Impacto e detecção
Diferente dos ataques tradicionais de Bring Your Own Vulnerable Driver, esta abordagem não depende do carregamento de um driver de terceiros conhecido como vulnerável. O BTR.sys é um componente interno da Microsoft com uma assinatura válida, complicando os controles de segurança que tratam as assinaturas de driver como um sinal de confiança principal.
Os pesquisadores disseram que não encontraram evidências de abuso no mundo real no momento da análise, mas a publicação pública da metodologia torna a detecção proativa cada vez mais importante. Os defensores devem monitorar o contexto de implantação suspeito do BTR.sys em vez de confiar apenas em hashes de arquivo ou assinaturas da Microsoft.
O Sysmon Event ID 15, FileCreateStreamHash, registra a criação de fluxo de arquivo nomeado e pode ajudar a identificar atividade ADS anômala .sys:changelist. O Sysmon Event ID 6, DriverLoad, registra cargas de driver junto com detalhes de hash e assinatura, tornando-se útil para correlacionar atividade incomum de driver assinado com o processo que o implantou.
Recomendações para equipes de segurança
Sinais de alto valor incluem um driver de remediação do Defender escrito ou registrado por PowerShell, shells de comando, ferramentas não assinadas ou outros processos fora da linhagem normal do Defender; chaves de serviço aleatórias contendo um valor Args que referencia :changelist; e cargas de driver assinadas pela Microsoft seguidas pela exclusão de binários de segurança em nível de SYSTEM.
As equipes de segurança também devem investigar a criação e exclusão rápidas de BootClean.log, arquivos de feedback baseados em ADS anômalos em caminhos de driver e criação de serviço que carece de um registro de instalação esperado do Service Control Manager. As organizações devem controlar e auditar rigorosamente o SeLoadDriverPrivilege, coletar telemetria de carga de driver e ADS, impor políticas de controle de aplicação onde viável e construir detecções em torno da linhagem de execução, alterações de persistência no tempo de inicialização e operações suspeitas atribuídas ao processo System.