Home Comunidade Eventos YouTube Networks Desafios // produtos Academy News CTI | CVE Contato

01 - TH.6 - Formulação de Hipóteses Estruturadas (SE-ENTÃO)

video explicativo
Video explicativoEspaco reservado para o video desta anotação — adicione video: https://youtu.be/... no frontmatter da nota.

TH.6 - Formulação de Hipóteses Estruturadas (SE-ENTÃO)

Controle TH.6 do grupo HNT (Threat Hunting) da seção "15 - Framework CTH - Controles".
Deriva do Capítulo 12 do PDF e da etapa de formulação do Ciclo de Threat Hunting (Capítulo 2).
Define o formato SE-ENTÃO que transforma inteligência em investigações testáveis para TH.7 a TH.10.

1. Contexto e Posicionamento no Framework CTH

A formulação da hipótese é a etapa que separa uma caça sistemática de uma exploração aleatória de dados. No Ciclo de
Threat Hunting do Framework CTH, a hipótese ocupa o momento entre a identificação do alvo e a execução da busca, e sua
qualidade determina diretamente a eficácia do hunt. Hipóteses vagas produzem investigações inconclusivas, desperdício de
horas de analista e, no pior cenário, a falsa confiança de que o ambiente está limpo.

O controle TH.6 exige que toda hipótese seja escrita no formato condicional SE-ENTÃO, com técnica ATT&CK suspeita,
comportamento esperado e fonte de dados declarados de forma explícita. Esse formato obriga o hunter a pensar como o
adversário, decidir de antemão o que seria observável e definir onde procurar. Ele também torna o trabalho auditável, pois
outro analista consegue ler a hipótese, entender o raciocínio e reproduzir ou contestar a busca.

Na sequência do grupo HNT, o TH.6 recebe do TH.5 o backlog priorizado de temas e entrega às técnicas de execução (TH.7,
TH.8, TH.9 e TH.10) objetos de investigação devidamente estruturados. Sem hipóteses bem formadas, essas técnicas se
reduzem a consultas ad hoc, sem critério de sucesso ou encerramento. Por isso a formulação é controle formal, com
critérios, template e salvaguardas.

2. O Que Torna uma Hipótese de Hunting Boa

Uma hipótese útil reúne quatro atributos verificáveis ainda antes da execução, e cada um deles pode ser testado com uma
pergunta objetiva. A resposta negativa em qualquer um dos critérios é sinal de reformulação, não de execução, conforme o
teste rápido da tabela.

Atributo Pergunta de verificação Sinal de falha
Observável O comportamento gera eventos em alguma fonte de telemetria? Hipótese depende da intenção do adversário, não de ação registrada
Específica Técnica, padrão e fonte estão nomeados com precisão? Frase genérica do tipo "procurar malware no ambiente"
Falsificável Existe um resultado que refutaria a hipótese? Busca que nunca termina, pois qualquer resposta vira "mais investigação"
Ligada a dado disponível A fonte citada está realmente coletada e consultável? Referência a logs que o DAT.x confirmou não existir no ambiente

A observabilidade é o critério mais negligenciado na prática. O que o adversário pretende não é testável, mas o que ele
executa, conecta e escreve em disco deixa rastro em eventos concretos, como o Sysmon Event ID 1, o Windows Event ID 4698
ou consultas DNS registradas pelo sensor de rede. A especificidade, por sua vez, permite medir cobertura, pois hipóteses
mapeadas em subtécnica ATT&CK alimentam a matriz de detecção e revelam lacunas reais de visibilidade.

A falsificabilidade dá encerramento ao hunt. Se a busca completa foi executada e o padrão não apareceu, a hipótese está
refutada naquele período, e esse é um resultado válido e registrável, que enriquece o entendimento do baseline. Hipóteses
que admitem qualquer resultado como confirmação produzem relatórios inúteis e devem ser reescritas antes de entrar em
execução.

3. Anatomia do Formato SE-ENTÃO

