TH.13 - Hunting de Memória

Nota do grupo HNT (Threat Hunting) do Framework CTH, seção "15 - Framework CTH - Controles".
Deriva do Capítulo 13, controle TH.13, e complementa TH.11 e TH.12 quando o disco e o fluxo
não bastam. Papel no programa: expor malware fileless, injeção de código e credenciais residuais
por meio de captura e análise forense de memória, de forma cirúrgica e com cadeia de custódia.

1. Contexto e Posicionamento no Framework CTH

O hunting de memória é o controle TH.13 do grupo HNT e representa a camada mais profunda de
investigação disponível no framework. Enquanto TH.11 trabalha com telemetria de processo e TH.12 com
fluxo de rede, a memória é o território onde o adversário executa código que nunca toca o disco:
payloads fileless, shellcode injetado em processo legítimo, credenciais extraídas de LSASS e
ferramentas de pós-exploração carregadas em memória. Nenhuma solução baseada em varredura de disco
enxerga esse estado, e mesmo o EDR cobre apenas parte dele, o que torna a análise de memória a
técnica definitiva para casos de evasão sofisticada.

Este controle tem natureza distinta dos demais da mesma família: não é rotina contínua, é operação
cirúrgica. Coletar memória impacta o host, gera dados sensíveis em volume e exige tempo de análise
especializado. Por isso, o framework posiciona a captura de memória como resposta a hipótese
específica derivada de TH.6, como achado de TH.11 que sugere injeção ou como decisão tática em
incidente ativo gerido por IR.x. O ambiente de TH.3 deve estar preparado com as ferramentas e com
espaço para os dumps, e as coletas planejadas de TH.13.1 são a exceção calendarizada dentro de um
controle que é, por essência, reativo a hipóteses.

2. Por que Caçar na Memória

Quatro motivos sustentam o investimento em análise de memória. O primeiro é o malware fileless, que
executa inteiramente em memória, por exemplo via PowerShell com execução de assembly em streaming, e
não deixa binário no disco para antivírus varrer. O segundo é a injeção de código, em que o payload
habita um processo legítimo, herdando confiança e assinatura do processo hospedeiro, invisível para
listagem de processos convencional. O terceiro são as credenciais em memória: hashes NTLM, tickets
Kerberos, tokens e senhas em texto claro residem em LSASS e em processos de aplicação, e o
adversário que chegou até ali opera com identidade da própria vítima. O quarto é a evasão deliberada
de disco, em que o adversário sabe que a organização monitora arquivos e então escolhe um caminho
que só a memória revela.

Há ainda um motivo operacional que não é sobre o adversário: a memória preserva estado que já sumiu
do disco no momento da coleta. Processos encerrados, conexões ativas, chaves de criptografia, linhas
de comando dos processos em execução e conteúdo de arquivos abertos ficam disponíveis na imagem, e
às vezes só nela. Em investigação de ransomware com fileless delivery, por exemplo, a memória pode
ser a única fonte que identifica o loader inicial.

3. Quando Vale a Coleta

A captura de memória tem custo real e deve ser disparada por critérios claros, definidos antes da
hora do estresse. Os critérios típicos são os seguintes, em ordem de frequência prática.

A regra de decisão é simples: se a hipótese pode ser fechada com telemetria de TH.11 ou TH.12, não
se coleta memória; se a hipótese exige ver o estado vivo do sistema, a coleta é justificada e deve
ser executada com método.

4. Captura Segura de Memória

A captura é a parte mais sensível do controle, porque acontece no host em produção e é irrepetível:
depois do reboot ou da desinstalação do malware, o estado se perde. As ferramentas consolidadas de
mercado incluem o WinPmem para Windows com driver assinado, ferramentas de captura dos kits de DFIR
e soluções de agente forense remotas que podem puxar o dump por canal criptografado. O tamanho do
dump é da ordem da RAM física, o que define o espaço de destino e a duração da operação.

A sequência correta de execução segue a ordem de volatilidade da forense clássica: capturar memória
antes de qualquer coisa que altere o estado vivo, depois registrar data, hora, hash do dump e
operador responsável, e só então lidar com disco, logs e isolamento. A cadeia de custódia começa no
momento da coleta e deve acompanhar o dump do host até o repositório de análise, com hash registrado
em cada transferência. Num incidente ativo, o reboot é a última opção e o isolamento de rede sem
reiniciar é a preferida, justamente para preservar o estado em memória.

O impacto de desempenho precisa ser comunicado: a captura consome recursos por minutos, pode gerar
breve degradação em servidores sensíveis e, em plataformas críticas de missão, deve ocorrer em
janela acordada ou com failover acionado. Em sistemas Linux, que raramente têm agente de EDR
equivalente, a captura por módulo carregado em memória requer ainda mais cuidado com versão de
kernel e assinatura de módulo. Em nenhum cenário a ferramenta de captura é instalada diretamente do
meio comprometido sem verificação prévia de hash.

5. Análise com Volatility 3

O Volatility 3 é a ferramenta padrão de análise de memória e opera com plugins por nome de sistema
operacional. O fluxo analítico típico começa pela identificação do perfil, passa pela listagem de
processos e termina nos plugins de detecção de injeção e de rede. Os comandos a seguir formam o
núcleo da primeira passada analítica.

