Volatility 3 Cyber Suite (com eBPF e LLM)

Nota da subpasta 04 - Ferramentas de Análise de Memória e DFIR, no Capítulo 24 (Ferramentas e Plataformas Atualizadas).
Cobre o Volatility 3 como framework forense de memória, os comandos essenciais de triagem e as expansões recentes do ecossistema com telemetria runtime via eBPF e assistentes LLM para triagem de resultados.
Dialoga com a nota de SPECTRE da mesma subpasta, com as notas de Elastic, Wazuh e Splunk da pasta 02 e com as notas de TIP da pasta 01.

1. Contexto e Posicionamento na Biblioteca

A memória volátil é a fonte que registra, em um único instante, processos em execução sem suporte em disco, conexões de rede vivas, chaves de criptografia em uso e código carregado apenas em RAM. Por isso a análise de memória ocupa o posto de evidência de maior fidelidade nos casos em que o adversário opera fileless, apaga rastros ou usa módulos de kernel para se esconder. O Volatility é o padrão de fato dessa disciplina, e o Volatility 3, reescrito em Python 3 com arquitetura modular, é a versão de referência a partir da qual o ecossistema evolui.

O rótulo Cyber Suite usado nesta nota designa a direção recente do projeto e do seu entorno: além do framework clássico de plugins forenses, o ecossistema incorporou instrumentação runtime baseada em eBPF para telemetria contínua em hosts Linux e assistentes baseados em LLM para acelerar a triagem de resultados volumosos. O analista que domina apenas o comando isolado perde metade do valor, porque a força está no ciclo que vai da aquisição, passa pelos plugins e termina em hipóteses verificadas e IOC extraídos para a CTI. Esta nota cobre a arquitetura do framework, a aquisição, os comandos essenciais, as expansões com eBPF e LLM e um fluxo completo de análise de dump.

2. O Framework Volatility 3: Camadas, Símbolos e Plugins

O desenho técnico do Volatility 3 se apoia em três pilares. O primeiro é o framework de camadas, que abstrai o acesso à memória como uma pilha de espaços de endereçamento: o dump bruto se traduz em espaço físico e depois em espaço virtual por meio das estruturas de paginação do sistema operacional alvo. O segundo é o sistema de símbolos no formato ISF, descrito em JSON, que declara as estruturas do kernel e permite que os plugins percorram listas encadeadas de processos, módulos e handles sem depender de endereços fixos por versão. O terceiro é o catálogo de plugins, cada um com escopo único, o que permite escrever extensões próprias sem tocar no núcleo do framework.

A prática de símbolos merece atenção especial. Em Windows, o framework identifica a versão exata do kernel no dump e consome os pacotes de símbolos públicos correspondentes; em Linux e macOS, o analista geralmente precisa gerar o ISF com ferramentas como o dwarf2json, a partir dos binários e dos debug symbols do kernel exato da máquina de origem. Sem símbolos corretos, plugins falham em silêncio ou devolvem resultados vazios, e essa é a primeira causa de dump que parece não abrir em laboratório.

A tabela resume os plugins de primeira linha para triagem em Windows e a pergunta que cada um responde.

3. Aquisição e Preparação da Evidência

A aquisição é o passo que define o valor de tudo o que vem depois, e ela obedece à ordem de volatilidade: memória antes de disco, disco antes de backups, tudo antes do reboot. Em Windows, ferramentas como winpmem e DumpIt capturam a memória física inteira para um arquivo único; em Linux, LiME e avml cumprem o mesmo papel, com avml sendo prática comum em ambientes de nuvem. O arquivo resultante recebe hash criptográfico registrado na cadeia de custódia, é armazenado em volume criptografado e nunca é analisado na máquina de origem.

# no host comprometido, como administrador, antes de qualquer reboot
winpmem_mini_x64.exe E:\evidencia\SRV-01-20250312.mem
# em estacao de analise, registrar integridade da evidencia
sha256sum SRV-01-20250312.mem | tee SRV-01-20250312.mem.sha256
# validar que os simbolos carregam antes de prosseguir com a triagem
vol -f SRV-01-20250312.mem windows.info

A validação do windows.info como primeiro passo não é ritual, é teste de sanidade. Se a versão do kernel e o carregamento de símbolos aparecem corretos, toda a cadeia de plugins seguinte é confiável; se algo falha nesse ponto, o problema está na aquisição ou nos símbolos, e não nas conclusões que viriam depois. Times que pulam essa verificação frequentemente descobrem, horas depois, que analisaram um dump truncado por armazenamento insuficiente no embarque.

4. Comandos Essenciais e Leitura Crítica dos Resultados

A sequência abaixo representa o núcleo de triagem sobre um dump Windows, na ordem que a prática consagrou: listar processos ativos, procurar ocultação, procurar injeção, mapear rede e puxar contexto de execução.

