SIEM (Splunk, QRadar, ELK) para Hunting

Nota 01 do capítulo 09 (Ferramentas e Plataformas), que abre o bloco de plataformas onde a caça de fato acontece.
Posiciona o SIEM como a primeira plataforma de caça da maioria dos programas e compara Splunk, IBM QRadar e Elastic Security.
Dialoga com as notas 02, 03 e 05 deste capítulo, com a nota 04 do capítulo 02 e com os controles DAT.4, TH.8 e TH.9 do capítulo 15.

1. Contexto e Posicionamento na Biblioteca

Os capítulos anteriores definiram o que caçar e como formular hipóteses; esta nota responde com qual plataforma executar essas hipóteses sobre eventos centralizados. Para a maioria das organizações, o SIEM (Security Information and Event Management) é a primeira plataforma de caça disponível, porque já centraliza logs por dever de detecção, resposta e conformidade. A premissa aqui é direta: o mesmo dado ingerido para alertas serve para caça, desde que a plataforma permita consulta livre, agregações arbitrárias e janelas históricas longas. Três produtos estruturam a comparação: Splunk com a linguagem SPL, IBM QRadar com AQL e Elastic Security com EQL, KQL e Lucene sobre o Elasticsearch.

A nota não substitui o manual de administração de nenhum dos três produtos. O objetivo é duplo: capacitar o hunter a extrair valor de caça de cada plataforma e separar as características que tornam um SIEM caçável de um SIEM meramente operacional. As linguagens de consulta recebem nota própria, a 03 deste capítulo, de modo que os exemplos aqui ilustram capacidades e a tabela final orienta decisões de arquitetura consumidas pelo controle DAT.4 do capítulo 15 e pelo capítulo 10.

2. O que Torna um SIEM Caçável

Quatro características separam um SIEM útil para caça de um SIEM que apenas roda correlações agendadas. A primeira é o acesso a eventos crus: a caça frequentemente precisa do registro original, e não do evento normalizado ou agregado, porque o campo exato que sustenta a hipótese pode não ter sobrevivido ao parse. A segunda é a indexação eficiente: índices invertidos por campo e por token permitem filtros rápidos por host, usuário, processo e hash, enquanto wildcard no início do termo e busca em mensagem inteira custam ordens de magnitude mais caro. A terceira é a retenção em camadas, com dados quentes para o dia a dia e camadas frias consultáveis, porque hipóteses de movimento lateral e de exfiltração raramente cabem em 7 dias.

A quarta característica são as funções de agregação e de série temporal: contagem distinta de valores, agrupamento por campos arbitrários, junção entre conjuntos e detecção de anomalia sobre série são o motor do stack counting e do clustering definidos nos controles TH.8 e TH.9 do capítulo 15. Junto delas vem o esquema normalizado, Splunk CIM, ECS do Elastic e a camada de DSM do QRadar, que permite que a mesma hipótese rode sobre fontes diferentes. Um SIEM sem esquema consistente obriga o hunter a decorar nomes de campo por fonte, e essa memória se perde a cada troca de analista.

A tabela abaixo amarra cada característica ao teste objetivo que o hunter pode aplicar no ambiente antes de assumir que a plataforma suporta a caça planejada. O teste prático vale mais que a ficha técnica, porque as mesmas capacidades se comportam de forma muito diferente conforme o volume real de ingestão e o hardware disponível.

3. Splunk e SPL na Prática

O Splunk guarda eventos em índices e resolve consultas SPL como pipeline de transformações, o que favorece a exploração iterativa: o hunter refina a busca a cada passo sem reescrever a consulta inteira. O modelo de licenciamento é por volume diário ingerido, o que torna as decisões de exclusão de dados parte da estratégia de caça, e não apenas de custo. O exemplo abaixo implementa stack counting para execuções raras nascidas do serviço WMI, hipótese típica contra T1047 do MITRE ATT&CK:

index=sysmon EventCode=1 ParentImage="*\\wmiprvse.exe"
| stats count AS execucoes, dc(host) AS hosts, values(Image) AS filhos BY CommandLine
| where hosts < 3 AND execucoes <= 5
| sort - execucoes

O mesmo padrão se aplica a autenticação: contar contas distintas por origem em janela curta expõe password spraying (T1110.003), e a consulta permanece estável entre versões do produto porque os comandos de estatística mudam pouco. Para janelas longas, o comando tstats sobre data models acelerados responde em segundos o que a busca crua levaria minutos, e é o caminho recomendado para caças agendadas em produção, reservando a busca crua para a investigação profunda do achado. O exemplo abaixo usa tstats para medir a distribuição de processos por host no data model de endpoint, base de qualquer linha de base de software:

| tstats summariesonly=true count FROM datamodel=Endpoint.Processes
    WHERE Processes.process_name="*"
    BY Processes.process_name, Processes.dest