# Listagem de processos pela estrutura do sistema operacional
vol -f memoria.raw windows.pslist

# Varredura de processos em estruturas órfãs ou ocultas
vol -f memoria.raw windows.psscan

# Detecção de injeção: regiões de memória executáveis com conteúdo anômalo
vol -f memoria.raw windows.malfind

# Conexões e sockets ativos no momento da captura
vol -f memoria.raw windows.netscan

# Linha de comando de cada processo
vol -f memoria.raw windows.cmdline

# DLLs carregadas por processo, com caminho completo
vol -f memoria.raw windows.dlllist --pid 4288

A leitura combinada é o que gera conclusão. Processos que aparecem no psscan mas não no pslist
indicam estruturas desencaixadas, típicas de rootkit ou de processo recém-terminado; cabe ao
analista decidir pelo contexto temporal. Saída de malfind em processo nativo do sistema, como
svchost com caminho correto e código executável anômalo, é o indicativo clássico de shellcode
injetado. Netscan cruzado com os processos do malfind liga a injeção ao destino externo, e o cmdline
fecha a narrativa do achado. A varredura com YARA complementa o fluxo, com regras de malware
conhecido aplicadas direto à imagem.

vol -f memoria.raw yara.YaraScanner --yara-file regras_ameacas.yar

6. Padrões de Injeção Clássicos e Como Aparecem

Dois padrões cobrem a maior parte dos casos reais. O process hollowing cria um processo legítimo em
estado suspenso, desmapeia a imagem original e escreve o payload no lugar, deixando o processo com
nome e caminho íntegros no disco e conteúdo executável completamente diferente em memória. Os sinais
de caça são divergência entre a imagem carregada e o binário do disco, valor de PEB apontando para
caminho diferente do processo real e região RWX no espaço do processo. No Volatility, o par pslist e
psscan com malfind no mesmo PID é a combinação que mais frequentemente evidencia o hollowing.

A DLL injection reserva memória em processo remoto, escreve o caminho da DLL maliciosa e força o
carregamento por thread remota. Os sinais são handle aberto sobre processo de outro dono, chamadas
de memória remota e DLL carregada de caminho não padrão em processo assinado, visível no dlllist. A
variável de decisão para ambos os padrões é a mesma: o código executável dentro do processo pertence
àquele processo ou não. Tabelas de processo legítimo por caminho de imagem, mantidas no baseline de
TH.2, reduzem a análise de centenas de processos a dezenas de candidatos reais.

7. Integração com EDR, Custo e Planejamento

O EDR moderno cobre boa parte da superfície de memória com telemetria de alocação, thread remota e
acesso a LSASS, mas não cobre tudo. Casos típicos em que a análise de memória complementa o EDR são
hosts sem cobertura de agente, evasões dirigidas à lógica do próprio EDR,rootkits de kernel e
incidentes em que o agente foi desativado pelo adversário. O desenho correto é usar o EDR como
sinalizador barato e a memória como confirmadora profunda, e não como rotina concorrente.

O custo precisa estar no planejamento anual: tempo de analista especializado, espaço de
armazenamento da ordem de gigabytes por host, janelas de coleta em servidores e processo formal de
custódia. Coletas rotineiras fazem sentido apenas em hosts de alto valor definidos pelo INS.1; o
restante do parque opera com captura por hipótese. O armazenamento dos dumps merece tratamento de
dado sensível: a memória contém senhas em uso, e-mails abertos, conteúdo de documentos e dados
pessoais de usuários que estavam logados. Os dumps devem ficar em repositório com acesso restrito ao
time de DFIR, criptografia em repouso, retenção definida em política e descarte documentado ao fim
do ciclo, em linha com as exigências de privacidade do DAT.5 e da legislação aplicável.

8. Salvaguardas por Nível de Maturidade

As salvaguardas seguem o padrão de subcontroles do framework, do Básico ao Avançado.

9. Erros Comuns e Pontos de Atenção

O erro mais grave é coletar memória depois de reboot ou de desligamento do host, porque o estado
vivo se perde e a evidência mais rica da investigação desaparece. Em incidente ativo, a pressão de
isolar rápido precisa ser gerida com o roteiro de volatilidade: memória primeiro, rede depois, disco
em seguida, reboot por último. O segundo erro é capturar sem cadeia de custódia, o que destrói o
valor jurídico do dump mesmo quando a análise técnica está perfeita; hash, horário, operador e local
de destino são obrigatórios desde o primeiro minuto.

O terceiro erro é tratar toda saída de malfind como comprometimento. Regiões marcadas como anômalas
aparecem em software legítimo que usa técnicas de empacotamento e proteção de código, e a triagem
exige correlação com processo, caminho e assinatura antes de escalar. O quarto erro é subestimar o
custo e transformar memória em rotina ampla, gerando acúmulo de dumps sem analista para ler, risco
de privacidade sem razão de existir e impacto em produção sem benefício proporcional. A integração
natural deste controle é com TH.11, que gera a hipótese de injeção que dispara a captura, com IR.2,
que consuma o dump como evidência de incidente, e com PLT.x, quando a extração de configurações e
artefatos do malware em memória alimenta a plataforma de inteligência.