Evasão de EDR no SOC: Detecte Atacantes que Cegam Agentes

Evasão de EDR deixou de ser técnica de grupo avançado: virou commodity. Em 2026, ferramentas de “evasion-as-a-service” disponíveis no GitHub permitem que atacantes de baixa habilidade ceguem agentes de endpoint em minutos, abrindo caminho para roubo de credenciais, movimento lateral e ransomware. O SOC que trata silêncio de alertas como segurança está operando cego. Este artigo mapeia as três táticas de evasão que mais aparecem em resposta a incidentes e mostra como montar detecção que sobrevive quando o endpoint é burlado.

Por que seu EDR falha

A confiança cega no agente de endpoint é o erro mais caro que vejo em operação real. O relato de uma avaliação de red team da CISA é direto: a organização avaliada dependia demais de soluções baseadas em host e não implementou proteções suficientes na camada de rede. O EDR detectou apenas uma fração dos payloads do time vermelho nos ambientes Windows e Linux — e, quando bloqueou um payload de phishing inicial, gerou um alerta que ninguém leu nem respondeu.

O problema não é o EDR em si, que segue sendo primeira linha necessária. O problema é treat a única fonte de verdade como se fosse cobertura completa. Nem todo endpoint da empresa comporta agente — impressoras de rede, dispositivos IoT, appliances de borda e VPNs continuam como pontos cegos. Segundo o Verizon DBIR 2025, a exploração de dispositivos de borda e VPNs saltou de 3% para 22% como vetor de invasão em um ano, tornando-se o ponto de entrada que mais cresce.

Quando o atacante evita as APIs monitoradas, desabilita o serviço do agente ou carrega um driver assinado vulnerável para remover callbacks de kernel, o seu painel simplesmente para de gerar eventos. Silêncio vira a falsa sensação de ambiente limpo.

As três frentes de evasão

O fluxo de um EDR é linear: sensores observam a atividade do endpoint, enviam dados a um servidor e disparam alertas. Cada etapa desse fluxo é um ponto de ataque. A literatura operacional classifica a evasão em três frentes complementares:

Tática	O que o atacante faz	Sinal que o SOC deve caçar
Cegar (tampering)	Configura o EDR para ignorar pastas, evita APIs monitoradas, desabilita serviços do agente ou instala filtros customizados	Queda abrupta de volume de telemetria de um host; serviço do agente parado; driver assinado suspeito carregado (Sysmon EID 6)
Se misturar (blending)	Usa credenciais legítimas e técnicas de living-off-the-land (PowerShell, WMI, certutil) em vez de instalar malware reconhecido	Uso anômalo de LOLBins fora de horário padrão; execução encadeada atípica de ferramentas nativas
Se esconder (hiding)	Explora vulnerabilidades em dispositivos conectados onde o EDR não pode ser instalado e usa esses hosts como ponte	Tráfego lateral originado de dispositivo sem agente; beaconing para destinos incomuns vindo de appliances

A chave operacional é entender que essas três frentes costumam aparecer em sequência dentro de um único incidente. O atacante cega o agente de um host inicial, se mistura às ferramentas nativas para escalar privilégio e depois usa dispositivos não gerenciados como trampolim para reach de rede — justamente onde a telemetria de endpoint nunca vai enxergar.

BYOVD: o vetor que cega

O BYOVD (Bring Your Own Vulnerable Driver) é a tática mais letal da frente de tampering. O atacante carrega na vítima um driver legitimamente assinado, porém vulnerável, explorado para ganhar privilégio de kernel e remover os callbacks que o EDR registra para observar o sistema. Como o driver é assinado por um fabricante legítimo, contorna as proteções padrão de carregamento.

Pesquisa recente catalogou 54 ferramentas de “EDR killer” que abusam de 35 drivers assinados para desligar produtos de endpoint. O projeto LOLDrivers mantém a lista curada e atualizada desses drivers vulneráveis e maliciosos — recurso obrigatório para qualquer SOC que opera ambiente Windows.

O custo desse vetor em produção é mensurável. No ataque à Change Healthcare, o grupo ALPHV/BlackCat usou credenciais roubadas para desabilitar as defesas de endpoint e passou nove dias movendo-se lateralmente, exfiltrando 6 TB de dados e extorquindo US$ 22 milhões. A invasão da Scattered Spider em ambientes de saúde e gaming seguiu o mesmo padrão: driver assinado vulnerável para acesso de kernel, desregistro de callbacks de segurança e agentes cegados. Em todos esses casos, o movimento do atacante continuou visível na rede — mas não no endpoint.

