A técnica leva código ao modo núcleo para encerrar processos de segurança, interferir em callbacks e abrir caminho para ransomware antes da criptografia.
| Componente | Ferramentas de desativação de EDR que abusam de drivers legítimos, assinados e vulneráveis no Windows. |
| Vetor | Uso de BYOVD para carregar um driver confiável com falha conhecida e obter privilégios de modo núcleo quando a cadeia já possui capacidade de execução no endpoint. |
| Impacto | Encerramento de processos de EDR, desativação de ferramentas de segurança, adulteração de callbacks do núcleo e redução da visibilidade antes da execução de ransomware. |
| Prioridade | Bloquear drivers vulneráveis comumente abusados, monitorar carregamento anômalo de drivers e detectar tentativas tardias de neutralização de controles. |
| Artefatos | Foram observadas 54 ferramentas usando BYOVD contra 35 drivers vulneráveis; outras classes incluem utilitários anti-rootkit, scripts administrativos e ferramentas sem driver como EDRSilencer e EDR-Freeze. |
Uma análise sobre ferramentas conhecidas como EDR killers identificou que 54 delas usam a técnica BYOVD, abreviação de bring your own vulnerable driver, explorando um conjunto de 35 drivers assinados e vulneráveis. O objetivo operacional é levar código ou controle para uma camada de privilégio superior no Windows, usando a confiança concedida a drivers legítimos para interferir em componentes de segurança que normalmente resistem a encerramento simples por processos de usuário.
Esse tipo de ferramenta aparece com frequência em intrusões de ransomware porque separa a evasão defensiva do binário responsável pela criptografia. Em vez de embutir técnicas sofisticadas de neutralização de EDR no próprio encryptor, o operador executa um componente externo pouco antes da fase de impacto. Essa divisão deixa o malware de criptografia mais simples e facilita a criação de novas compilações, enquanto a lógica de evasão fica concentrada em utilitários especializados.
O abuso de BYOVD é particularmente relevante porque não depende de carregar um driver malicioso sem assinatura. A cadeia leva ao ambiente um driver assinado por fornecedor legítimo, mas que contém uma vulnerabilidade conhecida. Depois que esse driver é aceito pelo sistema, a falha nele pode ser usada para alcançar privilégios de modo núcleo, também chamados de Ring 0. Nesse nível, a ferramenta passa a ter condições de interagir com memória, processos protegidos e mecanismos internos de fiscalização do sistema operacional.
A execução típica pressupõe que o invasor já conseguiu presença suficiente no endpoint para introduzir e acionar a ferramenta de desativação. O BYOVD não substitui o acesso inicial; ele atua em uma etapa posterior da cadeia, quando o operador tenta reduzir a capacidade de detecção antes de executar a carga de ransomware. A ferramenta carrega ou aciona o driver vulnerável assinado, explora a condição insegura disponível nesse componente e usa o novo nível de privilégio para manipular processos e serviços de segurança.
Com acesso ao modo núcleo, a ferramenta pode encerrar processos de EDR, desabilitar controles, interferir em callbacks do núcleo e enfraquecer proteções que dependem de observação contínua no endpoint. O resultado técnico não é necessariamente exploração remota ou vazamento de dados por si só; o impacto confirmado é a neutralização de defesas locais, com aumento do risco de que uma etapa posterior, como criptografia em massa de arquivos, ocorra com menos bloqueios e menos telemetria em tempo real.
A análise também descreve ferramentas baseadas em scripts que interferem em processos e serviços de segurança por meio de comandos administrativos nativos do Windows. Como esses artefatos dependem de capacidades já presentes no sistema, eles podem ser usados em ambientes onde a execução de binários adicionais é mais vigiada. Alguns variantes combinam esse comportamento com modo de segurança do Windows, em que apenas um subconjunto mínimo do sistema operacional é carregado e soluções de segurança podem ficar fora da inicialização. Essa técnica é ruidosa porque envolve reinicialização e tende a ser menos confiável em ambientes desconhecidos.
Outra classe envolve utilitários anti-rootkit legítimos, como GMER, HRSword e PC Hunter, que oferecem interface para encerrar processos ou serviços protegidos. Há ainda uma categoria emergente sem driver, exemplificada por EDRSilencer e EDR-Freeze, cujo foco não é carregar um componente vulnerável no núcleo, mas bloquear tráfego de saída de soluções EDR e colocá-las em um estado de inoperância funcional. Esses caminhos têm mecanismos diferentes, mas convergem no mesmo objetivo: reduzir a capacidade do endpoint de observar, reportar ou bloquear a etapa final do ataque.
A superfície afetada é composta por endpoints Windows que permitem o carregamento de drivers vulneráveis assinados ou que não aplicam bloqueios efetivos contra drivers já conhecidos por abuso. A confiança do sistema em assinaturas legítimas cria uma zona sensível: o driver não precisa ser malicioso em sua origem para se tornar instrumento de ataque quando contém uma falha explorável e é levado ao ambiente por um operador com privilégios suficientes.
O risco se concentra em estáções e servidores onde agentes EDR, antivírus e controles de proteção de endpoint podem ser interrompidos localmente. Ambientes com ransomware-as-a-service são especialmente expostos a esse padrão porque afiliados podem usar ferramentas prontas ou comercializadas em mercados clandestinos, sem alterar o encryptor principal. O contexto também cita grupos fechados de ransomware, operadores que adaptam provas de conceito existentes, como SmilingKiller e TfSysMon-Killer, e vendedores de ferramentas como DemoKiller, ABYSSWORKER e CardSpaceKiller.
A presença de uma ferramenta desse tipo no host indica uma fase avançada de intrusão. Como a execução ocorre perto do momento da criptografia, a defesa não deve tratar o evento apenas como falha de hardening local. Ele precisa ser correlacionado com sinais anteriores de acesso, movimentação operacional, preparação de carga e tentativa de redução de visibilidade.
- Endpoints Windows capazes de carregar drivers assinados vulneráveis usados em BYOVD.
- Agentes EDR e serviços de segurança que podem ser encerrados, desabilitados ou isolados da comunicação externa.
- Ambientes com risco de ransomware em fase final, especialmente quando a execução de encryptor vem depois da neutralização de controles.
- Hosts nos quais utilitários anti-rootkit legítimos aparecem fora de fluxo administrativo autorizado.
A caça deve começar pelo carregamento de drivers incomuns, especialmente quando um driver legítimo aparece em caminho atípico, em horário incompatível com manutenção ou logo antes de falhas em serviços de segurança. O valor defensivo está em relacionar eventos do núcleo, criação de serviços, alteração de estado de processos protegidos e queda de comunicação do EDR. Um driver vulnerável isolado pode parecer apenas legado; o encadeamento com encerramento de agente, reinicialização incomum ou preparação de ransomware eleva a prioridade.
Em endpoint, procure sequências em que serviços de segurança param de responder, processos de EDR encerram de forma anormal ou módulos de proteção deixam de registrar eventos. Em rede, observe agentes que passam a perder comunicação de saída sem janela de manutenção ou sem falha ampla de conectividade. Para as variantes sem driver, a ausência repentina de telemetria de um conjunto pequeno de hosts pode ser tão importante quanto um alerta explícito de malware.
A telemetria de identidade e administração também importa. Ferramentas baseadas em scripts tendem a usar recursos administrativos locais para manipular serviços e processos, portanto eventos de criação de processo com privilégios elevados, alteração de serviços e reinicialização em modo de segurança devem ser correlacionados. O foco não é publicar comandos operacionais, mas identificar o efeito: parada de serviços críticos, remoção de componentes de proteção, mudança de inicialização e perda de visibilidade pouco antes de atividade destrutiva.
- Carregamento de drivers assinados fora do inventário aprovado ou a partir de diretórios temporários, de usuário ou de ferramentas.
- Interrupção súbita de processos, serviços ou callbacks associados a EDR e antivírus.
- Reinicialização inesperada seguida de redução de agentes de segurança carregados no sistema.
- Queda seletiva de comunicação de agentes EDR com servidores de gerenciamento.
- Execução não autorizada de GMER, HRSword, PC Hunter, EDRSilencer, EDR-Freeze ou artefatos com nomes relacionados às famílias citadas.
A mitigação principal é impedir que drivers vulneráveis conhecidos sejam carregados. Isso exige uma política de bloqueio mantida, revisão de drivers permitidos e validação de compatibilidade com hardware e softwares legítimos antes da implantação ampla. Como o abuso se apoia em componentes assinados, confiar apenas na assinatura do fornecedor não é suficiente; a decisão de permitir precisa considerar reputação, versão, histórico de vulnerabilidade e necessidade operacional no ambiente.
A resposta a um alerta de EDR killer deve assumir intrusão em andamento, não apenas tentativa de evasão isolada. O host precisa ser contido de forma que preserve evidência, e a investigação deve retroceder para identificar como o operador obteve execução. Também é necessário verificar se houve preparação de ransomware, alteração de políticas locais, criação de serviços, uso de ferramentas administrativas e perda de telemetria em outros ativos. Quando a ferramenta é executada no estágio final, bloquear apenas aquele binário pode levar o operador a substituir o componente por outro equivalente.
Defesas em camadas são necessárias porque a falha em uma etapa pode permitir troca rápida de ferramenta. Bloqueio de drivers, controle de execução, privilégio mínimo, proteção contra adulteração de agentes, detecção de anomalias em serviços e correlação com identidade reduzem a janela de ação. Depois da contenção, a equipe deve validar se o EDR voltou a operar, se os callbacks e serviços de proteção foram restaurados e se não há drivers vulneráveis persistidos para uso posterior.
- Aplicar bloqueio de drivers vulneráveis conhecidos e revisar exceções de compatibilidade.
- Monitorar carregamento de drivers assinados que não pertencem ao inventário aprovado.
- Ativar e validar recursos de proteção contra adulteração dos agentes de segurança.
- Correlacionar eventos de parada de EDR com criação de serviços, reinicialização e execução elevada.
- Conter hosts afetados e investigar etapas anteriores da intrusão antes de restaurar a operação normal.
- Revisar a comunicação dos agentes de segurança para detectar bloqueio seletivo de saída.
0 Comentários