O que é Threat Hunting (Proativo vs Reativo)

Nota 01 do capítulo 06 - Fundamentos de Threat Hunting. Define threat hunting, distingue a caça da detecção por alerta e da resposta a incidente e organiza a prática no espectro proativo-reativo.
Estabelece o pressuposto operacional de todo o capítulo: caçar como se o adversário já estivesse dentro do ambiente.
Dialoga com a nota 01 do capítulo 01 (definição de CTI), com a nota 02 do capítulo 03 (IOA) e com os grupos HNT, RES e MET do capítulo 15.

1. Contexto e Posicionamento na Biblioteca

A primeira metade da biblioteca ensinou a produzir inteligência sobre adversários que operam fora e dentro do ambiente; este capítulo abre a metade que usa essa inteligência ativamente dentro de casa. Threat hunting é a prática de buscar, de forma proativa, iterativa e dirigida por hipótese, evidências de atividade adversária que os controles automatizados não capturaram. Sem uma definição precisa, o termo é absorvido pelo marketing e passa a cobrir tudo, de varredura de vulnerabilidade a resposta a incidente, e aí perde valor operacional. Esta nota fixa o conceito, as fronteiras com as disciplinas vizinhas e o pressuposto que dá origem à prática.

As quatro notas seguintes constroem sobre esta base. A nota 02 formaliza a hipótese como instrumento central da caça; a nota 03 desenha o perfil de competências de quem executa; a nota 04 organiza o trabalho no ciclo de caça; e a nota 05 mede a maturidade com que a organização sustenta tudo isso. No capítulo 15, os grupos HNT e MET do Framework CTH assumem que o leitor já sabe distinguir caça de detecção por alerta, e é exatamente essa distinção que a seção 3 constrói.

2. Definição de Threat Hunting

Threat hunting é a busca humana, dirigida por hipótese e apoiada em telemetria, por atividade adversária que sobreviveu às camadas automatizadas de defesa. Cada palavra da definição carrega peso operacional. Busca humana significa que intuição treinada e contexto de negócio participam do processo, ainda que as consultas sejam escritas em linguagem de máquina e possam ser reexecutadas por agendamento. Dirigida por hipótese significa que a caça parte de uma afirmação falsificável sobre o ambiente, e não de uma navegação aleatória por dashboards. Apoiada em telemetria significa que, sem dados de endpoint, rede, identidade e nuvem adequadamente coletados, caçar se transforma em adivinhação com aparência de método.

O objetivo da caça não é resolver incidentes em produção, e sim reduzir a incerteza sobre o ambiente e alimentar o ciclo de detecção. Quando a caça encontra atividade real, ela abre um incidente e entrega o bastão para a resposta; quando não encontra, produz evidência de cobertura, refina detecções e documenta o comportamento normal do negócio. Em ambos os desfechos o programa acumula valor, e é por isso que programas maduros tratam a caça como função permanente, e não como projeto emergencial acionado depois de manchetes.

3. Caça, Detecção por Alerta e Resposta a Incidente

As três disciplinas convivem na mesma operação e se confundem com facilidade, porque usam ferramentas parecidas e dados comuns. A distinção não é hierárquica, é funcional: cada uma responde a uma pergunta diferente e produz um artefato diferente. A tabela abaixo delimita as fronteiras:

Duas fronteiras merecem reforço. Triagem de alerta não é caça, mesmo quando o analista aprofunda a consulta além do alerta original, porque o ponto de partida continua sendo uma regra que já conhecia o padrão; caça começa onde o padrão ainda não foi codificado. E caça não é resposta a incidente, mesmo que encontre um incidente: a caça termina na abertura do caso com contexto rico, e o processo de resposta, com autoridade de contenção e critérios legais, assume a partir dali. O capítulo 13 do Framework CTH, no grupo RES, cobre essa passagem de bastão com detalhe.

4. O Pressuposto do Adversário Dentro

A caça nasce de um pressuposto simples e desconfortável: parte da atividade adversária relevante não dispara alerta. Relatórios públicos de mercado, como o M-Trends da Mandiant, situam o dwell time mediano global na casa de dias a semanas, com casos notórios de meses, e esse número é a medida do descompasso entre o que as defesas automatizadas veem e o que o adversário faz. Ransomware barulhento encerra o próprio ciclo em horas, mas intrusões de espionagem e de fraude silenciosa vivem justamente do intervalo em que ninguém as procura.

Os motivos técnicos do descompasso são conhecidos e estruturais. Regras e assinaturas descrevem o passado, enquanto o adversário moderno usa ferramentas nativas do sistema, como certutil, mshta e PowerShell, que são legítimas na mão do administrador e hostis na mão do invasor; o binário é o mesmo, e a regra precisa capturar contexto, não aparência. Adversários como APT29 e FIN7 têm documentado em relatórios públicos o uso de infraestrutura renovada, canais criptografados e abuso de ferramentas administrativas exatamente para ficar abaixo do limiar de alerta. Nenhum fornecedor resolve isso sozinho, porque o limiar de alerta é também um compromisso com a capacidade de triagem do SOC: baixar o limiar aumenta a cobertura e afoga a fila.

