SPECTRE (Detecção em Memória Volátil)

Nota da subpasta 04 - Ferramentas de Análise de Memória e DFIR, no Capítulo 24 (Ferramentas e Plataformas Atualizadas).
Trata da detecção de ameaças em memória volátil em tempo real: coleta contínua, motor de análise e alerta, como complemento runtime da análise forense post-mortem.
Dialoga com a nota de Volatility 3 da mesma subpasta, que analisa o dump após o fato, e com as notas de Elastic, Wazuh e Splunk da pasta 02, que recebem os alertas produzidos.

1. Contexto e Posicionamento na Biblioteca

O EDR tradicional observa o endpoint de fora da memória: eventos de processo, arquivo, rede e registro, coletados em modo usuário ou por callbacks do kernel. Essa cobertura é ampla, mas cega para o que acontece apenas dentro da memória de processos, e é exatamente nesse espaço que vivem as técnicas mais valiosas do adversário sofisticado: injeção de código, hollowing, carregamento refletivo e credenciais coletadas da memória do LSASS. A detecção em memória volátil em tempo real, representada aqui pelo SPECTRE, fecha esse espaço cego olhando diretamente para dentro da RAM, de forma contínua, enquanto a ameaça ainda está viva.

Antes de avançar, um alerta de vocabulário obrigatório: o nome SPECTRE coincide com a família de vulnerabilidades de CPU descoberta em 2018, e não há relação entre os dois assuntos. Nesta biblioteca, Spectre aparece nas discussões de hardware, e o SPECTRE desta nota é a abordagem de detecção em memória, tema que dialoga diretamente com a nota de Volatility 3 da mesma subpasta: uma olha para dentro da memória durante a execução, a outra analisa a memória preservada após o fato.

2. Detecção Runtime versus Análise Forense Post-Mortem

A diferença fundamental entre as duas disciplinas é o tempo, e dela derivam todas as outras. A análise post-mortem reconstrói o passado a partir de um instante capturado, com profundidade máxima e zero chance de perder o que ficou gravado no dump, mas com a ameaça possivelmente já executada. A detecção runtime observa o presente, com visão fragmentada por amostragem e janelas entre varreduras, mas com a chance de interromper o adversário no meio da cadeia. As duas não competem: o alerta runtime é o que dispara a captura forense que confirma e documenta.

A leitura operacional da tabela é de arquitetura de defesa em camadas. O runtime encurta o tempo de permanência do adversário, que é a métrica que mais importa em resposta a incidentes, e o post-mortem garante que o que foi interrompido seja entendido, mapeado em ATT&CK e convertido em detecção nova. Um SOC que tem apenas o post-mortem descobre intrusões no relatório trimestral; um SOC que tem apenas o runtime contém sem entender e repete o mesmo incidente na semana seguinte.

A tabela também explica por que as duas notas da subpasta seguem a mesma superfície em direções opostas. O SPECTRE trabalha contra o tempo de permanência, e o Volatility 3 trabalha contra a dúvida interpretativa, e um programa de DFIR maduro precisa dos dois laços: o laço curto que contém e o laço longo que documenta, testa e transfere a detecção para a frota inteira.

3. Arquitetura: Coleta Contínua, Motor de Análise e Alerta

A arquitetura típica se organiza em três planos. O plano de coleta contínua vive no host, como agente em modo kernel ou como sensor assistido por virtualização, e produz duas fontes: amostras periódicas das regiões de memória dos processos e um fluxo de eventos de memória, como mudanças de proteção de páginas e carregamentos de módulos não assinados. O plano de análise processa essas fontes em três níveis complementares: assinaturas YARA sobre o conteúdo das regiões, heurísticas estruturais como páginas executáveis sem arquivo de suporte e anomalias na ancestralidade de processos, e pontuação de risco que combina os níveis anteriores. O plano de alerta conecta a análise ao SOC, enriquecendo o alerta com contexto do processo e disparando ações automáticas pré-aprovadas, como a captura imediata de um dump do processo suspeito.

