TaHiTI (Threat Hunting Integrative Taxonomy)

Nota do Capítulo 23, Frameworks e Metodologias Emergentes.
Apresenta a TaHiTI, taxonomia integrativa que conecta threat hunting a CTI, IR e red teaming, com o processo em três fases, initiate, investigate e finalize, detalhadas, a gestão de backlog e o produto da caça, comparação com OTHF e PEAK e exemplo aplicado.
Dialoga com o Hunt Loop do capítulo 6, com o capítulo 7 de processo de hunting e com as demais notas desta pasta.

1. Contexto e Posicionamento na Biblioteca

A TaHiTI é uma metodologia de threat hunting desenhada para ser integrativa, ou seja, para funcionar como interface entre o hunting e as disciplinas vizinhas que produzem insumos e consomem resultados: a CTI que gera hipóteses, a resposta a incidentes que deixa lições e artefatos, e o red teaming que exercita técnicas contra o ambiente. Publicada como documento aberto por equipe de um grande banco europeu, a metodologia estrutura o processo em três fases com subfases claras, initiate, investigate e finalize, e fornece o vocabulário para gerenciar um backlog de caças com rastreabilidade de origem e de produto.

O posicionamento na biblioteca é o de esqueleto de processo por caça individual. O Hunt Loop do capítulo 6 descreve a espiral iterativa de execução, e a TaHiTI descreve o processo gerenciado que envolve essa espiral, da abertura do ticket ao produto entregue, e é essa visão de processo com fases, entradas e saídas que a difere de frameworks de maturidade ou de catálogo. A comparação com OTHF e PEAK nesta nota situa os três na mesma escala de propósito.

2. A Proposta da Taxonomia Integrativa

A palavra taxonomia no nome é deliberada: a TaHiTI classifica as caças por origem e por natureza, permitindo que um programa saiba de onde vêm suas hipóteses e qual tipo de trabalho está sendo feito. Na prática, a metodologia reconhece quatro entradas principais de motivação, a CTI com relatórios e campanhas, o incidente respondido que revela comportamento real, o red teaming que valida técnicas de ataque, e a exploração sobre os próprios dados do ambiente, e cada caça registra a entrada que a originou. Esse registro é o que permite, meses depois, responder com números qual disciplina mais alimenta caças úteis, e onde o programa está investindo demais ou de menos.

A integração funciona nos dois sentidos, e este é o coração da proposta. A CTI recebe do hunting novos TTPs observados, novos indicadores e novas lacunas de cobertura para pautar requisitos; o IR recebe correlatos históricos que aceleram investigações; o red team recebe o mapa de técnicas caçadas para calibrar emulação. Uma caça que nasce de um relatório de CTI e termina alimentando um requisito de inteligência e uma detecção no SIEM é o ciclo completo que a metodologia quer tornar padrão, e não exceção.

3. Fase Initiate

A fase initiate transforma uma motivação em caça definida, e a metodologia a detalha em subfases que evitam o defeito mais comum do hunting amador, começar a consultar dados antes de saber o que procurar. A primeira subfase é o scoping, que delimita o alcance da caça em termos de ativos, período de dados e técnica ATT&CK candidata, com critério de sucesso expresso em vez de implícito. A segunda é a coleta de informação, que reúne o material de contexto: relatórios de CTI relevantes, notas de incidentes anteriores, relatórios de red teaming e conhecimento interno sobre o ambiente, cada item com fonte registrada para rastreabilidade futura.

A terceira subfase é a formulação da hipótese, sempre no formato testável que a biblioteca adota desde o capítulo 7, com fenômeno esperado, dados necessários e o que contaria contra a hipótese. A quarta é a verificação de viabilidade, que cruza a hipótese com o inventário de dados do controle TH.1 e decide entre três caminhos: executar, reformular com telemetria disponível ou arquivar com motivo, realimentando o backlog. O produto da fase initiate é um ticket de caça completo, e não uma intenção, e esse ticket é a unidade de trabalho que as fases seguintes movem pelo processo.

A tabela a seguir resume as subfases de initiate com o produto esperado e o defeito típico quando a subfase é pulada, formato de lista de controle que funciona em revisão de backlog por pares.

4. Fase Investigate