vol -f evidencia/SRV-01-20250312.mem windows.pslist
vol -f evidencia/SRV-01-20250312.mem windows.psscan
vol -f evidencia/SRV-01-20250312.mem windows.malfind --dump
vol -f evidencia/SRV-01-20250312.mem windows.netscan
vol -f evidencia/SRV-01-20250312.mem windows.pstree
vol -f evidencia/SRV-01-20250312.mem windows.cmdline --pid 6140
vol -f evidencia/SRV-01-20250312.mem windows.yarascan.YaraScan --yara-file regras_beacon.yar

A leitura crítica importa mais do que a execução. O malfind produz falsos positivos com software empacotado e com alocações legítimas de JIT, e a confirmação vem do cruzamento com o cmdline, com a ancestralidade do pstree e com a presença ou ausência do processo no psscan. O netscan mostra apenas o estado das conexões no instante da aquisição, então ausência de conexão não prova ausência de C2, e conexões encerradas recentemente ainda aparecem e valem como IOC. A comparação entre pslist e psscan é a que aponta ocultação por desconexão de listas, e qualquer processo presente em um e ausente do outro merece explicação documentada.

5. Expansão com eBPF: Telemetria Runtime no Ecossistema

A expansão com eBPF adiciona ao ecossistema a dimensão que o dump isolado não tem, que é o tempo. O eBPF, do inglês extended Berkeley Packet Filter, permite executar programas verificados dentro do kernel Linux sem carregar módulos, e ferramentas como Tetragon, Falco e bpftrace transformam esse mecanismo em telemetria contínua de syscalls, hooks de segurança e operações de arquivo. No contexto de DFIR, a comparação entre o que a telemetria runtime viu e o que a imagem de memória revela se tornou técnica de caça por si só: um processo que aparece na telemetria de execução e não aparece no pslist do dump posterior indica ocultação na lista ativa, o clássico DKOM, agora com evidência dupla.

O exemplo abaixo, didático, monitora chamadas de mprotect com permissão de execução no host, comportamento que antecede boa parte da injeção de código em memória. Em produção, o mesmo papel é cumprido com políticas declarativas de ferramentas como o Tetragon, que entregam a telemetria já enriquecida ao coletor.

bpftrace -e 'tracepoint:syscalls:sys_enter_mprotect /arg2 & 0x4/
  { printf("pid=%d comm=%s addr=%lx len=%lx prot=%lx\n", pid, comm, arg0, arg1, arg2); }'

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: telemetria-mprotect-executavel
spec:
  kprobes:
    - call: "security_file_mprotect"
      syscall: false
      args:
        - index: 2
          type: "int"
      selectors:
        - matchArgs:
            - index: 2
              operator: "Equal"
              values: ["4"]
      message: "alteracao de protecao de pagina para executavel"

A fronteira honesta dessa expansão é o sistema operacional: o eBPF maduro é fenômeno Linux, e o port para Windows, embora em progresso, ainda não cobre o mesmo terreno. Por isso o desenho típico combina eBPF nos servidores Linux, onde entrega telemetria de kernel de alta fidelidade, com dumps de memória periódicos nos hosts Windows, onde o Volatility segue como instrumento principal de caça e resposta.

6. Expansão com LLM: Triagem Assistida de Resultados

A expansão com assistentes de linguagem ataca o outro gargalo, que é o volume de saída. Uma triagem completa sobre um dump de servidor gera milhares de linhas somando pslist, netscan e malfind, e o assistente serve para resumir, correlacionar saídas de plugins diferentes e propor hipóteses de encadeamento, como ligar um processo órfão do pstree a uma conexão do netscan e a uma linha de comando ofuscada do cmdline. O ganho maior aparece em resposta a incidente com pressão de tempo, quando a janela de decisão é curta e o volume bruto de resultado paralisaria a equipe.

O uso responsável exige três cuidados permanentes. O primeiro é prompt estruturado, com papel, contexto do caso, formato de saída e restrições explícitas. O segundo é governança de dados, porque o dump pode conter segredos, credenciais e dados pessoais, o que pode exigir modelo local ou sanitização prévia das saídas antes de qualquer envio a serviço externo. O terceiro é validação humana de cada afirmação contra a evidência original, porque o LLM alucina, não tem acesso ao dump em si e não substitui o comando forense.

1. Executar plugins e salvar saidas: pslist, pstree, psscan, malfind, netscan, cmdline
2. Montar o prompt com papel, contexto do caso, formato de saida e restricoes
3. Anexar as saidas e pedir: correlacione, ranqueie por suspeita e liste justificativas
4. Exigir que cada afirmacao cite o plugin e o trecho de origem
5. Validar cada afirmacao contra o dump antes de aceitar
6. Fechar a triagem com relatorio e evidencia original anexados ao caso

7. Uso em Threat Hunting e em Resposta a Incidentes