O formato SE-ENTÃO descreve uma relação de causa e efeito observável: se o adversário executa a técnica X com o padrão Y,
então a evidência Z será visível na fonte W. A cláusula SE concentra o comportamento do adversário; a cláusula ENTÃO
concentra a evidência que o defensor espera coletar. Além dessas cláusulas, toda hipótese carrega identificador, técnica
ATT&CK, fonte, prioridade e critério de validação, conforme o template da seção 7.

Componente Papel na hipótese Exemplo de preenchimento
SE (condição) Comportamento do adversário, com técnica e padrão Adversário usa T1053.005 com tarefa agendada cuja ação executa binário em caminho gravável pelo usuário
ENTÃO (observável) Evidência esperada, com eventos concretos Evento 4698 e Sysmon EID 1 com schtasks.exe criando tarefa apontada para caminho fora de C:\Windows
Fonte W Telemetria onde a evidência deve aparecer Task Scheduler Operational e Sysmon do Windows, centralizados no SIEM
Critério de validação O que confirma e o que refuta Tarefa criada por processo de Office aponta para investigação; ausência do padrão no período refuta

O padrão Y da cláusula SE é o que diferencia caças repetíveis de buscas genéricas. A frase "o adversário usa tarefas
agendadas" é conhecimento de manual; a frase "o adversário usa tarefas agendadas cuja ação executa binário em caminho
gravável pelo usuário, criadas por processo de produtividade" é um padrão observável e delimitado. Quanto mais concreto o
padrão, mais direta a consulta.

4. Fontes de Derivação das Hipóteses

As hipóteses do backlog nascem de três fontes primárias, e o registro deve indicar qual delas motivou a entrada. A
diversidade de fontes protege o programa do viés de caçar apenas o que está na moda setorial, e a origem documentada
permite auditar o alinhamento com os PIRs.

  • CTI corrente: relatórios de atores relevantes para o setor, alertas de ISACs e colegas e
    atualizações de perfis no TIP. O TH.6.2 estabelece a meta de ao menos 50% das hipóteses vindas
    dessas fontes, garantindo caça guiada por inteligência e não por suposição.
  • Lacunas de cobertura ATT&CK: o cruzamento entre a matriz e as regras ativas do DET.x revela
    técnicas sem detecção automatizada; cada lacuna crítica vira uma hipótese que testa se a ausência
    de alerta corresponde ou não à ausência de atividade.
  • IOBs das baselines: desvios registrados pelo INS.5, como processo pai incomum ou volume anômalo de
    logons fora de hora, viram cláusulas SE específicas. Achados de hunts anteriores e lições de
    incidentes do IR.x também alimentam hipóteses de variantes do mesmo comportamento.

A ligação com os PIRs (Priority Intelligence Requirements) do ciclo de CTI garante alinhamento estratégico do esforço. Uma
hipótese sobre exfiltração via DNS entra com prioridade alta apenas se algum PIR cobre roubo de dados ou espionagem;
hipóteses desconectadas de todo PIR competem por tempo de analista sem entregar valor. Quando não houver PIR associado, o
registro indica a justificativa alternativa, como fechamento de lacuna apontada pelo MAP.x.

5. Exemplos Completos de Hipóteses

Os três exemplos a seguir cobrem persistência, movimento lateral e comando e controle, as três situações mais frequentes
em hunts guiados por hipótese. Cada exemplo traz a hipótese no formato completo e o critério que separa confirmação de
refutação, servindo de modelo para o backlog.

Exemplo 1, persistência via tarefa agendada (T1053.005). SE o adversário estabelece persistência criando tarefa
agendada que executa binário em caminho gravável pelo usuário, ENTÃO será observada a criação de tarefa (Windows Event ID
4698) cuja ação aponta para caminho fora de C:\Windows e dos diretórios de programa, possivelmente precedida pela execução
de schtasks.exe com o parâmetro /create (Sysmon EID 1), na fonte Task Scheduler Operational e Sysmon centralizados no
SIEM. Critério de validação: tarefa criada por processo pai incomum (winword.exe, excel.exe, powershell.exe de origem
atípica) ou com ação em %APPDATA%, %TEMP% ou %PUBLIC% valida a suspeita; a ausência desses padrões no período consultado
refuta a hipótese.

