autopsiadigital.com
Radar / Notícias / AD-2026-067
panoramaNOTÍCIA2020-05-27 · 2 min de leitura
0

Quando motores de antivírus parecem rootkits de kernel: um estudo de caso com Volatility

Resumo executivo

Um artigo técnico do time do Volatility explica por que produtos de segurança como antivírus e EDR frequentemente parecem rootkits durante uma análise de memória, já que usam as mesmas técnicas de hooking empregadas por malware. O post detalha um caso real em que 45 hooks de syscall marcados como "UNKNOWN" foram rastreados e identificados como proteção legítima da Symantec, não como comprometimento.

O post do Volatility Labs aborda um problema recorrente na análise forense de memória: ferramentas de segurança legítimas — antivírus, EDR e produtos similares — frequentemente empregam as mesmas técnicas de baixo nível usadas por rootkits maliciosos, como hooking de API, interceptação de chamadas de sistema (syscall hooking) e registro de callbacks no kernel. Isso significa que um analista, ao rodar um plugin de detecção de hooks, pode se deparar com dezenas de interceptações que parecem suspeitas à primeira vista, mas que na verdade são comportamento normal de um produto de proteção instalado.

O caso concreto analisado envolve um sistema Windows 7 em que o plugin ssdt do Volatility (que enumera a System Service Descriptor Table) sinalizou 45 chamadas de sistema redirecionadas para um destino desconhecido, todas classificadas como UNKNOWN por apontarem para um módulo não identificado automaticamente. A investigação manual usou o volshell para desmontar o código no endereço de destino e o plugin drivermodule para identificar a qual driver aquela região de memória pertencia. Todos os 45 hooks levavam a um único endereço (0x964ba922) dentro do driver SYMEVENT.SYS, e o padrão de fluxo de controle era consistente entre eles — assinatura típica de um produto de segurança legítimo (neste caso, a proteção da Symantec) e não de um rootkit, que tipicamente distribuiria os desvios entre múltiplos destinos e tentaria esconder o próprio módulo da lista de módulos carregados.

O valor prático do post está em ensinar o raciocínio de triagem: hooks que convergem para um único endereço, dentro de um driver nomeado e presente na lista de módulos, tendem a ser produto de segurança; hooks distribuídos, apontando para memória não mapeada a nenhum módulo, ou para regiões RWX alocadas após o descarregamento do módulo original, são sinais de comprometimento genuíno. Embora publicado em 2020, esse tipo de metodologia de triagem continua sendo material de referência para quem está aprendendo forense de memória, já que o problema de diferenciar EDR/AV de rootkit não desapareceu — pelo contrário, tende a se tornar mais comum à medida que mais produtos de segurança adotam técnicas agressivas de instrumentação em kernel.

Fonte ↗
0 comentários

Entre para comentar.

Nenhum comentário ainda — seja o primeiro.