Usando Inteligência para Priorizar Hipóteses

Nota 01 do capítulo 10 - Integração entre CTI e Threat Hunting. Abre o capítulo que costura as duas metades da biblioteca, definindo como o relatório de inteligência se converte no backlog de hipóteses da caça.
Estabelece o filtro de relevância (setor, stack, exposição), o pipeline de tradução de TTP narrada em hipótese testável e a cadência de manutenção do backlog.
Dialoga com a nota 04 do capítulo 05 (relatórios), com a nota 02 do capítulo 06 (hipótese SE-ENTÃO) e com os controles INT.1 e TH.5 da seção 15.

1. Contexto e Posicionamento na Biblioteca

O relatório de inteligência existe para mudar decisões, e a decisão mais frequente que um relatório tático habilita é a escolha do que caçar a seguir. Produzida a análise e feita a disseminação, o destino natural do produto é a fila de priorização do time de hunting; quando esse destino não existe formalmente, o relatório morre na caixa de entrada e a organização paga duas vezes, uma pela produção e outra pela intrusão que ninguém procurou. Esta nota define a interface entre as duas funções: um pipeline de conversão com artefatos nomeados, um modelo de priorização com critérios explícitos e uma cadência de manutenção que mantém o backlog vivo e auditável.

A biblioteca já fornece as peças que esta nota conecta. A montante, o capítulo 05 entrega o relatório canônico com julgamentos calibrados e anexo técnico, e o capítulo 01 fornece os PIRs que separam ameaça relevante de notícia interessante. A jusante, a nota 02 do capítulo 06 define a estrutura SE-ENTÃO que toda hipótese do backlog deve adotar, e o capítulo 07 executa o processo que consome a fila. Na seção 15, o controle INT.1 institucionaliza o ciclo inteligência-driven e a salvaguarda TH.5 formaliza a priorização; esta nota é a versão conceitual e prática desses controles, com exemplos completos de conversão.

2. Do Relatório ao Backlog: O Pipeline de Conversão

A conversão de relatório em hipótese não é um gesto de leitura, é um processo com cinco etapas, cada uma com entrada, saída e responsável. O desenho em etapas existe porque cada passagem de bastão é um ponto de controle: relatório sem técnica ATT&CK mapeada não entra em extração, hipótese sem fonte de dados declarada não entra em execução. A tabela abaixo consolida o pipeline de referência, que deve ser adaptado ao porte da equipe sem quebrar os critérios de aceitação entre etapas.

Três regras editoriais sustentam o pipeline na prática. Primeira, todo relatório tático deve sair com no mínimo uma recomendação de caça, com técnica ATT&CK e fonte de dados sugerida; recomendação que o CTI não escreve, o hunter inventa com menos contexto. Segunda, a extração separa comportamento de artefato: TTPs geram hipóteses, IOCs alimentam busca de presença complementar, e confundir os dois planos produz caças que viram grep. Terceira, cada hipótese candidata herda a confiança do julgamento de origem, no padrão do capítulo 05, e registra de qual relatório descende, o que permite auditar a cadeia completa do conhecimento externo à execução interna.

A ferramenta que hospeda o backlog importa menos que os campos estruturados que ele carrega. Identificador único da hipótese, referência ao relatório de origem, técnica ATT&CK, nota de priorização com data, estado atual e veredicto final compõem o mínimo que permite auditar a cadeia e calcular métricas; planilha sem vínculo com o relatório, ou fila de e-mail sem estado, devolve o processo à memória das pessoas. Plataformas de gestão de casos e TIPs maduros já oferecem esses campos como objetos nativos, e a regra prática é que a hipótese no backlog deve ser o mesmo objeto que a execução depois preenche, e não uma cópia reescrita em outro formato.

3. Priorização por Relevância: Setor, Stack e Exposição