Exemplo 2, movimento lateral via ferramenta administrativa (T1021.002). SE o adversário utiliza ferramenta de
administração remota legítima, como PsExec ou equivalente, para avançar de estações para servidores, ENTÃO será observada
a criação de serviço (Windows Event ID 7045) com nome padrão da ferramenta ou nome aleatório, seguida de logon de rede
(tipo 3) e de processos cmd.exe ou powershell.exe iniciados por services.exe no destino, na fonte de eventos de segurança
centralizados no SIEM e telemetria de EDR. Critério de validação: serviço com binário em share administrativo (caminho no
formato \IP\ADMIN$), criada a partir de estação e fora da janela aprovada, valida a suspeita; execuções do repositório de
TI, por contas de infraestrutura, são descartadas.

Exemplo 3, beaconing de C2 sobre HTTPS (T1071.001). SE um implante se comunica com infraestrutura de C2 em intervalos
regulares sobre HTTPS, ENTÃO serão observadas conexões repetidas do mesmo host interno para o mesmo destino externo, com
espaçamento quase constante entre as conexões e volumes de bytes enviados muito similares, na fonte de logs de proxy e de
conexão do sensor de rede (Zeek conn, logs de firewall). Critério de validação: desvio padrão do intervalo entre conexões
inferior a 10% da média, mantido por mais de 20 conexões consecutivas, valida a suspeita; tráfego com jitter elevado para
destino categorizado como serviço legítimo de nuvem refuta a hipótese naquele período.

6. Erros de Formulação e Como Corrigi-los

Três erros dominam a formulação amadora, e todos são evitáveis com revisão disciplinada. A tabela lista o erro, o sintoma
típico e a correção, servindo de checklist para a revisão por pares exigida pelo TH.6.4 antes da execução.

Erro Sintoma típico Correção
Hipótese genérica sem padrão observável "Hunt para ver se tem malware", sem consulta derivável Nomear técnica, padrão e eventos concretos na cláusula ENTÃO
Hipótese não falsificável Qualquer resultado é tratado como "continuar investigando" Definir critério objetivo de confirmação e de refutação
Hipótese sem fonte de dados Consulta planejada para fonte inexistente no ambiente Validar a fonte contra o inventário do DAT.x antes de aprovar
Hipótese dupla Duas relações SE-ENTÃO condensadas na mesma entrada Dividir em hipóteses independentes no backlog

Um caso frequente é a hipótese que cita fontes em nível de desejo, como "telemetria de memória do endpoint", quando o
DAT.x mostra que a coleta existe apenas em parte dos servidores. Nessas situações a hipótese não está errada, mas o escopo
precisa ser delimitado ao subconjunto coberto, com registro da lacuna para que o MAP.x trate da cobertura. Formular contra
dado inexistente gera hunts inconclusivos por razões técnicas, e não analíticas.

7. Template de Registro no Backlog

O registro padronizado é o que permite ao backlog funcionar como ativo do programa, e não como lista pessoal de cada
hunter. O template cobre os campos mínimos do TH.6 e pode ser adaptado a ticket, planilha ou repositório, desde que os
critérios de confirmação e refutação permaneçam sempre presentes.

ID: HYP-2025-017
Título: Persistência via tarefa agendada criada por processo de Office
Hipótese: SE um adversário estabelece persistência criando tarefa agendada que executa binário
em caminho gravável pelo usuário, ENTÃO será observado o evento 4698 com ação em %APPDATA%,
%TEMP% ou %PUBLIC%, com processo pai winword.exe, excel.exe ou powerpnt.exe, na fonte Sysmon
(EID 1) e Task Scheduler Operational.
Técnica ATT&CK: T1053.005 (Scheduled Task/Job: Scheduled Task)
Fonte de dados: Sysmon EID 1 e Windows Event ID 4698 (cobertura: 100% das estações)
PIR: PIR-03 (loader de phishing) | Prioridade: Alta | Status: Pendente | Revisão: TH.6.4
Confirmação: ao menos um evento casando com o padrão no período consultado
Refutação: nenhuma correspondência após consulta completa e validada
Resultado: (preencher após execução) | Conversão: (detecção, IOC ou IR)

8. Evolução da Hipótese Durante a Caça