A fase investigate é a execução analítica da caça, e a TaHiTI a organiza em três atividades recorrentes que formam um ciclo interno. A análise de dados executa as consultas, examina resultados e refina a busca, com liberdade metodológica para usar as técnicas de clustering, grouping e stack counting do capítulo 15 conforme o fenômeno exigir. A documentação de resultados intermediários acompanha o trabalho em tempo real, registrando caminhos explorados, descartes e descobertas laterais, e é o que diferencia uma caça auditável de uma sessão de consultas esquecida. A iteração é o terceiro elemento, porque achados frequentemente desviam a caça do rumo original, e a metodologia autoriza explicitamente a reformulação da hipótese em curso, desde que a mudança fique registrada no ticket com a nova formulação.

A disciplina central da fase é o gerenciamento de rabbit holes, os becos sem saída que consomem dias. A TaHiTI trata o desvio como decisão consciente: o hunter marca o desvio, define um tempo máximo dedicado a ele e registra o motivo da exploração, e o desvio que rende vira caça nova no backlog, não extensão silenciosa da atual. Essa regra protege o prazo da caça e preserva o achado lateral, que em muitos programas se perde justamente por não ter para onde ir.

5. Fase Finalize

A fase finalize fecha a caça transformando o que foi aprendido em produtos para os consumidores corretos, e a metodologia a decompõe em subfases igualmente explícitas. O sumário de resultados registra o veredito da hipótese, confirmada, refutada ou inconclusiva, com a evidência que sustenta cada conclusão, porque inconclusiva com motivo documentado é resultado legítimo e valioso. O feedback para as disciplinas parceiras distribui o aprendizado: para a CTI, novos TTPs, indicadores e requisitos derivados; para o IR, correlatos e padrões que aceleram futuras investigações; para a engenharia de detecção, analytics candidatos conforme a ponte do capítulo 18; para o red team, técnicas validadas ou lacunas confirmadas.

A última subfase é a avaliação do processo da própria caça, perguntando o que atrasou, qual dado faltou e se a origem registrada no backlog justificou o esforço, e é essa avaliação que melhora o programa em vez de apenas cumprir o ciclo. O produto final da TaHiTI, portanto, não é um relatório único, é um conjunto de entregas roteadas, com o ticket original atualizado e arquivado como memória do programa, material que a nota de documentação de descobertas do capítulo 7 detalha em formato.

6. Backlog e Produto da Caça

O backlog TaHiTI é a fila gerenciada de caças, e sua qualidade define o programa tanto quanto a execução. Cada entrada carrega metadados mínimos: origem registrada entre CTI, IR, red teaming e exploração; técnica ATT&CK candidata; estado atual entre proposta, iniciada, em investigação, finalizada e arquivada; e o vínculo com o material de origem, como o relatório ou incidente que motivou a caça. A tabela a seguir mostra um recorte de backlog real com estados variados.

O produto da caça, conforme já visto, roteia entregas por consumidor, e o backlog é o instrumento de cobrança dessas entregas: uma caça só sai de finalized quando os produtos têm destino registrado. Essa disciplina conecta o backlog às métricas de hunting do capítulo 11, que medem descobertas e destinos, e não apenas horas gastas. O formato de ticket abaixo representa a entrada mínima do backlog, e é o mesmo formato que o exercício do capítulo 16 pede ao aluno.

ticket: TAHI-H-041
origem: CTI
material_origem: relatorio de campanha de phishing financeira, secao de loader
hipotese: >
  Execucao de DLL suspeita por rundll32 com argumentos de carregamento
  aparece em hosts da area financeira.
tecnica_candidata: T1218.011
dados: telemetria de linha de comando (EDR), 30 dias
estado: em_investigacao
produtos_planejados:
  - analitico para catalogo de deteccoes
  - TTP e infraestrutura para a CTI
dono: hunter do turno A
prazo: 3 dias uteis

O ticket carrega produtos_planejados desde a abertura, e não só no final, porque prometer entrega na fase initiate é o que permite cobrar a entrega na fase finalize. A revisão semanal do backlog percorre os estados, envelhece tickets sem movimento e realimenta hipóteses arquivadas quando intelligence nova muda o contexto, fechando o ciclo de gestão que o backlog exige.

7. Comparação com OTHF e PEAK

