Caça Orientada por Hipótese (Hypothesis-Driven)

Nota do grupo "17 - Tipos de Threat Hunting", derivada do Capítulo 21 do PDF de referência do Framework CTH.
Este tipo aplica o método hipotético-dedutivo ao hunting e usa o formato SE-ENTÃO definido no controle TH.6.
Papel no programa: dar objetivo claro, escopo definido e resultado interpretável a cada caça, cobrindo lacunas de detecção de forma sistemática.

1. Contexto e Posicionamento no Framework CTH

A caça orientada por hipótese é frequentemente considerada a abordagem mais rigorosa e científica de threat hunting. Ela combina o contexto de ameaças da caça orientada por inteligência com a visibilidade do ambiente da caça comportamental, dentro de um processo estruturado e replicável. O comparativo do capítulo 21 atribui maturidade mínima M2 (Inicial) e frequência recomendada quinzenal, sustentada por um backlog de hipóteses priorizadas na fila de TH.5.

No Framework CTH, este tipo é o grande consumidor do controle TH.6 (formulação de hipóteses estruturadas) e o maior gerador de trabalho para os grupos MAP e AUT. Cada hipótese testada que revela lacuna produz um item para MAP.4 (análise de lacunas de detecção), uma tarefa de detecção para AUT.3 e uma atualização de cobertura para MAP.5. É também o tipo mais adequado para programas em amadurecimento, pois oferece um caminho claro do nível iniciante ao avançado, com progressão mensurável no número de hipóteses executadas e de lacunas fechadas.

2. Definição e Natureza do Tipo

A caça orientada por hipótese testa uma afirmação falsificável sobre o ambiente, no formato SE-ENTÃO: SE a condição descrita for verdadeira, ENTÃO um padrão observável deve aparecer em uma fonte de dados conhecida. O método segue o princípio científico completo: formular a hipótese testável, definir o método de teste, executar, coletar dados, analisar e aceitar ou rejeitar. Essa estrutura garante que cada caça tenha objetivo claro, escopo definido e resultado interpretável, evitando buscas aleatórias que consomem horas sem gerar valor.

A falsificabilidade é o critério que separa hipótese de desejo. Uma afirmação como "o ambiente pode estar comprometido" não pode ser testada; uma afirmação como "SE houve persistência via tarefa agendada criada por processo Office, ENTÃO o evento Sysmon 1 registrará schtasks.exe com processo pai winword.exe nos últimos 90 dias" pode ser confirmada ou refutada com dados. O resultado refutado não é fracasso: ele fecha uma pergunta, valida a telemetria e produz evidência de diligência para auditoria.

3. Origens da Hipótese

O capítulo 21 lista fontes de inspiração múltiplas, e a prática de mercado confirma quatro origens dominantes:

Duas regras mantêm o backlog saudável. Primeira: toda lacuna identificada em simulação deve virar hipótese priorizada, conforme a salvaguarda TH.HH.3; simulação que não gera hipótese é teatro. Segunda: os exercícios trimestrais de red teaming mental da salvaguarda TH.HH.4 devem produzir hipóteses sem depender de inteligência externa, assumindo a perspectiva de um adversário que conhece bem o ambiente.

4. Anatomia da Boa Hipótese

Uma hipótese utilizável tem quatro componentes obrigatórios: condição observável, padrão esperado, fonte de dado e critério de refutação. A condição observável descreve o comportamento do adversário em termos executáveis; o padrão esperado define o que aparecerá nos dados se a condição for verdadeira; a fonte de dado aponta a telemetria exata, com o evento ou campo responsável; o critério de refutação fixa o que encerra a caça sem comprometimento. O template abaixo, alinhado ao registro de TH.6, materializa os quatro componentes:

