Geração de Hipóteses

Nota 02 do capítulo 07 (Processo e Metodologias de Hunting), transformando a preparação da nota 01 em perguntas testáveis contra a telemetria.
Cobre as fontes de hipóteses, o brainstorming estruturado e a decon de relatos de inteligência, a formulação SE-ENTÃO com evidência esperada, a priorização por custo e valor e o backlog de hipóteses.
Consome inteligência dos capítulos 01 a 05 e o plano de caça da nota 01, e alimenta a coleta da nota 03 e a execução da nota 04.

1. Contexto e Posicionamento na Biblioteca

A hipótese é a unidade mínima do hunting orientado a hipótese: uma afirmação específica, testável e falsificável sobre como um adversário poderia operar no ambiente. Caças sem hipótese degradam em navegação curiosa pelos logs, e hipóteses mal formuladas produzem consultas genéricas que confirmam qualquer resultado e não sustentam nenhuma conclusão. Esta nota organiza o passo do processo em que o hunter gera, formula e prioriza hipóteses antes de gastar horas de consulta, conectando a inteligência produzida nos capítulos anteriores ao trabalho prático sobre os dados do ambiente.

Na biblioteca, a nota é consumidora direta da Pirâmide de Dor e do MITRE ATT&CK do capítulo 04, dos TTPs do capítulo 03 e dos relatórios de inteligência do capítulo 05, porque todas essas peças fornecem comportamentos observáveis que cabem em uma hipótese. Dialoga com a Análise de Hipóteses Concorrentes do capítulo 05, que exige gerar mais de uma explicação para o mesmo fenômeno antes de escolher, e com o controle de formulação de hipóteses estruturadas do capítulo 15, que esta nota detalha como procedimento operacional. À frente, cada hipótese aprovada vira um plano de caça preenchido no formato da nota 01, e cada hipótese engavetada entra no backlog gerido na seção 6. Em métodos públicos, a nota dialoga com o TaHiTI, que organiza a caça a partir da inteligência, e com o ciclo do PEAK, que separa caça de hipótese, de dados e de modelo, porque ambos confirmam que a qualidade da caça se decide na formulação da pergunta.

2. Fontes de Hipóteses

Hipóteses de qualidade nascem de fontes diversas, e a dependência de uma única fonte produz uma carteira viciada de caças. A inteligência de ameaças fornece o insumo mais direto: relatos sobre APT29, APT41, FIN7, Lazarus, LockBit ou Scattered Spider descrevem técnicas concretas que podem ser traduzidas em perguntas sobre os próprios dados. A matriz de cobertura do ATT&CK fornece o insumo complementar: técnicas relevantes para o setor em que a organização não tem detecção nem registro de caça são candidatas naturais, porque caçá-las fecha lacuna real e não apenas repete cobertura existente.

A conectividade com o capítulo 01 passa pelos PIRs e EEIs: hipóteses de valor são as que respondem, direta ou indiretamente, a uma pergunta de inteligência que a organização já declarou prioritária. Uma hipótese sobre uso de contas de serviço pode responder a um PIR de risco de credencial exposta ou a um PIR de campanha ativa de ransomware, e a mesma caça ganha patrocínio diferente conforme o PIR que atende. Antes de aceitar hipótese nova no backlog, vale perguntar a qual PIR ela se liga, e a ausência de resposta não proíbe a caça, mas rebaixa sua prioridade de valor.

As fontes internas costumam ser as mais negligenciadas e as mais baratas de explorar. Incidentes passados e quase incidentes geram hipóteses de retorno e de variante, porque o adversário que entrou uma vez tende a tentar de novo com pequenas mudanças. Anomalias vistas nos baselines apontam comportamentos que merecem explicação, e não apenas ajuste de limiar. Os crown jewels geram hipóteses em direção inversa: em vez de perguntar que técnica caçar, pergunta-se como um adversário chegaria ao ativo crítico, e cada caminho plausível vira uma família de hipóteses. A teoria de adversário, por fim, exercita a simulação do raciocínio do oponente sem intel específica, combinando motivação presumida, capacidade observada no setor e superfície exposta.