1. Sensor no host amostra regioes de memoria dos processos em cadencia definida
2. Sensor emite eventos de memoria: mprotect executavel, modulo nao assinado, unlinked page
3. Motor de analise aplica assinaturas YARA sobre o conteudo das regioes amostradas
4. Motor aplica heuristicas: RWX sem arquivo de suporte, ancestralidade anomala, entropia alta
5. Motor combina sinais em pontuacao de risco por processo
6. Pontuacao acima do limiar gera alerta enriquecido com processo, regiao e regra
7. Acao automatica pre-aprovada: snapshot de memoria do processo enfileirado para analise
8. Alerta segue ao SIEM e ao caso de IR com a evidencia anexada

O detalhe que separa uma implementação séria de um protótipo está no plano de alerta: a ação automática de capturar a memória do processo no momento do alerta. Sem essa ação, o alerta chega ao analista minutos depois, a região suspeita já foi desalocada, e o caso fica sem evidência técnica além do próprio alerta. Com essa ação, cada alerta vem acompanhado de um dump do processo que o Volatility 3, conforme a nota da mesma subpasta, consome diretamente para confirmar e expandir.

O plano de coleta admite duas arquiteturas de sensor, e a escolha define cobertura e risco ao mesmo tempo. O agente em modo kernel coleta com alta fidelidade e integração natural com o EDR, ao custo de acoplamento com cada versão do sistema operacional; a coleta assistida por virtualização observa a memória de fora da máquina virtual, ao custo de visibilidade parcial e de infraestrutura dedicada de hypervisor. Implementações sérias combinam as duas fontes, usando o evento do agente como gatilho rápido e a amostra profunda da camada de virtualização como confirmação.

4. Casos de Uso: Rootkits e Injeção de Código em Memória

O caso de uso canônico é o rootkit em modo kernel que esconde processos do sistema. Um processo removido da lista encadeada ativa do kernel é invisível para o gerenciador de tarefas, para o EDR que enumera processos e para a maioria das ferramentas de resposta, mas as suas páginas continuam residentes e executando. A varredura de memória em tempo real cruza as duas visões, o que a enumeração estrutural do kernel enxerga contra o que existe fisicamente nas páginas, e a divergência entre elas é a assinatura da ocultação, técnica associada a T1055.003 no ATT&CK.

O segundo caso é a injeção e o hollowing em processos legítimos, o padrão clássico de loader e de frameworks de C2 como o Cobalt Strike com carregamento refletivo. Um svchost.exe legítimo não possui páginas executáveis graváveis sem suporte em arquivo, e a presença de região RWX desacompanhada, somada a ancestralidade anômala, é o gatilho típico. O terceiro caso é a coleta de credenciais na memória, em que a regra de assinatura aponta ferramentas conhecidas de extração do LSASS e as heurísticas apontam acesso anômalo ao processo de autenticação, conexão direta com o uso de Mimikatz em campanhas públicas de ransomware.

O quarto caso é a caça por beacon de C2 residente, e ele conecta a detecção runtime à CTI. Configurações de beacon, chaves e padrões de alocação de frameworks conhecidos viram regras YARA no motor de conteúdo, e cada campanha relevante descrita nos relatórios de intelligence vira atualização do conjunto de regras. É nesse ponto que a detecção em memória deixa de ser genérica e passa a refletir as ameaças que importam para o negócio específico da organização.

5. Sinais de Detecção e Regras de Correlação

Para que o motor de análise produza alerta de qualidade, os sinais precisam ser declarados e combinados de forma consciente, e não empilhados. Os sinais estruturais olham para a geometria da memória do processo, como páginas executáveis graváveis sem arquivo de suporte e módulos carregados fora do caminho padrão. Os sinais de conteúdo aplicam assinaturas YARA sobre as regiões amostradas, e os sinais comportamentais olham para a ancestralidade e para o histórico do processo, como um processo de sistema que começa a abrir sockets depois de uma mudança de proteção. A pontuação de risco existe para combinar sinais fracos isolados em alerta forte quando coincidem no mesmo processo e na mesma janela de tempo.

