Ferramentas de Análise de Memória e Disco (Volatility, Plaso)

Nota 06 do capítulo 09 (Ferramentas e Plataformas), dedicada às ferramentas forenses que levam a caça além da telemetria contínua.
Volatility 3 interpreta o estado volátil da memória RAM; Plaso converte artefatos de disco em super timelines consultáveis.
Dialoga com a nota 05 do capítulo 08 (coleta de credenciais), com a nota 03 do capítulo 07 (coleta e normalização) e com os controles DAT.1, TH.3 e TH.13 do capítulo 15.

1. Contexto e Posicionamento na Biblioteca

As demais notas do capítulo 09 cobrem plataformas que observam o ambiente de forma contínua, com agentes e telemetria indexada. Esta nota introduz as duas ferramentas clássicas da DFIR (Digital Forensics and Incident Response) que operam sobre o estado de um host específico: o Volatility 3, que interpreta a memória volátil capturada, e o Plaso, que transforma artefatos persistidos em disco em uma única linha do tempo ordenada. Ambas respondem perguntas que o SIEM não alcança: o que o processo fazia na RAM no instante da captura, qual chave de registro sobreviveu a uma limpeza superficial, em que ordem exata os eventos se deram em um host sem agente.

Dentro do programa de CTI e Threat Hunting desta biblioteca, as duas ferramentas cumprem três papéis complementares. Na resposta a incidentes, fornecem profundidade forense para reconstruir a intrusão e sustentar o relatório de inteligência da nota 04 do capítulo 05. Na caça profunda, permitem investigar hosts apontados por hipótese sem depender de cobertura de agente, cobrindo servidores legados, estações de grupos sensíveis e imagens de resposta rápida. Na validação, servem como fonte de verdade para confirmar ou refutar achados do SIEM, materializando o controle TH.13 (Hunting de Memória) do capítulo 15.

A disciplina operacional que rege o uso das duas ferramentas é o custo de coleta, e por isso a nota termina com números concretos. Capturar memória interrompe brevemente o host e produz um arquivo do tamanho da RAM; uma varredura completa de disco com todos os parsers pode levar horas e gerar arquivos de vários gigabytes. Selecionar artefatos por hipótese, em vez de capturar tudo sempre, é a competência que transforma essas ferramentas em instrumentos de caça e não em rituais de emergência.

2. Volatility 3: Modelo de Operação e Plugins Essenciais

O Volatility 3 abandonou os perfis fixos da série 2 e passou a trabalhar com camadas de símbolos, arquivos ISF em JSON que descrevem estruturas e offsets do kernel, mantidas em repositório oficial e geráveis para kernels customizados. A operação é offline por natureza: o analista roda o binário vol sobre o dump, o host investigado não é tocado e a evidência permanece íntegra. A sintaxe padrão é vol -f <dump> <plugin>, com saída em texto que se encadeia bem com awk, grep e sort nos pipelines de triagem.

Os plugins de maior retorno em hunting e IR estão resumidos abaixo, com a pergunta que cada um responde:

A ordem de leitura importa mais que a lista: a seção seguinte segue a sequência inventário, injeção, rede e credenciais, que maximiza achado por minuto de análise e evita que o analista se perca em becos sem saída nos primeiros minutos de triagem.

O primeiro plugin a rodar em qualquer dump é o windows.info, que confirma se a camada de símbolos casou com o kernel correto, mostra a versão exata do sistema e o uptime no momento da captura. Sem essa validação inicial, saídas de plugins posteriores podem ser silenciosamente incorretas, com estruturas interpretadas em offsets errados; quando o windows.info falha ou devolve dados inconsistentes, o problema está nos símbolos, e é neles que a depuração começa.

3. Fluxo Prático de Análise de Memória

O roteiro mínimo de triagem de um dump Windows começa pelo inventário e parentesco, passa pela caça de injeção e termina em rede e credenciais. Os comandos assumem um dump raw obtido com winpmem ou com o coletor do EDR, de um host suspeito de execução de loader.

vol -f host32.mem windows.pstree
vol -f host32.mem windows.psscan > psscan.txt
vol -f host32.mem windows.cmdline --pid 4816
vol -f host32.mem -o saida/ windows.malfind --dump --pid 4816
vol -f host32.mem windows.dlllist --pid 4816
vol -f host32.mem windows.netscan > netscan.txt
vol -f host32.mem windows.handles --pid 4816 | grep -i lsass

A leitura começa pelo pstree: processos legítimos têm pais coerentes com boot e logon, e qualquer PowerShell filho de winword.exe, cmd.exe filho de wscript.exe ou binário de caminho de usuário pai de processos de sistema precisa ser explicado antes de prosseguir. O psscan complementa ao revelar processos presentes na memória mas ausentes da lista encadeada, indício de ocultação por DKOM associada a rootkits e a ferramentas de evasion modernas.