O pressuposto muda o planejamento de três formas práticas. Primeiro, o ambiente é tratado como potencialmente comprometido por padrão, e a pergunta deixa de ser "temos intrusão?" para virar "quais TTPs dos nossos adversários de referência conseguiríamos ver hoje?". Segundo, a telemetria passa a ser avaliada pela pergunta que ela permite responder, e não pelo volume que produz, o que conecta a caça ao grupo DAT do capítulo 15. Terceiro, o não achado deixa de ser vazio e passa a ser evidência, porque demonstra, com consulta registrada e janela coberta, que um comportamento específico não ocorreu.

5. O Espectro Proativo-Reativo

Proativo e reativo não são categorias binárias de produto, e sim extremos de um espectro de postura em que cada atividade de segurança ocupa um ponto. A caça se situa do lado proativo do incidente, mas não é a atividade mais proativa da esteira, porque ainda depende de dados que só existem se a coleta e a inteligência os prepararem. A tabela posiciona as atividades:

Ler o espectro evita dois erros de posicionamento. O primeiro é vender a caça como reativa "melhorada", o que a condena a competir por hora de analista com a fila de alertas e a morrer no primeiro trimestre cheio. O segundo é vendê-la como substituta do SOC, o que ignora que a caça precisa da fila de alertas como fonte de hipóteses derivadas e de baselines de ruído. A posição correta é a de função proativa permanente que consome inteligência, produz detecções e reduz o trabalho reativo futuro.

6. Casos de Uso e Mitos Comuns

6.1 Casos de Uso Recorrentes

Os casos abaixo concentram a maior parte do valor entregue por programas de caça em operação real:

• Fechar lacunas de cobertura: o heatmap ATT&CK do grupo MAP mostra táticas sem detecção, e a caça verifica se a lacuna é de telemetria ou de regra, devolvendo o diagnóstico correto ao capítulo 18.
• Investigar por campanha: um relatório de CTI descreve TTPs de um ator relevante aos PIRs, e a caça traduz o relatório em consultas sobre o próprio ambiente antes que exista alerta público pronto.
• Descobrir mudança silenciosa no ambiente: contas com privilégio novo, serviços instalados fora da janela de mudança e relações pai-filho raras aparecem no empilhamento antes de virarem alerta.
• Enfrentar o living-off-the-land: ferramentas nativas com assinatura válida atravessam antivírus, e a caça por contexto de execução enxerga o que a assinatura não distingue.
• Reduzir dwell time de intrusões antigas: após incidente em organização do mesmo setor, a caça reexecuta as TTPs conhecidas sobre os últimos 90 dias de telemetria própria.
• Apoiar o purple teaming: a caça confirma se a técnica simulada pelo red team deixou rastro nos dados e se a detecção correspondente a capturou, fechando o laço com o capítulo 19.

6.2 Mitos que Atrapalham Programas Iniciantes

Os mitos abaixo aparecem em quase toda discussão inicial sobre caça, e desmontá-los cedo economiza ciclos de patrocínio:

• "Caçar é comprar plataforma": ferramenta acelera consulta e registra evidência, mas hipótese, método e telemetria vêm antes; a nota 05 mostra que plataforma não muda nível de maturidade.
• "Caça substitui o SOC": caça não é triagem 24x7; é função distinta, com cadência própria, que convive com o fluxo de alertas em vez de competir com ele.
• "Caça exige IA": estatística simples de agregação e empilhamento resolve a maior parte das caças iniciais; aprendizado de máquina entra no grupo AUT do capítulo 15 como aceleração, não como pré-requisito.
• "Caça sem achado foi desperdício": hipótese fechada gera baseline, refina detecção e registra evidência de cobertura, e é o desfecho mais comum em ciclos saudáveis.
• "Caça é intuição": intuição sugere, hipótese estrutura; sem registro e falsificação, é passeio pelos dados.
• "Só empresa grande caça": ambientes pequenos caçam com consultas agendadas no SIEM e no EDR disponível; a escala muda a logística, não o método.

7. Exemplo Prático: O Alerta que Não Dispara e a Caça que Encontra

O cenário usa o ambiente de estudo da biblioteca: distribuidor de médio porte, EDR em todas as estações, SIEM com telemetria de processo e rede. Meses antes, a regra que alertava sobre certutil.exe com o parâmetro -urlcache gerou dezenas de falsos positivos causados pela ferramenta legítima de implantação, e foi ajustada para ignorar execuções filhas do agente de implantação. O ajuste foi tecnicamente correto e criou, sem ninguém perceber, um ponto cego: qualquer certutil cujo processo pai não fosse o agente deixou de ser olhada por humano.

Durante a campanha de phishing mapeada como CLUSTER-2025-041-PHISH no capítulo 05, um anexo de "nota fiscal" aberto no Outlook do host PC-FIN-114 disparou wscript.exe, que executou mshta.exe e depois certutil.exe para baixar a segunda etapa. Nenhum alerta disparou: a regra do SIEM só observava o pai do certutil, e o EDR não classificou a primeira execução de mshta como hostil, porque o binário é assinado pela Microsoft. A caça mensal de empilhamento, que não parte de definição de malicioso e sim de raridade inexplicada, encontrou a cadeia na consulta abaixo:

// Caça de empilhamento: pares pai-filho raros com binarios LOLBin nos ultimos 30 dias
DeviceProcessEvents
| where Timestamp > ago(30d)
| where FileName in~ ("certutil.exe", "mshta.exe", "wscript.exe", "regsvr32.exe", "rundll32.exe")
| summarize Execucoes = count(), Hosts = dcount(DeviceName),
            PrimeiroVisto = min(Timestamp), UltimoVisto = max(Timestamp)
    by InitiatingProcessFileName, FileName
| where Hosts <= 3
| order by Execucoes asc

O resultado apontou OUTLOOK.EXE como pai de wscript.exe com duas execuções em um único host, volume que o baseline do parque confirmou como anômalo, pois nenhuma outra estação registrava a combinação. A segunda consulta reconstituiu a linha do tempo da estação e entregou à resposta um caso aberto com contexto rico, e não um alerta frio:

// Linha do tempo do host suspeito apontado pelo empilhamento
DeviceProcessEvents
| where DeviceName == "PC-FIN-114"
| where Timestamp between (datetime(2025-05-12 08:00) .. datetime(2025-05-12 20:00))
| project Timestamp, AccountName, InitiatingProcessFileName, FileName, ProcessCommandLine
| order by Timestamp asc

O desfecho ilustra o papel do hunter como ponte entre caça e detecção. A resposta contém o host e inicia o incidente; o hunter converte o padrão descoberto em detecção permanente, para que o mesmo comportamento nunca mais dependa de humano:

title: Interpretador de Script ou Binario de Sistema Iniciado por Processo do Office
id: 7b4f3c1e-8a2d-4e55-9c31-1f6d2a0b9e77
status: experimental
description: Cadeia de processo do Office abrindo wscript, mshta ou certutil, observada
  na campanha CLUSTER-2025-041-PHISH e ausente do baseline do parque
logsource:
    category: process_creation
    product: windows
detection:
    selection_parent:
        ParentImage|endswith:
            - '\OUTLOOK.EXE'
            - '\WINWORD.EXE'
            - '\EXCEL.EXE'
    selection_child:
        Image|endswith:
            - '\wscript.exe'
            - '\mshta.exe'
            - '\certutil.exe'
    condition: selection_parent and selection_child
level: high

8. Erros Comuns e Pontos de Atenção

Os erros abaixo custam caro em programas iniciantes e aparecem com regularidade em avaliação de maturidade:

• Chamar de caça a triagem de alertas ou a resposta a incidentes: dilui as métricas do programa e confunde o patrocinador sobre o que está financiando.
• Caçar sem telemetria mínima: a primeira caça de um programa é um inventário de dados, como define a salvaguarda TH.1 do capítulo 15.
• Executar caça sem registro: consulta sem caderno de caça não pode ser reexecutada, auditada nem convertida em detecção.
• Confundir caça com pentest: o pentest valida exploração de fora para dentro; a caça valida presença que já pode existir de dentro para dentro.
• Tratar caça como projeto emergencial: sem cadência, dono e métrica, conforme o grupo MET, a prática morre na primeira semana cheia do SOC.
• Medir caça apenas por achados: o programa que só celebra incidente encontrado passa a pressionar por achados, e achados pressionados viram achados inflados.

Um ponto final de atenção é a relação entre caça e detecção automatizada. Caça não é plano B permanente para o que a detecção não vê: cada descoberta que sobrevive ao ciclo precisa virar regra, baseline ou telemetria nova, para que o mesmo padrão nunca mais precise de humano. O programa que acumula descobertas sem convertê-las está, na prática, terceirizando a detecção para a memória das pessoas, e memória institucional não escala, não audita e não sobrevive a troca de equipe.

9. Integração com o Restante da Biblioteca

Esta nota é o contrato conceitual do capítulo 06 e conversa com os dois lados da esteira. A montante, a nota 01 do capítulo 01 define a inteligência que vira insumo de hipótese, a nota 02 do capítulo 03 define os IOA que a caça procura e o capítulo 05 produz os relatórios que alimentam a caça por campanha. A jusante, a nota 02 formaliza a hipótese, a nota 03 define quem executa, a nota 04 organiza o ciclo e a nota 05 mede a maturidade; os capítulos 07 e 08 detalham metodologias e técnicas, e o capítulo 09 cobre as ferramentas citadas aqui apenas de passagem.

Para o estudante, o exercício recomendado é reproduzir o cenário da seção 7 no laboratório: executar a cadeia Office para wscript para certutil em máquina de teste com Sysmon ou EDR de avaliação, rodar a consulta de empilhamento e escrever a detecção Sigma correspondente. O artefato final, uma detecção nascida de caça documentada, é a menor unidade de valor do programa inteiro, e é exatamente o tipo de evidência que a nota 05 e o grupo MET do capítulo 15 pedem para sustentar o investimento no programa.