• Região RWX sem arquivo de suporte em processo que não empacota código por natureza.
• Módulo executável carregado em região desalocável fora do caminho de carregamento padrão do sistema.
• Processo removido da lista ativa do kernel, porém residente e executando nas páginas.
• Mudança de proteção para executável em região que antes guardava dados, seguida de execução.
• Acesso a processo sensível, como o LSASS, por processo sem histórico legítimo de depuração.
• Ancestralidade anômala, como processo de sistema com pai de aplicativo de usuário final.

A correlação com o SIEM transforma o alerta do sensor em detecção de frota. O exemplo abaixo, ilustrativo, agrega eventos de memória por host e processo em janelas de dez minutos, e o padrão de agregação é o que importa, porque os nomes de ActionType variam por produto e versão.

DeviceEvents
| where Timestamp > ago(1d)
| where ActionType in ("MemoryProtectedAllocation", "ReflectiveLoad", "ProcessModifiedAllocatedMemory")
| summarize Eventos = count() by DeviceName, InitiatingProcessFileName, bin(Timestamp, 10m)
| where Eventos >= 3
| order by Eventos desc

O resultado da agregação alimenta duas ações distintas. O host com pontuação isolada entra como caso individual, e o padrão que repete em vários hosts vira caça por hipótese, com a memória confirmando o que a telemetria suspeita, fechando o circuito com as notas de metodologia de hunting da biblioteca.

6. Limitações, Overhead e Ajuste de Cadência

O custo da detecção runtime é estrutural, e não um detalhe de implementação. A leitura contínua da memória de processos consome CPU e banda de memória proporcionais à frequência e à profundidade da varredura, e a análise de conteúdo com assinaturas é o componente mais pesado do ciclo. Além disso, a detecção é probabilística por construção: o que acontece entre duas janelas de varredura pode passar sem ser visto, e a ameaça que permanece menos tempo residente do que a cadência de varredura tem chance real de não ser amostrada. Essas são as limitações que o post-mortem não tem, e é por isso que as disciplinas se complementam em vez de competir.

Há ainda limitações de cobertura e de privacidade que o projeto deve declarar. A complexidade do kernel varia por versão e por sistema operacional, e técnicas que dependem de estruturas internas precisam de atualização a cada ciclo de patches, sob risco de falso negativo silencioso. Na privacidade, a varredura de memória lê o que os usuários têm em RAM, incluindo senhas em formulários e conteúdo pessoal, o que exige tratamento de dados compatível com a LGPD, escopo de coleção documentado e retenção mínima dos conteúdos capturados, um ponto que poucos programas de detecção formalizam antes da primeira auditoria.

O falso positivo merece tratamento de programa, e não de ajuste pontual. A linha de base por grupo de hosts, servidores com JIT, estações de desenvolvedor e desktops padrão, é o que permite calibrar o limiar de pontuação sem abrir janela de detecção, e a amostragem semanal de alertas encerrados como falso positivo produz a curva de qualidade do sensor. Sem esse ciclo, o sensor morre de credibilidade em poucos meses, e o programa perde a única fonte que enxerga dentro da memória.

7. Exemplo de Fluxo de Detecção

O cenário: um host de finanças recebe um documento com macro, e o loader decide carregar o beacon apenas em memória, sem tocar o disco além do próprio documento. O EDR não vê processo filho anômalo com linha de comando suspeita, porque o carregamento é refletivo. O fluxo abaixo descreve a detecção do SPECTRE no desenho típico.

1. Macro executa e injeta o loader no processo host legítimo
2. Evento do sensor: regiao do processo recebe protecao RWX via mprotect
3. Heuristica marca: pagina executavel gravavel sem arquivo de suporte
4. Varredura de conteudo na regiao encontra strings de configuracao de C2
5. Pontuacao de risco ultrapassa o limiar de alerta
6. Alerta enriquecido publicado no SIEM com processo, regiao e regra YARA
7. Acao pre-aprovada: dump do processo capturado e hash registrado
8. Dump processado no Volatility 3: ancestralidade, IOC de C2 e escopo confirmados
9. Contencao do host aprovada pelo IR com evidencia tecnica em anexo