No hunting, o dump de memória funciona como fonte de hipótese e de confirmação. Varreduras periódicas de aquisição leve com winpmem em hosts de alta exposição, seguidas de yarascan com regras das famílias relevantes ao intelligence da organização, transformam a memória em superfície de caça complementar ao SIEM. O critério de sucesso é o mesmo de qualquer caça: a hipótese nasce de um relatório de CTI ou de um padrão suspeito de telemetria, e a memória fornece a confirmação técnica que o log não alcança, como o conteúdo íntegro de uma região injetada.

No IR, a memória é a primeira evidência a perder, e a ordem de preservação dita o começo da operação. A aquisição acontece antes do desligamento, o hash é registrado na cadeia de custódia, e a análise roda em estação isolada, nunca na máquina de produção. Em incidentes com grupos agressores ativos, como os casos públicos de ransomware de LockBit e ALPHV, o dump é frequentemente a fonte que revela o mecanismo de execução inicial depois que o próprio adversário limpou o disco e os logs.

8. Exemplo de Fluxo de Análise de Memory Dump

O cenário: um servidor web Windows sem alerta de EDR, com relatório de CTI apontando campanha que usa loader fileless e beacon de C2. O fluxo abaixo condensa a operação, do embarque ao relatório.

1. Coleta: winpmem gera SRV-01-20250312.mem, hash SHA-256 registrado na custodia
2. Validacao: windows.info confirma Windows Server 2019 e simbolos carregados
3. Linha de base: windows.pslist lista 84 processos, ancestralidade sem suspeito obvio
4. Ocultacao: windows.psscan revela svchost.exe com PID 6140 ausente da lista ativa
5. Injecao: windows.malfind aponta regiao RWX sem arquivo em 6140, regiao extraida
6. Rede: windows.netscan mostra 6140 com TLS persistente para 203.0.113.44:443
7. Contexto: windows.cmdline mostra 6140 lancado por powershell com linha ofuscada
8. Assinatura: yarascan bate regra de configuracao de beacon, IOC extraidos
9. Fechamento: achados mapeados em ATT&CK, IOC enviados ao TIP, host isolado

Cada achado do fluxo se converte em técnica mapeada e em ação concreta, como resume a tabela.

O fluxo termina com três entregas: os IOC alimentando a CTI, a detecção nova alimentando o SIEM e o laudo alimentando o caso de IR. É esse circuito de evidência para prevenção que justifica o esforço da análise de memória, e é o mesmo circuito que a nota de SPECTRE encurta ao detectar a ameaça durante a execução, e não após o fato.

9. Erros Comuns e Pontos de Atenção

• Aceitar o resultado de um plugin isolado como veredito, sem cruzar malfind com cmdline, pstree e psscan; o falso positivo de software empacotado é rotina conhecida.
• Analisar com símbolos errados ou ausentes, obtendo listas vazias que levam à conclusão equivocada de ambiente limpo.
• Esquecer hash e cadeia de custódia na aquisição, comprometendo o valor jurídico da evidência e a reprodutibilidade do laudo.
• Executar extrações de código suspeito em estação conectada à rede corporativa; a região extraída pelo malfind é malware vivo.
• Tratar a saída do assistente LLM como evidência; a saída é hipótese de triagem, e a evidência continua sendo o dump e o plugin que a produziu.
• Manter o Volatility 2 em produção, sem manutenção e sem suporte a sistemas recentes, quando o Volatility 3 cobre o mesmo terreno com API estável.
• Adiar a aquisição de memória para depois do reboot de contenção, perdendo a evidência mais volátil do caso sem alternativa de recuperação.
• Subir dumps inteiros a serviços externos de IA sem sanitização, expondo credenciais e dados pessoais capturados na memória.

10. Integração com o Restante da Biblioteca

Os IOC extraídos do dump alimentam as notas de TIP da pasta 01, em especial o OpenCTI e o MISP, e as detecções derivadas dos achados pousam nas notas de Elastic, Wazuh e Splunk da pasta 02, que operam o SIEM onde o padrão vira regra. A nota de SPECTRE desta subpasta cobre o lado runtime da mesma superfície, e as duas notas juntas descrevem o par detecção durante a execução e análise forense após o fato. No ciclo de resposta, o dump entra como evidência nos passos de detecção e análise do NIST SP 800-61, e o feedback para o programa purple, na pasta 03, usa emulações do Caldera e do Atomic Red Team para validar que as técnicas mapeadas no fluxo geram, de fato, artefatos em memória observáveis.

A recomendação operacional de fechamento é institucionalizar um kit de aquisição pronto, com mídia, ferramenta de captura versionada, formulário de cadeia de custódia e destino de armazenamento criptografado. Times que mantêm esse kit ensaiado transformam a análise de memória de habilidade de especialista em rotina de resposta, e é essa rotina que sustenta as caças por hipótese descritas nas notas de metodologia de hunting da biblioteca, nas quais a memória funciona como tribunal final quando os logs de disco e de rede discordam entre si.