Começar threat hunting no SOC exige três elementos na ordem certa: telemetria centralizada com retenção suficiente, hipóteses escritas a partir de inteligência aplicável ao seu ambiente e um ciclo que converta cada caça em detecção permanente. A ferramenta entra por último. A pesquisa anual da SANS com equipes de segurança mostra que a falta de analistas qualificados é citada por 61% dos respondentes como a principal barreira para o sucesso dos programas de caça, o que torna o desenho do processo mais decisivo do que o orçamento de ferramentas.
Este guia organiza o ponto de partida em blocos práticos: o que separa a caça da monitoração reativa, quais dados garantir antes de comprar qualquer coisa, como formular hipóteses testáveis e como rodar o ciclo em passos curtos e mensuráveis.
O que a caça resolve
Monitoração tradicional espera o alerta disparar; threat hunting parte do pressuposto de que o adversário já está dentro e de que as regras existentes não o viram. A caça usa informação nova sobre dados já coletados para achar sinais de comprometimento que escaparam da detecção. Quando a hipótese se confirma, o caso vira incidente e entra no processo de resposta; quando não se confirma, o aprendizado vira detecção nova ou baseline mais preciso. Esse duplo retorno é o argumento econômico do programa: cada caça melhora a biblioteca de regras do SOC.
O advisory conjunto das autoridades de cibersegurança dos Estados Unidos, Canadá, Reino Unido, Austrália e Nova Zelândia trata a investigação como sequência de coleta e cuidado operacional: recomenda coletar primeiro artefatos, logs e dados e só depois mitigar, evitando alertar o adversário de que sua presença na rede foi descoberta. A mesma disciplina vale dentro do SOC durante uma caça: preservar o contexto antes de qualquer ação de contenção.
Dados antes de ferramentas
Antes de escolher plataforma, garanta a telemetria que responde às perguntas mais prováveis do seu ambiente. O conjunto mínimo para um primeiro ano:
- Eventos de processo com linha de comando (Sysmon Event ID 1 ou equivalente do EDR), cobrindo servidores e estações de trabalho;
- Autenticação: logons de rede, NTLM, Kerberos, VPN e identidade na nuvem, incluindo falhas e padrões fora de horário;
- Proxy e DNS, com destino, URI e user-agent, para achar beaconing e exfiltração em baixa frequência;
- Persistência e execução agendada: tarefas agendadas, run keys, serviços e assinaturas WMI.
Retenção importa tanto quanto coleta: hipóteses sobre permanência de semanas exigem poder voltar no histórico. Com esse alicerce, hunts sobre reuso de credencial como o movimento lateral por pass-the-hash ou sobre o comportamento de ransomware como o Gunra saem do campo teórico e viram consultas concretas no SIEM.
Hipóteses orientam a busca
Boa hipótese liga uma técnica adversária a um artefato observável nos seus dados. Segundo a mesma pesquisa da SANS, técnicas de living off the land apareceram em 76% dos ataques de estado-nação relatados pelas equipes que responderam ao estudo: adversário que usa binários nativos do sistema não gera hash malicioso, mas gera padrão de execução anômalo, e é esse padrão que a caça persegue. Exemplos de hipóteses iniciais e onde testá-las:
| Hipótese inicial | Técnica ATT&CK | Fonte de dados |
|---|---|---|
| Contas criadas com padrão fora do normal de nomes | Criação de conta (T1136) | Eventos de directory services e Windows 4720 |
| Beaconing HTTPS de baixa frequência para hospedagem nova | Canal de aplicação web (T1071.001) | Logs de proxy e firewall com destino e user-agent |
| PowerShell codificado em Base64 em estações de usuário | Interpreter de comando (T1059.001) | Eventos de processo com linha de comando do EDR |
| Autenticação NTLM fora dos hosts esperados | Uso alternativo de material de autenticação (T1550) | Logs de autenticação de DC e sensor de rede |
Ciclo de caça em seis passos
- Escolha uma hipótese por caça, derivada de inteligência aplicável: relatório de fornecedor, advisory de autoridade ou incidente anterior do próprio ambiente.
- Confirme a cobertura: os dados necessários existem, estão centralizados e a retenção alcança o período que a hipótese cobre.
- Estabeleça o baseline do comportamento normal antes de buscar o anômalo; sem linha de base não existe anomalia, existe achismo.
- Execute e filtre: rode a consulta, remova o benigno conhecido e documente cada falso positivo recorrente como whitelist candidata.
- Feche o resultado: incidente confirmado segue para resposta; hipótese refutada gera nota curta com o que foi descartado e por quê.
- Converta em detecção: caça bem-sucedida vira regra monitorada, com medição de falso positivo antes de entrar em produção.
Maturidade evolui por etapas
No modelo mais citado do mercado, o Hunting Maturity Model proposto por David Bianco descreve categorias crescentes de maturidade de caça, começando em equipes que dependem apenas de relatórios de terceiros e terminando em programas que criam processos, ferramentas e dados próprios. O erro clássico do SOC iniciante é pular direto para o topo: querer automação e ciência de dados sem ter a telemetria de base coberta. Um primeiro ano realista combina hipóteses simples, uma por quinzena, executadas por um analista sênior com apoio do time de triagem, e avaliação trimestral do que virou detecção permanente.
Métricas que sustentam o programa
Meça o que o time controla: hipóteses executadas por trimestre, taxa de conversão em detecção nova, tempo médio gasto por caça e cobertura de fontes de dados, contando quantas hipóteses foram abortadas por falta de telemetria. Registre também as caças negativas: saber o que foi descartado, e por qual motivo, evita retrabalho e acelera o treinamento de analistas novos. Programa sem métrica visível perde orçamento no primeiro ciclo de cortes; programa que mostra quantas detecções saíram de caças justifica a próxima contratação.