A teoria de adversário merece nota à parte, porque é a única fonte que não depende de relato nem de telemetria prévia. O exercício é simples e produtivo: escolher um objetivo plausível, como acesso ao sistema financeiro, um perfil presumido de adversário, com motivação e capacidade, e simular os passos que esse operador tomaria, respeitando as defesas conhecidas do ambiente. Cada passo que sobrevive ao filtro de plausibilidade vira hipótese candidata, e o exercício completo costuma gerar uma família inteira de caças alinhadas por objetivo, em vez de hipóteses isoladas por técnica.

3. Brainstorming Estruturado e Decon de Relatos

O brainstorming de hipóteses funciona quando tem estrutura, e falha quando vira reunião livre. A prática recomendada divide a sessão em dois blocos com tempo marcado: na divergência, 20 a 30 minutos para listar quantas hipóteses plausíveis forem possíveis, com regra explícita de não criticar; na convergência, o grupo elimina duplicatas, agrupa variantes e nomeia cada hipótese sobrevivente com técnica ATT&CK e ativo alvo. Três inclusões obrigatórias protegem o exercício contra o viés de confirmação: uma hipótese de mau funcionamento interno, uma hipótese de atividade autorizada não documentada e uma hipótese nula de que nada ocorreu.

O brainstorming funciona melhor com diversidade de participações, e não com volume: hunter, engenheiro de detecção e analista de CTI enxergam caminhos diferentes para o mesmo relato, e a sessão com apenas hunters tende a reproduzir a mesma lógica de consulta. O registro da sessão é a própria lista numerada com proveniência, e não ata formal, porque o que importa é a rastreabilidade da ideia até a fonte.

A decon, ou deconstrução, é a disciplina de transformar relatos de inteligência em hipóteses operáveis, em vez de arquivá-los como leitura. O processo extrai do relato os elementos caçáveis: ator, objetivo, técnicas com IDs ATT&CK, procedimentos específicos, infraestrutura e artefatos. Para cada elemento, o hunter pergunta três coisas: como esse comportamento apareceria nos meus dados, qual fonte o registraria e qual campo diferenciaria atividade maliciosa de atividade legítima. O quadro abaixo mostra a decon de um relato fictício de campanha de acesso inicial em dois passos.

Relato: campanha de phishing com ISO anexada, execução de loader em
PowerShell, persistência por tarefa agendada, exfiltração via serviço de
nuvem pública.

Decon para hipóteses:
1. Anexo ISO montado: procurar montagem de ISO por processo Outlook e
   processo filho nucleares; fonte: EDR de arquivo, campo de ancestralidade.
2. Loader em PowerShell com string codificada: procurar powershell.exe com
   -enc ou FromBase64String iniciado por leitor de PDF ou navegador;
   fonte: EDR de processo, campo de linha de comando.
3. Persistência por tarefa agendada: procurar schtasks.exe criando tarefa
   com ação apontando para diretório de usuário; fonte: EID 4698 e EDR.
4. Exfiltração por nuvem: procurar upload de volume alto para domínio de
   armazenamento recém-visto no ambiente; fonte: proxy e NDR.

4. Formulação SE-ENTÃO e Evidência Esperada

A formulação SE-ENTÃO força a hipótese a declarar o que será observado e onde, o que a torna falsificável por definição. O formato completo tem quatro partes: SE o comportamento do adversário, ENTÃO a evidência esperada descrita em termos de dados, EM qual fonte e campo, DENTRO DE qual janela e conjunto de ativos. A evidência esperada precisa ser escrita no vocabulário das fontes reais, com nomes de campos e identificadores de evento, e não em linguagem vaga, porque é dela que a consulta da nota 04 será derivada. Toda hipótese também declara o significado do resultado vazio: ausência de evidência após verificação de cobertura encerra como refutação provisória, e não como silêncio.

Hipótese formulada precisa ser confrontada com o mapeamento de dados antes de entrar na fila, porque evidência esperada inexistente nos dados transforma caça em achado de lacuna, o que é legítimo mas custoso quando não intencional. A verificação leva minutos: cada elemento da evidência esperada é localizado na tabela técnica por fonte por campo da nota 03, e os elementos sem correspondência viram ressalva explícita na hipótese. Essa ressalva evita o desgaste de uma execução que descobre, no meio do caminho, que o campo prometido nunca foi coletado.