Priorizar é decidir onde a hora de analista rende mais, e a decisão exige critérios que sobrevivam à troca de pessoas. O primeiro eixo é o setor: a pergunta é se o ator ou a campanha descritos têm histórico de vitimizar organizações como a nossa, informação que vem de relatórios setoriais, alertas de ISAC e do histórico interno de incidentes. Um afiliado de ransomware que ataca manufatura no fuso da América do Sul tem prioridade objetivamente maior para uma indústria brasileira do que uma campanha igualmente técnica contra provedores de nuvem asiáticos, independentemente de qual relatório é mais bem escrito.

O segundo eixo é o stack: a pergunta é se a técnica é executável no parque tecnológico real da organização. Hipótese sobre abuso de LaunchDaemons, do macOS, é irrelevante em ambiente só de Windows; hipótese de abuso de IAM na nuvem exige que a organização tenha a carga na nuvem; técnica de Active Directory não vale nada sem Active Directory. O terceiro eixo é a exposição: a pergunta é se a superfície que a técnica explora existe e está alcançável, informação que a superfície externa do capítulo 21 e o inventário do grupo INS da seção 15 fornecem. Serviço de VPN sem MFA exposto eleva T1133; mesmo serviço atrás de MFA com contas dedicadas derruba a nota.

A estes três eixos somam-se dois critérios operacionais que a salvaguarda TH.5 exige: disponibilidade de telemetria, porque hipótese sem dado é caça cega, e frescor da evidência, porque campanha de seis meses atrás pode já ter rotacionado infraestrutura e ferramenta. O modelo abaixo soma os cinco critérios com pesos, numa escala de 0 a 5 por critério, e produz uma nota máxima de 60. Faixas orientam o agendamento: acima de 40 entra no próximo ciclo semanal, entre 25 e 39 entra no trimestre, abaixo de 25 fica em monitoramento com data de reavaliação.

Um exemplo numérico fixa o método. Hipótese de apagamento de shadow copies de um afiliado que mira manufatura, com telemetria de processo disponível e campanha ativa, pontua 5 no PIR, 5 no setor, 5 no stack, 4 na exposição, 4 na telemetria e 5 no frescor, totalizando 56 e entrando no ciclo semanal. Hipótese sobre técnica de nuvem descrita em relatório genérico, sem carga na nuvem e sem PIR associado, pontua baixa em três eixos e fica em monitoramento, com anotação do motivo, porque decisão documentada é o que distingue priorização de gosto pessoal.

3.1 Comparativo de Candidatas Pontuadas

A tabela abaixo aplica o modelo a três candidatas geradas do mesmo lote de relatórios, com o resultado de cada critério registrado. O exercício comparativo é o que dá ao backlog a propriedade de decisão: quando o gestor pergunta por que a caça A entra antes da caça B, a resposta está nas notas, e não na autoridade de quem ordenou.

Duas leituras da tabela merecem registro. A candidata de nuvem não é descartada, e sim monitorada com data de reavaliação, porque a condição que a rebaixa, ausência de carga na nuvem, pode mudar com a estratégia de tecnologia e a hipótese continua documentada para esse dia. E a candidata de phishing com pontuação máxima mostra o comportamento esperado quando o alerta vem de ISAC com campanha ativa: nota alta em todos os eixos ao mesmo tempo, que é o perfil de disparo ad hoc, com execução fora da cadência e janela de reação em dias.

4. De TTP do Relatório a Hipótese Testável

A tradução de TTP narrada em hipótese testável segue quatro movimentos: normalizar o comportamento em técnica ATT&CK, decompor a técnica em comportamento observável nos dados próprios, mapear a fonte de dados que registraria o comportamento e redigir a estrutura SE-ENTÃO com critério de falsificação. O movimento mais negligenciado é o segundo, porque relatórios narram procedimentos ("o operador apaga cópias de sombra antes de cifrar") e o analista precisa descer da narrativa para o evento concreto que a telemetria própria registraria, com nome de processo, argumento e evento de log.