As três metodologias respondem perguntas diferentes sobre o mesmo problema, e confundi-las gera adoção frustrada. A tabela seguinte compara os três frameworks nesta pasta pelos eixos que importam na escolha.

Os frameworks são combináveis, e a combinação natural da biblioteca é usar o THRIVE para priorizar, a TaHiTI para conduzir cada caça interna, o PEAK para equilibrar o portfólio e o OTHF para a parcela terceirizada, com o backlog TaHiTI como fonte de demanda para o MSSP. O erro é tratar os nomes como concorrentes exclusivos, descartando processo por falta de plataforma ou vice-versa.

8. Exemplo de Aplicação de uma Caça na Estrutura TaHiTI

Considere a caça H-041 do backlog, motivada por relatório de CTI sobre campanha de phishing com macro que entrega loader via rundll32. A aplicação da estrutura na tabela seguinte mostra o caminho completo com produtos roteados.

O exemplo mostra a vocação integrativa da TaHiTI na prática: uma caça de origem CTI terminou alimentando quatro consumidores distintos, e o registro completo do ciclo é o que permite reproduzir a caça e cobrar as entregas registradas. Entre os produtos planejados, o analítico para o catálogo de detecções foi entregue como regra Sigma candidata, ainda em estado de observação, com a estrutura abaixo.

title: execucao de dll fora de pasta padrao via rundll32
status: experimental
description: >
  Detecta rundll32 carregando DLL de pasta de usuario ou de pasta
  temporaria, padrao observado na caixa TAHI-H-041.
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        Image|endswith: '\rundll32.exe'
        CommandLine|contains:
            - '\Users\'
            - '\Temp\'
    condition: selection
tags:
    - attack.defense_evasion
    - attack.t1218.011
falsepositives:
    - instaladores de software de fabricantes com DLL em pasta de usuario
level: medium

A regra entra no catálogo com status experimental e sai dele apenas depois do período de observação previsto na ponte entre hunting e detecção do capítulo 18, e os falsepositives declarados vêm diretamente da documentação intermediária da fase investigate, e não de suposição posterior. Esse traçado, do achado à regra com contexto preservado, é exatamente o produto que a fase finalize da TaHiTI existe para garantir.

9. Erros Comuns e Pontos de Atenção

A adoção da TaHiTI tropeça nos mesmos obstáculos na maioria dos times, e vale listá-los como checklist de revisão:

• Fase initiate encurtada por pressa, com caça começando sem escopo nem critério de sucesso, e o prazo estourando na investigação sem direção.
• Documentação intermediária adiada para o fim, perdendo os caminhos explorados e tornando o sumário final irreproduzível.
• Rabbit holes sem limite, com desvios consumindo a caça inteira porque ninguém marcou tempo máximo de exploração.
• Finalize reduzido ao sumário interno, com feedback para CTI, IR e detecção esquecido, e a vocação integrativa do framework desperdiçada.
• Backlog sem origem registrada, impossibilitando avaliar quais motivações produzem valor e ajustar o investimento.
• Hipóteses inconclusivas descartadas sem registro, quando a refutação documentada é ativo que evita recaça futura.

O ponto de atenção estrutural é que a TaHiTI pressupõe dono de processo, alguém que movimente tickets, cobre finalize e audite o backlog, e sem essa função o framework degrada para lista de desejos. Em times de três ou mais hunters, o papel rotativo por sprint funciona bem e ainda dissemina conhecimento do ambiente.

10. Integração com o Restante da Biblioteca

O capítulo 7 de processo e metodologias fornece os blocos que a TaHiTI empacota em fases, e a nota de documentação de descobertas do mesmo capítulo detalha o produto de finalize. O capítulo 15 contribui com os controles de preparação e execução que sustentam initiate e investigate, e o capítulo 10 fecha o ciclo com o retorno de TTPs e indicadores para a inteligência, exatamente o feedback que a fase finalize roteia.

Dentro do capítulo 23, o THRIVE pontua e ordena o backlog que a TaHiTI gerencia, o PEAK balanceia as selvas de experiência e fornece a fundação de plataforma, e o OTHF terceiriza parte da execução usando tickets TaHiTI como contrato de demanda, com a comparação da seção 7 orientando a combinação. O exercício de caça baseada em hipótese do capítulo 16 é o laboratório ideal para rodar o ciclo completo da taxonomia com supervisão.