| stats dc(Processes.dest) AS hosts, sum(count) AS execucoes
    BY Processes.process_name
| sort - hosts

A disciplina de caça no Splunk inclui dois hábitos que poupam horas. Primeiro, salvar toda iteração relevante na busca com título da hipótese e comentário, porque o histórico do produto é a memória da caça. Segundo, acompanhar o job inspector nas consultas lentas, que mostra o custo real por comando e revela o gargalo antes que a caça morra por timeout.

4. IBM QRadar e AQL na Prática

O QRadar organiza dados por fonte de log com DSMs (Device Support Modules) e oferece o AQL (Ariel Query Language), uma linguagem de inspiração SQL sobre o banco Ariel, que separa eventos e fluxos em bancos distintos. A força do AQL na caça está nas funções de contexto, como LOGSOURCETYPENAME, REFERENCESETCONTAINS e XFORCEURL, que aproximam consulta analítica e listas de referência mantidas pela plataforma. O exemplo abaixo cruza falhas de logon do Windows por origem, o mesmo raciocínio de spray do exemplo do Splunk:

SELECT sourceip AS origem,
       COUNT(DISTINCT username) AS contas,
       COUNT(*) AS tentativas
FROM events
WHERE LOGSOURCETYPENAME(devicetype) ILIKE '%Microsoft Windows Security%'
  AND "Event ID" = 4625
GROUP BY sourceip
HAVING COUNT(DISTINCT username) > 10
LAST 24 HOURS

Duas particularidades de caça no QRadar merecem registro permanente na biblioteca do time. Primeiro, o desempenho depende do uso de campos indexados e da janela temporal dentro da própria cláusula WHERE, porque consulta sem janela varre o Ariel inteiro e compete com o motor de ofensas. Segundo, as reference sets funcionam como ponte natural entre o TIP e a caça: o hunter consulta REFERENCESETCONTAINS('feed_c2', destinationip) para verificar infraestrutura de inteligência no tráfego histórico, tema que a nota 04 deste capítulo desenvolve. O exemplo abaixo audita quantas conexões de saída do mês casaram com o conjunto alimentado pelo TIP:

SELECT destinationip, COUNT(*) AS conexoes,
       COUNT(DISTINCT sourceip) AS origens
FROM flows
WHERE REFERENCESETCONTAINS('feed_c2', destinationip) = true
GROUP BY destinationip
ORDER BY conexoes DESC
LAST 7 DAYS

O QRadar também guarda dados de fluxo (flows) separados dos eventos, o que permite caçar comunicação sem conteúdo de log de firewall, inclusive quando o equipamento de borda não entrega telemetria suficiente. O custo dessa separação é a duplicidade de linguagem: parte das consultas roda em events, parte em flows, e o hunter precisa escolher o banco certo antes de escrever a primeira linha.

5. Elastic Security: EQL, KQL e Lucene

O Elastic Security roda sobre o Elasticsearch com o esquema ECS (Elastic Common Schema) e oferece três camadas de consulta que cumprem papéis distintos. A barra de busca do Kibana aceita KQL (Kibana Query Language) para filtros rápidos do dia a dia e Lucene clássica para casos especiais como regexp e proximidade; o motor EQL (Event Query Language) executa correlações sequenciais por host, exatamente o tipo de consulta que sustenta hipóteses de cadeia de execução. O exemplo abaixo em EQL procura o par clássico de reconhecimento seguido de execução remota, com janela máxima de dois minutos:

sequence by host.id with maxspan=2m
  [process where event.action == "start" and process.name == "net.exe" and process.args : "group*"]
  [process where event.action == "start" and process.parent.name == "wmiprvse.exe"
   and process.name : ("whoami.exe", "net.exe")]

O filtro equivalente em KQL, para a barra do Kibana, cobre o triage imediato do mesmo padrão:

event.category:process AND process.name:powershell.exe AND process.command_line:(*-enc* OR *-w*hidden*)

Para séries temporais, o framework de agregações do Elasticsearch, exposto no Kibana via Lens e TSVB, entrega histogramas e contagens por campo com boa latência em janelas longas. A ressalva operacional é o custo de administração do cluster em deployments on-premise, que recai sobre a própria equipe de segurança e é retomado na seção de limitações.

O Elastic também possui o recurso de threat intel matching, que cruza automaticamente índices de inteligência com os eventos de endpoint e rede usando as mesmas regras do ECS. Para caça, o uso correto desse recurso é gerar o par evento e indicador como semente, e depois abrir a investigação manual com os logs crus do período, porque o casamento automático de IOC é ponto de partida e nunca veredito.

6. Comparação e Critérios de Escolha