Duas regras de redação separam hipótese forte de tradução preguiçosa. A condição SE descreve comportamento e não ferramenta, porque "adversário apaga shadow copy" sobrevive à troca de vssadmin por wmic, enquanto "adversário usa vssadmin" envelhece com o relatório. E a expectativa ENTÃO precisa ser consultável nos dados que a organização realmente coleta na janela considerada; se o evento 4688 com linha de comando não está centralizado, a hipótese nasce acompanhada de um pedido formal de coleta ao grupo DAT, e não de uma execução frustrada que produz falso negativo silencioso.

A normalização em ATT&CK também tem função política que vale registro. Relatórios de fornecedores diferentes nomeiam o mesmo comportamento com termos próprios, e a técnica ATT&CK é o vocabulário comum que permite somar evidências, comparar cobertura e conversar com o heatmap do grupo MAP da seção 15. Uma TTP narrada que não casa com nenhuma técnica do catálogo é sinal de atenção e não de erro automático: ou o relatório descreve algo realmente novo, o que vale submissão de feedback ao próprio ATT&CK, ou descreve um procedimento tão específico que a hipótese deve mirar a técnica genérica, com o procedimento como pista de busca, e não como critério de falsificação.

5. Exemplo Completo: Relatório de Ransomware Vira Caça

O cenário abaixo percorre o pipeline ponta a ponta com um relatório de afiliado de ransomware contra o setor industrial. O trecho do relatório reproduz os campos que interessam à conversão, no padrão de estrutura canônica do capítulo 05:

[TLP:AMBER] RELT-2025-062: Afiliado de ransomware mira indústria com VPN sem MFA
BLUF: afiliado explora VPN corporativa sem segundo fator, exfiltra com rclone
e cifra após apagar cópias de sombra; recomenda-se caça pelos precursors
T1490 e T1567.002 nos últimos 45 dias.
Confiança: moderada-alta; três vítimas confirmadas no setor com os mesmos TTPs.
TTPs: T1133, T1047, T1490, T1567.002, T1486.

A pontuação da hipótese candidata sobre T1490 resultou 56 de 60, com justificativa registrada por critério, e a tradução SE-ENTÃO produziu o registro abaixo, já no formato do caderno de caça da nota 02 do capítulo 06:

ID: H-2025-031
Título: Apagamento de cópias de sombra como precursor de cifração
Tipo: inteligência-driven | Origem: RELT-2025-062 | Confiança herdada: moderada-alta
Relevância: PIR-04, interrupção de produção por ransomware; pontuação 56/60
SE um host corporativo foi preparado para cifração nos últimos 45 dias,
ENTÃO haverá execução de vssadmin.exe, wbadmin.exe ou diskshadow.exe com
     argumentos de exclusão, ou wmic.exe com shadowcopy delete,
     em servidor de arquivo ou estação com compartilhamento sensível,
DADOS: telemetria de processo (Sysmon 1 centralizado e 4688 com linha de comando)
FALSIFICAÇÃO: zero ocorrências do padrão na janela com telemetria confirmada
              fecha a hipótese como limpo validado
SAÍDAS: hosts afetados, linha do tempo, hash de loader eventual, detecção Sigma

A consulta de execução cobre os três binários nativos de apagamento e exclui as operações legítimas de backup, que usam os mesmos comandos em janela agendada:

DeviceProcessEvents
| where Timestamp > ago(45d)
| where (FileName =~ "vssadmin.exe" and ProcessCommandLine has "delete shadows")
   or (FileName =~ "wmic.exe" and ProcessCommandLine has "shadowcopy delete")
   or (FileName =~ "diskshadow.exe" and ProcessCommandLine has "delete shadows")
   or (FileName =~ "wbadmin.exe" and ProcessCommandLine has "delete catalog")
| where not(InitiatingProcessFileName has_any ("backupexec", "veeam", "netbackup"))
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine,
          InitiatingProcessFileName

O encerramento do exemplo ilustra a regra de ouro da integração: a execução devolve três produtos, o veredicto para o caderno de caça, os observáveis eventualmente confirmados para o ciclo de feedback da nota 02 deste capítulo e a lógica validada para o pipeline de detecção do capítulo 18. A hipótese descende do relatório, e o relatório, na próxima edição, cita a caça como verificação interna, o que fecha o laço entre as duas funções.