O malfind lista regiões de memória com proteção executável e sem backing file no disco. Nem toda região apontada é maliciosa, porque JIT de runtimes legítimos e produtos de proteção produzem falsos positivos frequentes; a triagem combina o resultado com cmdline e dlllist do mesmo PID e, quando o caso justifica, envia as regiões despejadas para análise estática em disassembler ou para sandbox interna.

No netscan, o interesse recai sobre conexões ESTABLISHED mantidas por processos que não deveriam falar com redes externas, como rundll32, regsvr32, mshta e binários de caminhos de usuário. O cruzamento do endereço externo com reputação, passive DNS e o histórico de resolução da nota 01 do diretório 06 do capítulo 03 fecha o elo entre o processo em memória e a infraestrutura adversária.

vol -f host32.mem windows.netscan | grep ESTABLISHED | grep -Ei "rundll32|regsvr32|mshta|Users"

No registro em memória, o printkey com chave explícita responde à hipótese de persistência sobrevivente a limpeza, e o filescan lista todos os arquivos que o kernel mantinha mapeados, incluindo binários executados de caminhos de usuário e já apagados. O dumpfiles baixa cópias desses arquivos para análise estática, usando o offset virtual que o filescan reporta.

vol -f host32.mem windows.registry.printkey --key "Software\\Microsoft\\Windows\\CurrentVersion\\Run"
vol -f host32.mem windows.filescan | grep -Ei "Users.*(Downloads|Temp).*\.exe"
vol -f host32.mem -o saida/ windows.dumpfiles --virtaddr 0x1f2a0000

4. Extensões de Caça: Credenciais, Linux e Máquinas Virtuais

A memória é a melhor fonte de credenciais efêmeras que o disco já não guarda, e os plugins de credenciais sustentam diretamente as hipóteses de coleta de credenciais da nota 05 do capítulo 08. O hashdump recupera hashes de contas locais do SAM carregado em memória, o cachedump extrai hashes de cache de domínio e o lsadump lê segredos do LSA, incluindo chaves de serviço e credenciais armazenadas. A extração só é legítima dentro de incidente autorizado ou de laboratório, e o resultado entra no caso com o mesmo rigor de cadeia de custódia dos demais artefatos.

vol -f host32.mem windows.hashdump
vol -f host32.mem windows.cachedump
vol -f host32.mem windows.lsadump

O Volatility 3 também cobre Linux, o que importa para ambientes mistos. Os plugins linux.pslist, linux.bash, linux.malfind e linux.sockstat reproduzem a mesma sequência de triagem do Windows: inventário de processos, histórico de comandos por usuário, regiões suspeitas e sockets. Em servidores sem agente, o linux.bash sozinho já costuma responder quem executou o quê antes da captura, e o cruzamento com os logs de autenticação do host fecha o recorte temporal.

vol -f srv01.linux.mem linux.pslist
vol -f srv01.linux.mem linux.bash
vol -f srv01.linux.mem linux.malfind
vol -f srv01.linux.mem linux.sockstat

Em máquinas virtuais, o alvo correto é a memória completa do hypervisor, o arquivo .vmem do VMware ou o snapshot do Hyper-V, e não a captura de uma única vCPU, porque o kernel assume que todos os processadores continuam rodando. A regra prática é pausar a VM, capturar a memória inteira e documentar versão do hypervisor e ferramenta de captura, informações que o windows.info confirma depois, do lado da análise.

5. Plaso e log2timeline: Construção de Super Timelines

O Plaso é um motor de parsers que lê dezenas de formatos de artefatos e converte tudo em eventos com timestamp normalizado e proveniência registrada. O fluxo tem dois comandos: log2timeline.py processa a fonte, seja imagem forense, volume montado ou diretório de coleta, e gera um arquivo .plaso; psort.py consulta, filtra, etiqueta e exporta esses eventos quantas vezes for preciso, sem reler o disco. Entre uma execução e outra, o pinfo.py expõe quais parsers rodaram, quantos eventos cada um produziu e que erros ocorreram, informação essencial para auditar a coleta.

log2timeline.py --parsers "winevtx,prefetch,usnjrnl,mft,winreg,lnk,olecf,file_system,amcache" triagem.plaso /mnt/forense/C/
pinfo.py triagem.plaso
psort.py -o l2tcsv -w janela.csv triagem.plaso "date > '2024-03-10 00:00:00' and date < '2024-03-11 23:59:59'"

Os parsers de maior valor em caça de intrusão Windows estão resumidos abaixo:

O super timeline só vira produto de caça quando recortado. O psort aceita expressões de filtro por data e por campo, e o plugin de tagging aplica rótulos a partir de regras em YAML, isolando em minutos a janela que interessa à hipótese em curso. O exemplo abaixo etiqueta execução suspeita de PowerShell e criação de serviço, dois eventos centrais de qualquer cadeia de intrusão Windows:

labels: [ExecucaoSuspeita]
events:
- filter: data_type == 'windows:prefetch:execution' and executable contains 'POWERSHELL'
- filter: data_type == 'windows:evtx:record' and xml_string contains '<EventID>7045</EventID>'