Rede: a evidência imutável

A rede é a fonte de evidência imutável que o atacante não consegue apagar. Diferente de um agente de endpoint, que pode ser desinstalado ou ter seus filtros manipulados, o tráfego de rede reflete o comportamento real do host independentemente do que acontece dentro dele. Comando malicioso enviado via protocolo legítimo, exfiltração disfarçada de transferência de arquivo comum e beaconing para infraestrutura de comando e controle deixam rastro na telemetria de rede.

Por isso a detecção multicamada deixou de ser opcional. O relatório de Resposta a Incidentes Global da Unit 42 de 2026 analisou mais de 750 engajamentos e constatou que 87% das invasões envolveram atividade em múltiplas superfícies de ataque. Mais de 90% das violações foram viabilizadas por falhas de exposição evitáveis — gap de configuração e cobertura que um SOC com visibilidade integrada teria fechado.

A conclusão operacional é simples: quando o EDR falha, o tempo médio de detecção (MTTD) estica para dias ou semanas. A camada de rede é o que mantém o MTTD curto. Por isso artigos anteriores deste site já tratavam NDR no SOC como o complemento que sua ferramenta de logs não enxerga e o impacto das lacunas de visibilidade em SOCs que operam com pontos cegos. A evasão de EDR é justamente o cenário em que essa redundância se paga — e onde a unified detecção e resposta do XDR mostra seu valor.

Detecção dinâmica de BYOVD

O erro clássico de quem começa a detectar BYOVD é embutir a lista de hashes e nomes de driver diretamente na regra Sigma. Funciona no primeiro dia, vira pesadelo de manutenção em três meses: toda vez que o LOLDrivers publica novos indicadores, alguém precisa regenerar a lista, testar e redesplegar a regra. A regra vira um repositório de IOC em vez de lógica de detecção.

A abordagem que escala é desacoplar inteligência de ameaças da lógica de detecção. Em vez de codificar hashes na regra, você ingere o feed do LOLDrivers como um índice de inteligência e usa correlação por correspondência de indicador:

Fonte de telemetria: eventos de carregamento de driver do Sysmon (Event ID 6), Elastic Defend ou logs nativos do Windows.
Fonte de inteligência: feed do LOLDrivers normalizado em campos como threat.indicator.file.hash.sha256 e threat.indicator.file.name.
Correlação: a regra compara o hash do driver carregado contra o índice e dispara alerta quando há correspondência.

O ganho operacional é grande: a regra nunca muda, só os dados por baixo dela são atualizados. A equipe de engenharia de detecção para de manter listas e passa a focar em lógica. Dois detalhes que reduzem falso positivo na prática: separe severidade entre driver malicioso (alta, investigar imediatamente) e driver vulnerável (baixa, pois ambientes corporativos podem carregar software legítimo que usa esses drivers), e adicione filtros por publicador confiável, caminho de instalação e criticidade do ativo.

Runbook para EDR burlado

A pergunta certa não é “se” o EDR será evadido, mas “quando”. Um runbook de resposta a evasão precisa cobrir detecção, contenção e recuperação sem depender do agente comprometido:

Confirmar a cegueira: cruze a queda de volume de telemetria do host contra tráfego de rede ativo. Host silencioso com tráfego de saída anômalo é alerta vermelho, não falso positivo.
Isolar pela rede: quando não dá para confiar no agente de endpoint para contenção, aplique bloqueio no switch, no firewall de segmento ou via isolamento de NDR. Não conte com a auto-contenção do EDR desligado.
Coletar evidência de rede: capture pacote e preserve logs de proxy, DNS e fluxo de rede antes da contenção. Esse é o registro forense que o endpoint apagado não vai fornecer.
Investigar o vetor de evasão: identifique o driver carregado (consulte o Sysmon EID 6 e o feed do LOLDrivers), o processo pai e a cadeia que levou ao acesso de kernel.
Restaurar visibilidade: reinstale o agente, aplique a lista de bloqueio de drivers vulneráveis nativa do Windows e valide o retorno da telemetria antes de reconectar o host à rede.
Documentar e retroalimentar: registre a técnica de evasão (mapeie no MITRE ATT&CK) e ajuste a regra de detecção de gap de telemetria para pegar o padrão da próxima vez.

A visibilidade multicamada é o que separa um SOC que detecta invasão em horas de um que descobre o vazamento pelo jornal. Manter EDR, NDR e telemetria de identidade funcionando em conjunto não é redundância cara — é o seguro barato contra a única coisa que todo atacante moderno já sabe fazer: cegar o seu agente.