Forense de memoria com Volatility 3: um guia de campo para defensores

Quando um endpoint e comprometido, a evidencia mais valiosa muitas vezes nunca toca o disco. Chaves de descriptografia, codigo injetado, malware desempacotado, conexoes de rede, argumentos de linha de comando e credenciais frequentemente existem apenas na memoria volatil, e desaparecem no momento em que a maquina e desligada. Forense de memoria e a disciplina de capturar e analisar essa RAM para reconstruir o que um sistema estava fazendo, e o Volatility 3 e o framework de codigo aberto ao qual a maioria dos defensores recorre. Este guia de campo adota a perspectiva de um analista de blue team respondendo a um incidente: como adquirir memoria de forma solida, quais plugins respondem quais perguntas, como reconhecer os sinais de injecao de codigo e rootkits e como evitar os erros que levam a conclusoes equivocadas. O enquadramento e entender para defender, entao focamos em deteccao e triagem em vez de escrever malware, e cada tecnica e apresentada como algo que voce executa para encontrar um atacante que ja esta dentro.

Por que forense de memoria importa#

A forense de disco lhe diz o que estava armazenado; a forense de memoria lhe diz o que estava rodando. Intrusoes modernas cada vez mais vivem da terra e operam na memoria para evadir a deteccao baseada em arquivos: malware sem arquivo executa a partir do PowerShell ou WMI sem um binario persistente, a injecao de processo esconde codigo dentro de processos legitimos, e cargas empacotadas ou cifradas so revelam sua forma real depois de carregadas na RAM. A memoria tambem retem estado transitorio que nenhum log registra, como a linha de comando exata de um processo ja encerrado, sockets de rede abertos, modulos de kernel carregados e credenciais em cache. Para um respondente, uma imagem de memoria e um instantaneo congelado da cena do crime no momento da captura. Ela permite responder perguntas que os logs sozinhos nao conseguem, e pode confirmar ou refutar uma hipotese sobre como um atacante obteve execucao, o que tocou e se ainda esta residente.

Aquisicao solida de memoria#

A analise so e tao confiavel quanto a aquisicao. O principio central e perturbar o sistema o minimo possivel e registrar exatamente o que foi feito. Em hosts Windows ao vivo, ferramentas como WinPmem, FTK Imager ou Magnet RAM Capture produzem uma imagem crua; no Linux, o AVML ou um modulo de kernel LiME capturam a memoria fisica; maquinas virtuais podem ser capturadas por snapshot ou ter seus arquivos de memoria copiados, muitas vezes a opcao mais limpa porque e efetivamente atomica. Sempre calcule o hash da imagem imediatamente (por exemplo SHA-256) e preserve esse hash em suas anotacoes, capture a memoria antes do disco quando viavel porque e a evidencia mais volatil, e documente o host, a hora, a ferramenta, a versao e o operador para manter a cadeia de custodia. Evite rodar a aquisicao a partir dos binarios nao confiaveis do proprio host suspeito, e esteja ciente de que um rootkit em execucao pode, em principio, interferir na aquisicao, uma razao para correlacionar achados de memoria com telemetria independente.

Fundamentos do Volatility 3#

O Volatility 3 e uma reescrita do framework classico com uma abordagem guiada por simbolos. Em vez de selecionar manualmente um "perfil" de sistema operacional como no Volatility 2, a versao 3 identifica automaticamente o sistema operacional e localiza estruturas do kernel usando tabelas de simbolos, que para o Windows sao obtidas de informacao PDB e para Linux e macOS vem de pacotes de simbolos casados por banner que voce fornece. Voce o invoca como vol -f memory.img plugins.Name, ou python3 vol.py a partir do codigo-fonte. O modelo mental e que cada plugin percorre estruturas de dados do kernel especificas para reconstruir um aspecto do estado do sistema. Colocar uma analise correta de Linux para rodar exige um pacote de simbolos ISF que combine com o kernel exato, um tropeço inicial comum. Uma vez resolvidos os simbolos, o mesmo fluxo de investigacao se aplica em todas as plataformas: enumerar processos, inspecionar suas relacoes, examinar o estado de rede, cacar injecao e extrair artefatos para estudo mais profundo.