A parte DENTRO DE da formulação merece atenção especial, porque é ela que dimensiona o custo e a viabilidade da caça. Janela muito longa contra fonte com retenção curta é promessa que os dados não cumprem, e conjunto de ativos vago, como todo o domínio, esconde custos de varredura que só aparecem na execução. A prática recomendada é escrever a janela e os ativos com os mesmos valores que a consulta vai usar, e não com abstrações que precisarão ser traduzidas depois.

5. Priorização por Custo e Valor

Com um backlog de dezenas de hipóteses, a ordem de execução é uma decisão de portfólio, e não de intuição. O valor de uma hipótese cresce com a probabilidade de o adversário alvo usar a técnica, com a proximidade da técnica dos crown jewels e com o tamanho da lacuna de cobertura que a caça fecha. O custo cresce com o volume de dados a varrer, com o esforço analítico de triagem dos resultados e com a imaturidade das fontes envolvidas. A razão valor sobre custo dá a ordem inicial, e a revisão em pares corrige distorções que números sozinhos não captam, como uma hipótese barata que exige contexto institucional ainda inexistente.

A pontuação só fica útil com exemplo concreto, e a tabela abaixo ilustra a decisão final sobre três hipóteses fictícias da fila. A razão valor sobre custo dá a ordem, e a justificativa escrita na própria linha evita que a priorização precise ser refeita quando outra pessoa assumir a fila.

A revisão do portfólio complementa a pontuação individual. A carteira de hipóteses precisa de diversidade por fonte, por tática do ATT&CK e por ativo alvo, porque uma fila dominada por hipóteses de execução de código deixa credenciais, persistência e exfiltração sem olhar por meses. A prática recomendada revisa a distribuição a cada ciclo de priorização, e a regra prática é reservar ao menos uma vaga por ciclo para a tática menos coberta, que costuma ser coleta ou exfiltração, justamente as que aparecem tardiamente nos relatos públicos.

O custo de uma hipótese também é estimado com os dados da nota 03, e não por intuição. Volume de dados é consultado no inventário com o tamanho real do índice na janela proposta, esforço de triagem é estimado pela saída histórica de consultas semelhantes, e maturidade da fonte vem da pontuação de cobertura. Estimativa com números à mão vira discussão curta na triagem semanal, e estimativa por sensação vira reunião sem decisão.

A priorização é decisão revisável, e não veredito. Relato novo de intel que mostra o adversário alvo usando uma técnica específica eleva a probabilidade das hipóteses ligadas a ela, e incidente interno pode promover de imediato uma hipótese que estava em fila há meses. A triagem semanal revisa o topo da fila com essas mudanças em mente, e a mudança de prioridade fica registrada com data e motivo, porque histórico de priorização é o que permite auditar por que uma lacuna ficou aberta.

6. Pipeline e Backlog de Hipóteses

O backlog é a fila única de hipóteses da operação, e seu ciclo de vida precisa ser explícito para que hipóteses não morram em notas de reunião. Estados típicos são: nova, em análise de priorização, priorizada, em execução, encerrada com achado, encerrada com refutação, convertida em detecção, convertida em requisito de coleta e arquivada. A governança mínima inclui triagem semanal de novas hipóteses, revisão mensal do envelhecimento da fila e regra de descarte documentado para hipóteses que perderam relevância, porque fila infinita é fila que ninguém confia. O template abaixo padroniza a entrada no backlog e preserva o vínculo com o plano de caça da nota 01.

# Hipótese HYP-2025-037

- Estado: priorizada | Prioridade: 1 | Incluída em: [data]
- Fonte: [intel / incidente / anomalia / crown jewel / teoria de adversário]
- Referência externa: [relato, campanha ou ator associado, quando houver]

## Formulação SE-ENTÃO
- SE [comportamento], ENTÃO [evidência esperada] EM [fonte e campo],
  DENTRO DE [janela e ativos].

## Pontuação
- Valor: [nota 1-5 com justificativa] | Custo: [nota 1-5 com justificativa]
- Razão valor/custo: [cálculo simples]

## Vínculos
- Plano de caça: [HUNT-xxxx-xxx quando aprovada]
- Relato final: [HUNT-xxxx-xxx-R quando encerrada]
- Desdobramentos: [detecção, requisito de coleta ou hipótese filha]