6. Cadência de Atualização do Backlog

Backlog sem cadência apodrece em duas direções: acumula hipóteses que ninguém executa e envelhece evidências que sustentavam prioridades altas. A rotina de referência desta biblioteca opera em três alturas. A revisão mensal acompanha o briefing do INT.1: novas TTPs de atores priorizados entram, notas são recalculadas e a ordem é reavaliada com o time. A revisão semanal trabalha o topo da fila: confere telemetria, ajusta escopo e agenda o próximo ciclo de execução. E os disparos ad hoc reinserem o ciclo fora de prazo quando a realidade justifica, com validação humana antes de qualquer execução.

A manutenção também tem regras de descarte, e a mais importante é a de envelhecimento: hipótese priorizada que não executa em 90 dias volta a avaliação, porque ou a relevância passou ou a capacidade está subestimada, e os dois diagnósticos pedem decisões diferentes. Hipóteses duplicadas são unificadas com histórico preservado, e hipóteses cuja evidência de origem envelheceu sem renovação decai uma faixa por trimestre. O limite de trabalho em execução, sugerido em três caças simultâneas por hunter, protege o time do vício clássico de abrir tudo e concluir nada, que corrompe as métricas de conclusão discutidas no capítulo 11.

7. Erros Comuns e Pontos de Atenção

• Converter IOC em hipótese: tratar o anexo de indicadores como se fosse recomendação de caça degrada a conversão a uma lista de busca; o antídoto é exigir que toda candidata carregue técnica ATT&CK e comportamento observável, deixando os IOCs para a busca de presença da nota 03 deste capítulo.
• Priorizar por manchete: nota alta por novidade sem PIR é o viés do ciclonismo descrito no capítulo 06; o antídoto é o critério de relevância com peso maior no modelo e justificativa escrita por critério.
• Hipótese sem fonte de dados: candidata que assume telemetria inexistente produz falso negativo silencioso; o antídoto é o critério de aceitação entre as etapas 3 e 4 do pipeline, com verificação no inventário do TH.1.
• Backlog sem dono e sem cadência: fila que ninguém revisa cresce até virar arquivo morto; o antídoto é a tríade mensal, semanal e ad hoc da seção 6, com ata e responsável.
• Reescrever durante a execução: mudar a condição SE depois de rodar a primeira consulta adapta a hipótese ao resultado; mudanças passam por nova versão da ficha, com data e motivo.
• Ignorar o retorno: pipeline que não registra o veredicto de cada execução perde a matéria-prima das métricas de conversão do capítulo 11 e do feedback do INT.2; todo item encerrado carrega estado final.

8. Integração com o Restante da Biblioteca

Esta nota consome diretamente o relatório canônico do capítulo 05, os PIRs do capítulo 01 e a avaliação de fontes do capítulo 02, e entrega hipóteses prontas para o processo do capítulo 07 e as técnicas do capítulo 08. A nota 02 do capítulo 06 fornece a estrutura SE-ENTÃO que o pipeline adota, e a nota 05 do capítulo 06 usa a taxa de conversão de relatório em hipótese como sinal de maturidade. Na seção 15, o INT.1 institucionaliza o ciclo de direção, o TH.5 formaliza a priorização e o MET.1 mede o tempo entre relatório e hipótese, com meta de até cinco dias úteis.

O estudo desta nota se fecha com um exercício de conversão real: escolher um relatório tático público recente do setor de interesse, extrair três TTPs, pontuar cada candidata pelo modelo da seção 3 e redigir a ficha SE-ENTÃO da mais bem pontuada, com fonte de dados verificada no próprio laboratório. O exercício treinado com material externo se transfere sem fricção para o relatório interno, e é exatamente essa transferência que o capítulo 12 vai discutir como desafio operacional das equipes pequenas.