Plugins essenciais e o que revelam#

Um punhado de plugins forma a espinha dorsal da maioria das investigacoes. O windows.pslist percorre a lista de processos duplamente encadeada, enquanto o windows.psscan varre a memoria em busca de estruturas de processo diretamente e pode revelar processos escondidos da lista; comparar os dois e um passo de deteccao classico. O windows.pstree mostra relacoes pai-filho, o que expoe linhagens suspeitas como um navegador gerando um shell. O windows.cmdline recupera linhas de comando de processos, muitas vezes o artefato mais informativo. O windows.netscan reconstroi conexoes de rede e portas em escuta. O windows.dlllist e o windows.handles mostram modulos carregados e objetos abertos. No Linux os analogos sao linux.pslist, linux.pstree, linux.bash para historico de shell e linux.check_syscall para manipulacao. Esses plugins transformam um bloco opaco de bytes em um inventario do que a maquina estava fazendo, e discordancias entre plugins que deveriam concordar sao, por si so, sinais fortes.

Detectar injecao de processo#

A injecao de processo esconde codigo do atacante dentro de um processo confiavel, e a forense de memoria e uma das formas mais confiaveis de captura-la. O plugin defensivo chave e o windows.malfind, que varre a memoria dos processos em busca de regioes que sao ao mesmo tempo executaveis e graváveis e que carecem de um arquivo de respaldo em disco, uma combinacao que o codigo legitimo raramente precisa e que shellcode e modulos carregados reflexivamente exibem com frequencia. Analistas procuram por paginas de memoria privada marcadas PAGE_EXECUTE_READWRITE, pelo revelador cabecalho MZ de uma imagem PE mapeada onde nenhum modulo deveria existir, e por regioes injetadas dentro de processos que nao tem razao para hospeda-las. Sinais complementares incluem um processo cuja lista de modulos omite uma DLL claramente presente na memoria, threads cujo endereco de inicio aponta para memoria sem respaldo, e processos esvaziados onde a imagem em disco e em memoria divergem. Nenhum e prova por si so, mas juntos constroem um caso convincente e devem ser corroborados com telemetria de EDR e rede.

Cacar rootkits e artefatos escondidos#

Rootkits tentam se tornar invisiveis ao sistema operacional em execucao, mas nao conseguem se esconder facilmente de uma visao externa da memoria, o que e precisamente a vantagem da analise forense. A deteccao de visao cruzada compara duas formas de enumerar a mesma coisa e sinaliza discordancias: um processo visivel para o psscan mas ausente do pslist pode estar desvinculado da lista de processos ativos, uma tecnica de ocultacao classica. No Linux, o linux.check_syscall e verificacoes de integridade de modulo revelam tabelas de syscall com hook ou ponteiros de funcao manipulados. Analistas tambem inspecionam a SSDT e a IDT no Windows, modulos de kernel escondidos e objetos de driver que nao correspondem a nenhum arquivo legitimo. O principio defensivo e a triangulacao: nunca confie em um unico caminho de enumeracao, porque todo o proposito de um rootkit e corromper uma visao enquanto deixa outra intacta. A forense de memoria vence aqui porque le estruturas que o SO comprometido tentava esconder.

Extrair e pivotar para analise mais profunda#

Uma vez que a analise de memoria identifica algo suspeito, o proximo passo e a extracao para estudo mais proximo. O windows.dumpfiles recupera arquivos em cache na memoria, o windows.memmap e os plugins de dump de processo extraem o espaco de enderecos de um processo, e as regioes injetadas encontradas pelo malfind podem ser recortadas para analise estatica ou dinamica em uma sandbox. As linhas de comando e os endpoints de rede recuperados se tornam indicadores de comprometimento que voce pode varrer pelo resto do parque. Hives de registro residentes na memoria podem ser analisados em busca de chaves de persistencia e programas executados recentemente. O fluxo e iterativo: um achado na memoria gera uma hipotese, o artefato extraido a confirma ou refina, e os indicadores resultantes impulsionam uma cacada por outros hosts. Ao longo de tudo, mantenha a imagem original imutavel e trabalhe sobre copias, para que sua analise permaneca reproduzivel e defensavel se o caso escalar.