O alerta produzido neste fluxo carrega os campos mínimos para o analista decidir sem voltar ao host, e o exemplo abaixo mostra a estrutura típica desse evento no desenho do SIEM.

{
  "sensor": "MEM-SENSOR-042",
  "host": "WS-FIN-118",
  "detector": "unbacked_exec_region",
  "processo": "svchost.exe (pid 4824)",
  "regiao": "0x1f8a0000 RWX sem arquivo de suporte",
  "assinatura": "beacon_probe_strings",
  "acao_automatica": "snapshot do processo capturado e enfileirado para analise",
  "severidade": "alta"
}

O alerta e o snapshot chegam ao SIEM no mesmo minuto, e é a correlação com o resto da telemetria do host que transforma um evento isolado em caso. O processo suspeito tocou algum arquivo, alguma rede e alguma identidade antes da detecção, e a consulta cruzada entre o alerta de memória e o SIEM é o que revela a cadeia completa, com o snapshot do processo servindo de evidência técnica para o laudo.

8. Erros Comuns e Pontos de Atenção

• Confundir o SPECTRE desta nota com as vulnerabilidades de CPU Spectre e Meltdown; são assuntos completamente distintos e a confusão polui relatórios.
• Tratar o alerta runtime como veredito final; o alerta é o início do caso, e a confirmação técnica vem da análise do snapshot no Volatility 3.
• Fixar cadência de varredura sem medir o overhead real no percentil 95 dos hosts, sacrificando a experiência do usuário sem ganho proporcional de detecção.
• Deixar a captura de snapshot fora da ação automática de alerta, perdendo a evidência volátil mais valiosa do caso minutos depois.
• Ignorar o ajuste de linha de base para software com JIT e empacotamento legítimo, produzindo volume de falso positivo que mata a confiança no sensor.
• Coletar conteúdo de memória sem tratar a dimensão de privacidade, expondo a organização a risco regulatório maior do que o risco mitigado.
• Rodar a detecção em memória como única linha de defesa, desmontando telemetria de EDR e SIEM que sustentam o contexto do caso.
• Esquecer que a janela entre varreduras existe e usar a ausência de alerta como prova de ausência de ameaça no host.
• Aceitar o silêncio do sensor como evidência de host limpo em sensor recém-implantado, sem período de linha de base observado.
• Tratar o snapshot automático do processo como coleta completa do host, quando ele não substitui o dump de memória física integral.

9. Integração com o Restante da Biblioteca

A nota de Volatility 3 da mesma subpasta é o par direto: o SPECTRE gera o alerta e captura o instante, e o Volatility expande o snapshot em laudo com técnica mapeada e IOC extraídos, que alimentam as notas de TIP da pasta 01. Os alertas pousam nas notas de Elastic, Wazuh e Splunk da pasta 02, onde o padrão do alerta vira regra de correlação com o resto da telemetria do host, e as ações pre-aprovadas do fluxo de alerta são o mesmo mecanismo de guardas que a nota de Heptagon desta subpasta formaliza como transições de resposta. O programa purple da pasta 03 valida o sensor da forma correta: emulações do Caldera e do Atomic Red Team com técnicas de injeção em memória verificam se a pontuação de risco dispara no limiar esperado.

A recomendação de desenho para o SOC é posicionar o sensor de memória como fonte de alerta de alta fidelidade e de captura automática de evidência, e não como substituto do EDR. O valor do sensor se realiza no circuito completo, alerta, snapshot, análise, contenção, detecção nova, e é esse circuito, e não a tecnologia isolada, que reduz o tempo de permanência do adversário, métrica que as notas de métricas de detecção e resposta da biblioteca tratam como o indicador central de maturidade operacional.

Uma nota de implementação fecha o desenho: a qualidade da pontuação de risco depende de linha de base por grupo de hosts, e não de um limiar único global. Servidores com empacotamento legítimo, estações de desenvolvedor e hosts de usuário padrão têm assinaturas de memória distintas, e o programa que calibra por grupo reduz o falso positivo sem abrir janela para o adversário, seguindo a mesma lógica de linha de base que as notas de UEBA e de detecção comportamental da biblioteca já defendem para o SIEM.