Uma hipótese não é imutável durante o hunt; ela evolui conforme os dados respondem. O refinamento ocorre quando o padrão
inicial é largo demais e os resultados viram ruído: restringe-se o escopo por processo pai, por unidade organizacional,
por janela de tempo ou por um atributo adicional na cláusula SE. A subdivisão ocorre quando a hipótese revela ramificações
promissoras, como um achado de tarefa agendada suspeita que abre sub-hipóteses sobre o binário apontado, sua origem de
rede e o vetor de entrega do documento que o invocou.

Há também o encerramento legítimo, tratado com o mesmo rigor da confirmação. Quando a execução completa refuta a hipótese,
o resultado é registrado com fontes consultadas, período coberto e limitações de cobertura, e essa refutação passa a
compor o baseline do ambiente. Quando a hipótese se confirma, o caminho é curto: abrir investigação pelo IR.x, gerar IOC
para o acervo do TH.10 e converter o padrão em detecção permanente pelo DET.x. O mesmo olhar crítico da revisão por pares
acompanha o refinamento, evitando que o hunt deslize para territórios sem hipótese.

9. Critérios de Sucesso e Métricas

Métrica Definição Referência de meta
Tempo de formulação até execução Média de dias entre o registro e a execução do hunt Inferior a 15 dias para prioridade crítica
Taxa de conversão em achados Percentual de hipóteses executadas que geram achado formal Entre 10% e 20%; zero absoluto sugere backlog desalinhado
Taxa de verdadeiro positivo Percentual de achados confirmados como maliciosos Acima de 50% indica hipóteses específicas o bastante
Cobertura ATT&CK das hipóteses Percentual de técnicas críticas com hipótese já testada Crescimento contínuo, reportado pelo MET.x
Refutações documentadas Hipóteses refutadas com fonte, período e limitação registrados 100% das refutações documentadas no repositório

O acompanhamento dessas métricas pelo TH.6.5 fecha o laço entre formulação e governança. Um backlog com conversão
persistentemente nula indica hipóteses genéricas ou desalinhadas de PIR; um tempo de formulação até execução crescente
indica gargalo de capacidade. As métricas são revisadas junto com o backlog, em cadência semanal, e reportadas ao ciclo de
melhoria contínua.

10. Salvaguardas por Nível de Maturidade

Nível Salvaguarda Prática operacional esperada
Básico TH.6.1 Toda hipótese em formato SE-ENTÃO, com técnica ATT&CK, comportamento esperado e fonte declarados
Básico TH.6.2 Ao menos 50% das hipóteses derivadas de CTI corrente, com referência ao relatório de origem
Intermediário TH.6.3 Backlog com mínimo de 20 hipóteses testáveis, priorizado por risco e revisado semanalmente
Intermediário TH.6.4 Revisão por pares antes da execução, com checklist de clareza, testabilidade e dado disponível
Avançado TH.6.5 Sistema de rastreamento com métricas por hipótese e cobertura ATT&CK das caças testadas

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

A relação com o TH.5 é de alimentação direta: a priorização decide quais temas ganham capacidade de formulação primeiro, e
o backlog do TH.6.3 materializa essa decisão. A relação com o TH.10 é de mão dupla: um IOC acionado em busca reativa pode
gerar hipótese estruturada sobre o comportamento mais amplo do mesmo ator, enquanto a hipótese confirmada produz novos IOC
e IOA para o acervo operacional. Com as técnicas TH.7, TH.8 e TH.9, a hipótese define o objeto e o critério de sucesso, e
cada técnica define o método de busca mais adequado.

Os vínculos com os demais grupos fecham o ciclo do programa. O DAT.x garante que as fontes citadas existem e têm
qualidade; o INS.5 fornece os IOBs que viram cláusulas SE; o DET.x recebe a conversão dos padrões confirmados em regras; o
IR.x recebe os achados de maior criticidade; o MET.x mede a conversão e o tempo entre formulação e execução; o GOV
assegura alinhamento com os PIRs corporativos. Tratar o TH.6 como documento vivo, versionado e revisado semanalmente é o
que transforma formulação em capacidade institucional, e não em hábito restrito a alguns analistas experientes.