A tabela abaixo resume as diferenças que importam para caça, não para material de venda. O critério decisivo raramente é a linguagem: é o dado disponível, o custo de retenção e a maturidade operacional do time que administra a plataforma.

A escolha racional combina o SIEM existente com o controle DAT.4: melhor uma plataforma bem ingerida e bem normalizada do que duas plataformas metade configuradas. Times maduros usam o SIEM como fachada de consulta e mantêm repositório de consultas versionadas, tema da nota 03, para reduzir a dependência de sintaxe específica e sobreviver à troca de produto.

7. Limitações do SIEM para Caça e Complementos

O SIEM tem limites estruturais que o hunter precisa reconhecer em vez de forçar. O primeiro é econômico: o licenciamento por volume pressiona a exclusão exatamente dos dados verbosos que a caça ama, como telemetria completa de processo e logs de proxy, e o resultado é um índice bom para alertas e cego para hipóteses. O segundo é a retenção, que costuma ficar entre 30 e 90 dias em camada quente, enquanto hipóteses com incubação longa exigem arquivo frio ou data lake. O terceiro é analítico: estatística avançada, aprendizado de máquina e enriquecimento programático são incômodos dentro de uma linguagem de consulta e naturais em notebook, tema da nota 05 deste capítulo.

Os complementos formam o portfólio real de caça e dividem o trabalho por papel. A console do EDR cobre a telemetria de endpoint com contexto de processo que o SIEM raramente recebe completo, como detalhado na nota 02. O data lake sobre armazenamento de objeto, com eventos em parquet consultados por Athena, Spark ou DuckDB, estende a retenção a meses por custo baixo. O notebook estende a análise estatística, e o sensor de rede com pcap retido fecha o ciclo quando o endpoint não testemunha o comportamento. O desenho maduro usa o SIEM como hub de correlação e as demais plataformas como camadas de profundidade sobre o mesmo relógio sincronizado.

O exemplo abaixo mostra a mesma lógica de stack counting da seção 3 executada sobre um data lake local com DuckDB, que carrega parquet direto do disco e responde em segundos janelas de meses, fora do alcance do licenciamento do SIEM:

SELECT process_name, COUNT(*) AS execucoes,
       COUNT(DISTINCT hostname) AS hosts
FROM read_parquet('dados/edr/2025/*.parquet')
WHERE parent_name LIKE '%wmiprvse.exe'
GROUP BY process_name
HAVING COUNT(DISTINCT hostname) < 3
ORDER BY execucoes DESC

8. Erros Comuns e Pontos de Atenção

• Caçar apenas na camada quente; efeito: hipóteses de incubação longa encerradas como sem resultado quando o dado está no arquivo frio; correção: definir por PIR quais índices têm retenção longa e testar a consulta no período completo.
• Confundir esquema com dado; efeito: consulta correta no CIM que não encontra nada porque a fonte nunca foi mapeada para o esquema; correção: verificar cobertura de parse e de campos por fonte antes de culpar a hipótese.
• Deixar parse failures invisíveis; efeito: percentual relevante dos eventos cai no índice de erros e nunca aparece na caça; correção: rotina periódica de volume de falhas de parse por sourcetype com meta de correção.
• Consultar sem janela temporal; efeito: varredura completa do índice, disputa de recursos com produção e consultas mortas por timeout; correção: cláusula temporal sempre presente, mesmo nas caças exploratórias.
• Tratar agregado como prova; efeito: veredicto baseado em resumo que esconde o evento individual que desmentiria a hipótese; correção: todo encerramento volta ao evento cru com timestamp, host e campos de contexto.
• Rodar caças pesadas no cluster de produção sem isolamento; efeito: degradação da resposta a incidentes que roda na mesma plataforma; correção: agenda dedicada, réplicas de busca e caças pesadas fora do horário de pico.

9. Integração com o Restante da Biblioteca

Esta nota é a camada de plataforma do capítulo 09: a nota 02 cobre o EDR como fonte e como plataforma, a 03 formaliza as linguagens usadas aqui e a 05 estende a análise para notebooks. O desenho de ingestão e as decisões de retenção vivem no controle DAT.4 e na nota 13 do capítulo 02, as técnicas de stack counting e clustering aplicadas nos exemplos são os controles TH.8 e TH.9, e a promoção de caça confirmada em detecção permanente é o trabalho do capítulo 18. As métricas de cobertura e de tempo de caça alimentam o capítulo 11.

Um ganho composto fecha a nota com prática concreta: mantenha, por plataforma, um catálogo de consultas de caça com hipótese associada, dono, custo medido e data da última execução. O catálogo transforma o SIEM de ferramenta individual em ativo institucional, reduz o retrabalho quando o analista muda e entrega ao capítulo 11 números reais de custo por caça, em vez de estimativas de planilha.