hipotese:
  id: HIP-2025-014
  statement: >
    SE um adversario estabeleceu persistencia via tarefa agendada criada por
    um processo Office, ENTAO serao observados eventos de criacao de tarefa
    com processo pai winword.exe, excel.exe ou outlook.exe nos ultimos 90 dias.
  tecnica_attack: T1053.005 (Scheduled Task/Job: Scheduled Task)
  condicao_observavel: >
    EventID 1 do Sysmon com Image terminando em schtasks.exe e ParentImage
    em processo Office; reforco opcional com EventID 4698 do Windows.
  padrao_esperado: >
    Zero ocorrencias legitimas esperadas; qualquer ocorrencia exige
    investigacao do comando, do usuario e do destino da tarefa.
  fonte_dados: "SIEM (repositorio Sysmon); cobertura estimada de 92 por cento dos endpoints"
  criterio_refutacao: >
    Nenhuma ocorrencia no escopo e no periodo encerra a caca como refutada,
    com evidencia da cobertura real da fonte no periodo.
  fonte_inspiracao: "Lacuna de cobertura MAP.4 na tatica Persistence"
  resultado_possivel: [confirmada, refutada, lacuna_de_dados]

Hipóteses fracas costumam falhar em um dos quatro componentes. Condição não observável, como técnicas que exigem telemetria inexistente, gera caça impossível; padrão esperado vago impede decisão; fonte de dado não mapeada no inventário TH.1 produz lacuna no meio da execução; e a ausência de critério de refutação transforma a caça em pescaria sem fim.

A variedade de origens é melhor vista em exemplos prontos. Os quatro abaixo, derivados das fontes da seção 3, mostram que o mesmo formato serve a inteligência, a lacuna, o comportamento e a simulação:

5. Fluxo Típico de Execução

O processo completo, conforme descrito no capítulo 21, tem seis etapas encadeadas:

1. Formular a hipótese com mapeamento ATT&CK, usando o template TH.6 e registrando a fonte de inspiração.
2. Definir o escopo temporal e os dados necessários, verificando no inventário TH.1 a cobertura real e em DAT.5 a retenção disponível para a janela desejada.
3. Elaborar as consultas ou técnicas de análise, versionadas no repositório da equipe e testadas previamente no ambiente isolado de TH.3 quando envolvem alto volume.
4. Executar e coletar resultados, registrando contagens exatas, tempo de execução e eventuais ajustes de consulta feitos durante a busca.
5. Analisar e interpretar, classificando cada ocorrência como benigna justificada, suspeita ou indicativa de comprometimento, com evidência vinculada.
6. Documentar e retroalimentar, fechando a hipótese em um dos três estados: confirmada, refutada ou lacuna de dados.

O estado final decide o encaminhamento. Confirmada abre tratamento no grupo IR com contenção imediata. Refutada encerra a pergunta, mas exige a pergunta complementar: a técnica já tem detecção permanente? Se não, a consulta é candidata a AUT.3 e a lacuna é registrada em MAP.4. Lacuna de dados significa que a telemetria não permite responder, e o encaminhamento é para DAT.x, expandindo coleta antes de reprocessar a hipótese.

6. Exemplo Completo de Caça por Hipótese

A equipe identifica no heatmap MAP.2 que a subtécnica T1053.005 não possui nenhuma detecção ativa, e a salvaguarda TH.HH.2 prioriza a hipótese pela combinação de frequência da técnica em incidentes do setor e criticidade dos ativos de persistência. O registro HIP-2025-014 é criado com o template da seção 4, e a execução ocorre no ambiente isolado de TH.3, sobre 90 dias de repositório Sysmon:

let janela = 90d;
Event
| where TimeGenerated > ago(janela)
| where Source == "Microsoft-Windows-Sysmon" and EventID == 1
| where FileName in~ ("schtasks.exe", "at.exe")
| where ParentImage has_any ("winword.exe", "excel.exe", "outlook.exe", "powerpnt.exe")
| project TimeGenerated, Computer, Account, CommandLine, ParentImage, ParentCommandLine
| order by TimeGenerated asc

A consulta retorna duas ocorrências, ambas em estações de marketing, com um comando que registra uma tarefa chamada AtualizacaoAddon a partir de um suplemento legítimo de planilha instalado por um fornecedor há cerca de 80 dias. O ticket do fornecedor e o inventário de software de INS.2 confirmam a instalação autorizada, encerrando a hipótese como refutada para fins de comprometimento. A análise revela, porém, que nenhuma regra cobria o padrão, e a consulta é refinada com whitelist do suplemento e promovida a detecção contínua em AUT.3, com o fechamento registrado em MAP.5.