O psort ainda traz plugins de análise que enriquecem o recorte: o sessionize agrupa eventos em sessões por tempo e por fonte, o unique_domains_visited lista os domínios visitados no período e o tagging aceita múltiplos conjuntos de regras empilhados. Encadear sessionize antes do export organiza a timeline em blocos legíveis, e o recorte por sessão costuma revelar o padrão de repetição que a nota 06 do capítulo 08 caça no plano de rede.

6. Da Hipótese aos Artefatos: Uso em Caça

Na rotina de hunting, memória e timeline entram como segunda onda de coleta, disparada por um alerta ou por uma hipótese que aponta um host. O desenho típico é o seguinte: o SIEM ou o Velociraptor da nota 07 aponta anomalia de execução; o time captura a memória com winpmem, coleta os artefatos selecionados com KAPE ou com o coletor offline, gera o .plaso restrito aos parsers da janela suspeita e cruza a timeline local com os eventos já indexados no SIEM. O cruzamento de timestamps entre telemetria remota e evidência local é o que transforma alerta em diagnóstico.

A seleção de artefatos por hipótese vale mais que a varredura completa em triagens iniciais. Execução suspeita pede prefetch, amcache e olecf; persistência pede winreg, usnjrnl e winevtx de criação de serviço; movimento lateral pede winevtx de logon e artefatos de task scheduler; exfiltração pede usnjrnl e file_system sobre compartilhamentos e mídias removíveis. A nota 02 do capítulo 07 define como essas listas nascem do documento de hipótese, e o time as mantém versionadas em repositório, revisadas a cada campanha relevante do capítulo 01.

7. Custo de Coleta e Limitações

Entre as limitações que o time precisa dominar, quatro dominam a prática. O Volatility depende de símbolos corretos para o kernel exato, e hosts com patches recentes ou kernels customizados exigem geração própria de ISF. A memória é uma foto instantânea, sem histórico, e malware que detecta a ferramenta de captura pode não estar presente no dump, o que exige combinar fontes. O Plaso não produz telemetria de rede, e a lacuna que ele deixa deve ser preenchida com Zeek e Suricata da nota 12 do capítulo 08. Por fim, imagens de VM precisam da memória completa do hypervisor, e pausar a VM errada corrompe a cadeia de custódia.

O planejamento reduz a maior parte desse custo. Janelas de captura acordadas com as áreas de negócio, armazenamento pré-provisionado com hashing no recebimento e um repositório de ferramentas de captura homologadas por versão de sistema eliminam as improvisações que consomem horas no momento crítico. Para o Plaso, manter um preset de parsers por tipo de host, servidor, estação e saltador de rede, evita tanto a varredura completa desnecessária quanto a coleta seletiva que esquece artefato central.

8. Erros Comuns e Pontos de Atenção

Capturar memória sem planejar a saída é o erro mais caro: dumps sem local de armazenamento definido, sem hash calculado no recebimento e sem registro de cadeia de custódia costumam ser inutilizáveis em investigação formal. Trate o dump como evidência desde o primeiro minuto, com hash SHA256 no momento da coleta e permissões restritas no destino. Evite também capturar memória de hosts críticos em horário de pico sem janela acordada, porque a pausa de captura, ainda que curta, derruba conexões de memória volátil de aplicações sensíveis.

Na análise, dois deslizes dominam. Confundir malfind com veredito leva a falsos positivos tratados como incidentes, já que a ferramenta aponta regiões suspeitas e não malware confirmado; a confirmação exige correlação com cmdline, dlllist, rede e contexto. Na frente do Plaso, rodar a varredura completa por hábito, sem recorte de parsers e de janela, produz timelines gigantes que ninguém lê; o super timeline de milhares de linhas sem etiqueta é ruído caro, e o recorte por hipótese é o que gera produto analítico.

9. Integração com o Restante da Biblioteca

Esta nota consome hipóteses do capítulo 07 e devolve evidência ao ciclo de inteligência do capítulo 05: hashes extraídos de memória alimentam o IOC do capítulo 03, conexões do netscan enriquecem a análise de infraestrutura da nota 06 do capítulo 03, e a timeline do Plaso sustenta o clustering de campanhas da nota 01 do capítulo 05. O controle TH.13 do capítulo 15 recebe aqui a execução concreta do hunting de memória, e o DAT.1 orienta que artefatos de disco valem como fonte de caça mesmo sem agente.

Nas próximas notas do capítulo, o Velociraptor da nota 07 automatiza justamente a coleta que esta nota executou à mão, com artifacts de prefetch, registro e dumps sob demanda, e a nota 08 mostra como eventos forenses podem entrar no mesmo lake de dados que a telemetria contínua. O leitor deve sair desta nota com um roteiro de triagem de memória memorizado, uma lista de parsers Plaso por hipótese e a régua de custo que decide quando cada coleta vale o impacto.