Armadilhas comuns#

Varios erros se repetem. O mais danoso e uma ma aquisicao: uma imagem borrada capturada em um sistema ao vivo ocupado pode conter estruturas inconsistentes que fazem os plugins falharem ou mentirem, entao prefira snapshots atomicos quando possivel e anote as condicoes de aquisicao. Usar simbolos errados ou ausentes no Volatility 3, especialmente no Linux, produz saida vazia ou sem sentido que analistas as vezes interpretam mal como "nada encontrado" em vez de "ferramenta mal configurada". Tratar a saida de um unico plugin como verdade absoluta ignora que rootkits atacam visoes especificas; sempre verifique de forma cruzada. Analistas tambem superinterpretam os acertos do malfind, que tem causas legitimas como compiladores JIT, entao o contexto importa. Por fim, nao preservar a cadeia de custodia e os hashes pode tornar inuteis achados tecnicos solidos em um procedimento formal. Cada um e evitavel com disciplina: adquirir de forma limpa, verificar simbolos, corroborar entre plugins e telemetria, e documentar sem descanso.

Checklist de investigacao#

Use este checklist para estruturar uma investigacao de memoria. 1) Adquira memoria com uma ferramenta documentada e calcule o hash da imagem imediatamente. 2) Confirme que o Volatility 3 resolve os simbolos corretos antes de confiar na saida. 3) Enumere processos com pslist, psscan e pstree e compare as listas. 4) Recupere linhas de comando com cmdline e sinalize linhagens suspeitas. 5) Reconstrua o estado de rede com netscan e cruze com logs de firewall. 6) Rode o malfind e trie as regioes executaveis-graváveis sem respaldo. 7) Faca verificacoes de visao cruzada para processos, modulos e hooks de syscall escondidos. 8) Extraia processos suspeitos e regioes injetadas para analise mais profunda. 9) Extraia IOCs e varra o parque mais amplo. 10) Corrobore cada achado de memoria com evidencia de EDR, rede e disco, e documente a cadeia de custodia o tempo todo.

Perguntas frequentes#

A forense de memoria consegue detectar malware sem arquivo que nunca escreve em disco? Sim, e essa e uma de suas maiores forcas. Como as tecnicas sem arquivo executam na RAM, uma imagem de memoria muitas vezes captura o codigo injetado, os scripts carregados do interpretador e as conexoes de rede que nao deixam arquivo, algo que a forense de disco perderia por completo. O Volatility 3 e confiavel contra um rootkit ativo que tenta se esconder? Ele e muito mais confiavel do que perguntar ao SO comprometido, porque le estruturas cruas do kernel externamente em vez de confiar nas APIs do sistema operacional. No entanto, um rootkit sofisticado pode tentar corromper tambem essas estruturas, entao a melhor pratica e a analise de visao cruzada e a corroboracao com telemetria independente em vez de confiar em um unico resultado.

Conclusao#

A forense de memoria da aos defensores visibilidade da parte de uma intrusao que nao deixa rastro em disco, e o Volatility 3 torna essa visibilidade acessivel com um fluxo consistente guiado por plugins atraves de Windows, Linux e macOS. O metodo e direto em principio: adquirir memoria de forma solida, resolver os simbolos corretos, enumerar o que o sistema fazia, cacar as discordancias e as regioes executaveis sem respaldo que denunciam injecao e rootkits, extrair artefatos e corroborar tudo com evidencia independente. A disciplina que separa uma investigacao confiavel de uma enganosa e o ceticismo diante de qualquer visao unica e o rigor na aquisicao e na documentacao. Bem praticada, a forense de memoria transforma um instantaneo fugaz da RAM em uma reconstrucao defensavel de um ataque, e frequentemente fornece a evidencia decisiva que os logs e o disco sozinhos nao conseguem.