O ciclo fecha com três entregas: a pergunta de comprometimento respondida com evidência, uma detecção nova permanente e a atualização da cobertura na tática Persistence. É exatamente esse triplo produto que faz do tipo orientado por hipótese o motor de melhoria da base de detecção.

7. Relação com ATT&CK e com a Cobertura MAP.x

ATT&CK fornece o vocabulário e o cadastro de técnicas que sustentam o backlog. Cada técnica da matriz pode gerar múltiplas hipóteses, e a seleção prioriza o cruzamento de três fatores definidos em TH.HH.2: probabilidade do adversário usar a técnica, impacto potencial no ambiente e lacuna de detecção atual. A cobertura existente é lida nos heatmaps de MAP.2, e as lacunas emergem formalmente em MAP.4.

A disciplina de registrar cada hipótese executada com a técnica ATT&CK correspondente transforma o backlog em instrumento de gestão. Com poucos trimestres de dados, o programa sabe quais táticas foram exercitadas, quais hipóteses geraram detecções e onde a telemetria impede a caça. Sem esse registro, a equipe repete hipóteses, ignora táticas inteiras e perde a capacidade de demonstrar evolução em MET.2.

8. Prós, Contras e Quando Usar

Os contras exigem gestão ativa. A qualidade do resultado é diretamente proporcional à qualidade da hipótese, e hipóteses mal formuladas produzem investigações inconclusivas. Algumas técnicas exigem dados e ferramentas que nem toda organização possui, como análise de memória com Volatility em TH.13. E o backlog mal cuidado pode virar rotina vazia, com hipóteses reexecutadas por hábito sem renovação pelas fontes de inspiração da seção 3.

Quando usar: como espinha dorsal quinzenal do programa; após simulações do grupo SIM revelarem lacunas; ao receber relatório de CTI que permite tradução direta em SE-ENTÃO; e na investigação retrospectiva após incidentes. Em momentos de urgência de campanha ativa, o formato SE-ENTÃO ainda vale, mas a priorização de TH.5 acelera o caminho.

9. Salvaguardas por Nível

10. Erros Comuns e Pontos de Atenção

• Formular hipóteses sem critério de refutação. Sem saber o que encerra a caça, a equipe prolonga buscas indefinidamente e o resultado nunca é conclusivo.
• Escolher técnicas sem telemetria. A verificação de cobertura no inventário TH.1 precede a formulação; caçar técnica que os dados não enxergam só produz lacunas.
• Deixar refutações sem produto. Toda refutação deve responder se a consulta vira detecção em AUT.3; refutação sem aproveitamento é trabalho jogado fora.
• Repetir backlog por inércia. A revisão quinzenal de TH.HH.2 existe para renovar o backlog com as fontes da seção 3, não para reciclar os mesmos itens.
• Confundir hipótese com pergunta aberta. O formato SE-ENTÃO com fonte de dado e padrão esperado é obrigatório; perguntas genéricas pertencem à caça exploratória, não a esta.
• Ignorar o estado lacuna de dados. Tratar telemetria insuficiente como refutação corrompe a cobertura registrada em MAP.5 e mascara trabalho pendente em DAT.x.

11. Integração com Outros Controles do Framework CTH

A montante, CTI.7 e CTI.8 fornecem hipóteses derivadas de inteligência, SIM.x fornece lacunas testadas em laboratório e IR.x fornece lições de incidentes. Na execução, TH.10 a TH.15 são as ferramentas de teste da hipótese, e TH.3 protege o ambiente durante consultas pesadas. Na saída, MAP.2 e MAP.4 recebem a atualização de cobertura, AUT.3 recebe as detecções candidatas, DAT.x recebe os pedidos de telemetria nova e CTI.9 recebe o retorno sobre a aplicabilidade da inteligência consumida.

Em métricas, MET.2 deve acompanhar hipóteses executadas por período, distribuição por tática ATT&CK, percentual de lacunas convertidas em detecção e tempo médio de ciclo por hipótese. Esses indicadores, somados ao ranking automático de TH.HH.5 no nível avançado, dão à liderança do programa a visão de que a caça por hipótese não é consumo de horas, e sim fabricação contínua de capacidade de detecção.