Antes de uma hipótese sair do backlog para execução, cinco testes de qualidade evitam desperdício:

• Teste de falsificabilidade: a formulação SE-ENTÃO declara evidência observável que pode estar ausente.
• Teste de observabilidade: cada elemento da evidência esperada existe no mapeamento de dados com fonte e campo.
• Teste de especificidade: ativos, janela e comportamento estão delimitados, e não abertos para todo o ambiente.
• Teste de proveniência: a origem está registrada, com referência externa quando houver.
• Teste de vínculo: a hipótese se liga a um PIR ou a um ativo crítico, e a ligação está escrita.

O envelhecimento do backlog é métrica de governança, e não detalhe administrativo. Hipóteses que passam de um trimestre na fila sem execução precisam de decisão: reafirmar prioridade com justificativa nova, dividir em hipóteses menores ou descartar com registro. Fila envelhecida e nunca limpa perde credibilidade interna, e a equipe para de alimentá-la, o que fecha o canal mais barato de geração de hipóteses que o programa possui.

A ferramenta do backlog importa menos que a disciplina, e opções comuns convivem bem com o processo: planilha compartilhada em operações pequenas, itens de issue tracker com etiquetas em operações médias e campos personalizados na plataforma de CTI quando o backlog deve ficar visível junto à inteligência. O requisito não muda: estado único por hipótese, histórico de transições e busca por proveniência e técnica. Ferramenta que não oferece isso será contornada por planilha paralela, e a operação passará a ter dois backlogs, o que é pior que um manual.

7. Erros Comuns e Pontos de Atenção

O erro mais comum é formular hipóteses na direção da detecção existente, caçando aquilo que já tem regra pronta, porque é confortável e rende poucos falsos positivos. Esse viés transforma o hunting em reteste da engenharia de detecção, e as lacunas reais de cobertura continuam abertas. O segundo erro é formular hipóteses infalsificáveis, como afirmações de que o adversário pode estar em algum lugar, que não declaram evidência esperada nem resultado vazio e, portanto, não podem ser encerradas com integridade. O terceiro é confundir hipótese com IOC, caçando um hash específico de relato em vez do comportamento que o hash exemplifica, o que desperdiça a natureza prospectiva da caça e encurta a vida útil do trabalho, já que infraestrutura expira e comportamento persiste.

Um quarto erro é a inflação de hipóteses duplicadas, quando cada relato lido gera entrada nova que repete caça já registrada, e a fila cresce sem crescimento de cobertura. O antídoto é a deduplicação na triagem semanal, com vínculo explícito entre hipóteses irmãs, e a prática de atualizar a hipótese existente com a referência nova, em vez de criar outra. Hipótese que acumula referências de fontes diferentes ganha valor, porque é sinal de que o comportamento se repete entre adversários e campanhas.

Um erro de governança merece atenção: aceitar hipóteses de qualquer fonte sem registro de proveniência. Hipótese sem origem documentada não pode ser calibrada, porque ninguém sabe se veio de relato confiável, de ruído de anomalia ou de opinião solta. A proveniência também alimenta o feedback loop com o capítulo 05, indicando quais tipos de relato de intel geram caças com achado, e quais geram apenas consumo de horas.

8. Integração com o Restante da Biblioteca

A hipótese aprovada migra para o plano de caça da nota 01 no campo de hipótese central, e as consultas que a testam dependem da coleta e normalização descritas na nota 03, sem as quais a evidência esperada simplesmente não existe nos dados. A execução da nota 04 pode gerar hipóteses filhas por bifurcação, e cada bifurcação retorna a esta nota como entrada nova do backlog, mantendo o pipeline vivo durante a própria caça. A nota 06 automatiza parte desse pipeline, agendando a execução periódica de hipóteses estáveis.

Com os capítulos anteriores, a nota consome TTPs do capítulo 03, ATT&CK e Pirâmide de Dor do capítulo 04 e relatos avaliados pelo capítulo 05, fechando o arco que leva de indicadores a comportamentos. Com o capítulo 15, ela operacionaliza os controles de formulação e priorização de hipóteses, e suas métricas de conversão alimentam os KPIs de hunting. Com o capítulo 18, a hipótese encerrada como detecção candidata inicia o processo de engenharia que transforma caça em alerta permanente.