Memory Forensics com Volatility 3: Analisando Dumps em Lab Reproduzivel
Workflow tecnico de analise de memoria com Volatility 3, dumps reproduzidos em sandbox e validacao cruzada com Rekall e MemProcFS.

Memory forensics e a disciplina de reconstruir a verdade volatil de um sistema comprometido a partir de uma imagem de RAM: processos em execucao, sockets abertos, payloads decifrados e codigo injetado que nunca toca o disco. Volatility 3 e o padrao open source para isso, reescrito por inteiro em Python 3, usando tabelas de simbolos em vez de perfis rigidos. Na Basilisk analisamos cada dump em um laboratorio reproduzivel para que um resultado resista em tribunal e em revisao por pares. Este guia vai da aquisicao da imagem ate a deteccao de injecao de processos, com comandos que voce pode seguir diretamente.
Por que a memoria volatil importa
Quase todo malware moderno existe so na RAM em algum momento: loaders sem arquivo, beacons injetados em explorer.exe, volumes LUKS ou BitLocker cujas chaves estao em memoria. Quem so imagina o disco perde a arvore de processos, as conexoes de rede ao C2, a area de transferencia, as strings decifradas e os restos de processos encerrados. A ordem de volatilidade conforme a RFC 3227 e clara: registradores de CPU e cache primeiro, depois RAM, depois swap, e so entao o disco. Por isso a primeira acao em um incidente ao vivo costuma ser uma captura limpa de memoria, antes que alguem desligue o sistema ou rode uma limpeza.
Adquirir a imagem de memoria
A aquisicao precisa preservar a integridade: pegada minima, hashing imediato, cadeia de custodia documentada. No Windows usamos WinPmem ou Magnet RAM Capture, no Linux AVML ou LiME como modulo de kernel, e em ambientes virtualizados o snapshot nativo do hipervisor, muitas vezes o caminho mais limpo. Logo apos o dump calculamos sha256sum imagem.raw e registramos o valor no log do caso. Uma imagem sem hash e sem timestamp e forensicamente inutil. Para analise de Windows tambem e valioso o pagefile.sys correspondente, porque paginas paginadas ao disco aparecem de outra forma como buracos.
Montar um laboratorio reproduzivel
Reprodutibilidade e o nucleo da forense seria. Trabalhamos em um conteiner Docker ou um venv de Python com uma versao do Volatility 3 fixada, pacotes de simbolos hasheados e a imagem montada como volume somente leitura. Cada analise parte do mesmo requirements.txt para que um colega produza exatamente o mesmo resultado. A imagem original fica intocada; todo o trabalho roda sobre uma copia verificada cujo hash bate com o original. Registramos cada comando executado com timestamp em um runbook do caso, para que toda a cadeia de analise seja depois reproduzivel passo a passo.
Volatility 3 e as tabelas de simbolos
Volatility 3 abandona os perfis rigidos da versao 2 e usa no lugar Intermediate Symbol Files (ISF) gerados a partir dos simbolos de depuracao do kernel. Para Windows o framework carrega simbolos automaticamente do servidor de simbolos da Microsoft usando o GUID do kernel; para Linux e macOS voce gera o ISF a partir do System.map correspondente e dos headers do kernel com dwarf2json. A primeira execucao e sempre vol -f imagem.raw windows.info para confirmar versao do sistema, base do kernel e fuso horario. Se o pacote de simbolos estiver errado, todo plugin seguinte devolve lixo, por isso esse passo nunca e pulado.
Analisar processos: pslist, psscan, pstree
O coracao da analise e o contexto de processo. windows.pslist percorre a lista duplamente encadeada de processos ativos como o kernel a mantem. windows.psscan, por outro lado, varre a memoria buscando assinaturas _EPROCESS e por isso tambem encontra processos encerrados ou ocultos por DKOM que foram desencadeados da lista. A diferenca entre as duas saidas e um indicador classico de rootkit. windows.pstree mostra a hierarquia pai-filho, onde anomalias saltam de imediato: um cmd.exe sob winword.exe, um powershell.exe sob outlook.exe ou um lsass.exe com pai errado sao sinais de alarme.
Rede e handles
Depois dos processos vem as conexoes. windows.netscan reconstroi endpoints TCP e UDP com IP de destino, porta, estado e processo dono, expondo canais C2 ativos mesmo quando a conexao foi breve. windows.handles lista os handles abertos de um processo para arquivos, chaves de registro, mutexes e named pipes; um mutex suspeito costuma ser a assinatura de uma familia de malware conhecida. windows.dlllist e windows.ldrmodules comparam os modulos carregados: uma DLL presente na imagem de memoria mas ausente das tres listas de carga sugere fortemente carregamento reflexivo de DLL.
Detectar injecao e hollowing
O plugin mais importante para ameacas ativas e o windows.malfind. Ele caca regioes de memoria que combinam protecao PAGE_EXECUTE_READWRITE, ausencia de respaldo em arquivo e bytes executaveis no inicio, que e o padrao classico de injecao de shellcode e process hollowing. A saida mostra um hex dump; um cabecalho MZ ou a assinatura reveladora 4D 5A em uma regiao RWX confirma um PE injetado. Como complemento, windows.hollowprocesses pega o caso em que um processo legitimo foi iniciado e sua memoria substituida por codigo alheio. Cada achado e cruzado com windows.vadinfo para nomear com exatidao a regiao VAD afetada.
Extrair artefatos
Uma vez confirmado um processo suspeito, extraimos evidencia. windows.memmap --pid N --dump salva toda a memoria enderecavel do processo; windows.dumpfiles --pid N reconstroi arquivos em cache a partir da memoria. A regiao injetada do malfind pode ser isolada e passada a uma sandbox ou a um desassembler como o Ghidra. Puxamos hives do registro com windows.registry.hivelist e windows.registry.printkey para inspecionar chaves de persistencia sob Run e Services. Cada arquivo extraido e hasheado de imediato e vinculado ao seu PID de origem no runbook do caso.
Armadilhas comuns
A primeira armadilha e o pacote de simbolos errado, que produz resultados plausiveis mas completamente falsos. A segunda e ignorar a diferenca entre pslist e psscan, deixando processos ocultos sem deteccao. A terceira e trabalhar sobre o original em vez de uma copia hasheada, o que destroi a cadeia de evidencia. A quarta e confiar em um unico indicador: um segmento RWX sozinho nao e necessariamente malicioso, porque compiladores JIT tambem criam tais regioes. A quinta e esquecer o pagefile.sys, o que deixa evidencia paginada faltando e a analise cheia de buracos.
Checklist
Adquira a imagem com pegada minima e hasheie de imediato com SHA-256. Trabalhe em um laboratorio reproduzivel sobre uma copia somente leitura. Confirme a versao do sistema e o pacote de simbolos correto com windows.info. Triague processos com pslist, psscan e pstree e anote as diferencas. Cheque a rede com netscan, os modulos com dlllist e ldrmodules. Cace injecao com malfind e hollowprocesses. Extraia regioes suspeitas com memmap e dumpfiles, hasheie e documente no runbook. Sustente cada achado com ao menos dois indicadores independentes.
Linha do tempo e correlacao
Um unico plugin da um instantaneo; a historia do incidente emerge apenas da correlacao de varias fontes ao longo de uma linha do tempo. windows.pstree com timestamps de criacao, combinado com os tempos de conexao de netscan e os timestamps de windows.registry.userassist, produz uma sequencia defensavel: quando o loader iniciou, quando o canal C2 abriu, quando a persistencia foi fixada. Exportamos esses artefatos e os fundimos em uma ferramenta de super-timeline como o Plaso para que eventos de disco e memoria fiquem em uma unica visao cronologica. So entao da para separar causa de efeito e nomear o paciente zero. O alinhamento de fuso horario importa: windows.info da o bias, e cada timestamp e normalizado de forma consistente para UTC, caso contrario voce fabrica uma causalidade aparente que nunca existiu. Uma linha do tempo limpa e a espinha do relatorio final e a primeira coisa que um perito confere.
Memoria Linux e macOS
Windows domina os exemplos, mas o Volatility 3 tambem analisa imagens Linux e macOS, desde que o ISF correspondente exista. Para Linux voce o gera com dwarf2json a partir do System.map especifico do kernel e dos simbolos de depuracao do kernel exato em execucao, porque ate uma diferenca de patch-level quebra a estrutura. Os nomes de plugin espelham a logica do Windows: linux.pslist e linux.pstree para processos, linux.bash extrai o historico de comandos direto da memoria do shell, e linux.check_syscall e linux.check_modules cacam rootkits de kernel que engancharam a tabela de syscalls. Para conteineres importa que um unico dump do host contem todos os namespaces; processos de conteineres distintos aparecem lado a lado e se separam pela pertinencia ao cgroup. macOS exige um pacote de simbolos gerado a partir da KDK correspondente. O principio permanece identico: simbolos verificados primeiro, depois triagem sistematica, depois extracao evidenciada.
FAQ: Posso analisar um dump de memoria sem um perfil exato do sistema?
No Volatility 3 nao ha mais perfis escolhidos a mao; o framework deriva a estrutura das tabelas de simbolos. Para Windows isso acontece automaticamente via o GUID do kernel e o servidor de simbolos da Microsoft. Para Linux voce mesmo precisa gerar o ISF correspondente a partir do System.map e dos simbolos de depuracao do kernel com dwarf2json, caso contrario os plugins falham.
FAQ: E se o malfind nao achar nada mas a suspeita permanece?
malfind e poderoso mas nao onisciente: malware avancado pode evitar regioes RWX, mapear memoria como imagem ou descomprimir codigo so em tempo de execucao. Complemente entao a analise com ldrmodules para DLLs desencadeadas, netscan para rastros de C2 e um scan YARA sobre toda a imagem com windows.vadyarascan para acertar assinaturas conhecidas.
Conclusao
Takeaway pratico: monte hoje um laboratorio reproduzivel, adquira uma imagem de uma VM de teste com um beacon conhecido e rode toda a cadeia de windows.info ate malfind ate voce mesmo ver o codigo injetado. Memory forensics nao e magica, e trabalho metodico: aquisicao limpa, simbolos verificados, triagem sistematica de processos, indicadores sustentados por varios e uma cadeia de evidencia sem quebra. Quem hasheia e registra cada passo entrega resultados que resistem tanto em um relatorio de resposta a incidentes quanto em um tribunal. Repita o exercicio com diferentes tecnicas de injecao ate o padrao no hex dump saltar aos olhos de imediato.


