Abordagem Exploratória (Complementar)

Nota do grupo "17 - Tipos de Threat Hunting", derivada do Capítulo 21 do PDF de referência do Framework CTH.
Esta nota cobre a quarta abordagem do capítulo: exploração aberta do ambiente, sem hipótese predefinida, guiada por curiosidade e experiência.
Papel no programa: descobrir o que ninguém perguntou, revelar telemetria inesperada e alimentar novas hipóteses formais, com limite de tempo e registro do caminho.

1. Contexto e Posicionamento no Framework CTH

Além dos três tipos estruturados, o capítulo 21 reconhece a caça exploratória ou não estruturada como abordagem legítima. Nela, o threat hunter não possui hipótese predefinida nem inteligência específica guiando a busca: ele explora livremente os dados disponíveis, seguindo intuição, experiência e curiosidade investigativa. O capítulo recomenda que até 10 por cento do tempo de hunting seja reservado à exploração livre, incentivo deliberado à descoberta por serendipidade, sem que ela substitua as abordagens estruturadas como método principal.

A posição correta desta abordagem no programa é complementar por design. O comparativo do capítulo atribui a ela maturidade mínima M1 e direcionamento por intuição e experiência, o que a torna viável desde o primeiro dia; em contrapartida, é o único tipo sem replicabilidade intrínseca, e por isso o Framework exige disciplina de registro e transformação de achado em hipótese formal. Esta nota detalha o papel legítimo, as técnicas associadas, um exemplo de sessão, os riscos e as salvaguardas que tornam a exploração produtiva em vez de dispersiva.

2. Definição e Natureza da Abordagem

A exploração é a busca aberta do ambiente sem pergunta pré-formulada. O hunter parte de um conjunto de dados, geralmente agregações de processos, autenticações ou tráfego, e navega pelos padrões que emergem, investigando o que parece fora de lugar, incomum ou simplesmente mal compreendido. Não há estado final binário de confirmada ou refutada: a sessão termina quando a caixa de tempo se esgota ou quando um achado merece virar hipótese estruturada no formato de TH.6.

O valor do método vem da experiência acumulada do hunter. O profissional que já analisou centenas de pilhas de processos reconhece em segundos o que é estranho; quem conhece o ambiente sabe que aquele host deveria ter exatamente quatro processos recorrentes. É por isso que o capítulo situa a abordagem tanto na fase inicial do programa, quando a equipe está se familiarizando com os dados, quanto nas mãos do hunter veterano, que percebe padrões sutis durante investigações rotineiras e merece tempo formal para aprofundá-los.

A matéria-prima da sessão exploratória são agregações pré-computadas. Contrariamente à imaginação popular, o hunter exploratório não abre caixas de log cruas: ele navega por pilhas, histogramas e grafos produzidos no ambiente isolado de TH.3, que resumem milhões de eventos em superfícies navegáveis. Quanto melhor a camada de agregação de TH.8 e TH.9, mais produtiva a sessão, porque o tempo humano se concentra em interpretação e pivô, e não em espera de consulta.

3. Papel Legítimo e Complementar

A exploração cumpre três papéis que os tipos dirigidos não cobrem bem. Primeiro, descobrir o que ninguém perguntou: hipóteses só testam o que foi imaginado, e a imaginação depende de conhecer o ambiente de verdade; a navegação livre revela ativos, contas, agendamentos e fluxos que não entram em nenhum inventário formal. Segundo, achar telemetria inesperada: sessões exploratórias frequentemente descobrem fontes de dados esquecidas, cobertura parcial e campos não aproveitados, alimentando o inventário de TH.1 e as lacunas de DAT.x.

Terceiro, alimentar o backlog de hipóteses. Muitos achados significativos em programas maduros nasceram de explorações que depois foram formalizadas como hipóteses estruturadas; a exploração é a fonte da matéria-prima, e a hipótese formal é o produto acabado. Nesse sentido, a abordagem funciona como sensor de oportunidade para TH.5 e TH.6, garantindo que o backlog não fique restrito a relatórios de CTI e a lacunas já mapeadas em MAP.4.

4. Técnicas Associadas

A exploração livre usa as mesmas técnicas analíticas dos tipos dirigidos, com o diferencial de que a escolha da próxima consulta nasce do resultado anterior, e não de um plano. A tabela abaixo resume o papel de cada técnica do Framework na sessão exploratória:

O stack counting é a porta de entrada mais produtiva, porque transforma milhões de eventos em listas curtas de raridade. O grouping entra quando a raridade pede contexto em torno de uma âncora, como um binário incomum ou uma conta recém-criada. O clustering, executado em notebook do ambiente TH.3, dá visão de forma: pontos isolados de um cluster de hosts são candidatos imediatos a investigação. A navegação livre atravessa tudo isso, e é justamente ela que precisa de limites.

A variação temporal do stack counting, aplicando a dupla pilha de entidade e hora, é especialmente útil na exploração, pois separa processos que rodam continuamente de processos que aparecem em rajadas isoladas. Rajadas repetidas em poucos hosts merecem atenção prioritária, porque o padrão lembra execução manual de ferramenta administrativa ou staging de ataque:

DeviceProcessEvents
| where Timestamp > ago(7d)
| summarize execucoes = count() by DeviceName, FileName, hora = bin(Timestamp, 1h)
| where execucoes == 1
| summarize rajadas = dcount(hora) by DeviceName, FileName
| where rajadas >= 3
| order by rajadas desc

5. Exemplo de Sessão Exploratória

Um hunter reserva duas horas de exploração, conforme a caixa de tempo da política interna, e começa pela pilha de processos por host dos últimos 14 dias. A consulta abaixo lista os nomes de processo que aparecem em no máximo duas máquinas do parque, ordenados pela raridade acumulada:

let pilha = DeviceProcessEvents
| where Timestamp > ago(14d)
| summarize execucoes = count() by DeviceName, FileName;
pilha
| summarize hosts = dcount(DeviceName), total = sum(execucoes) by FileName
| where hosts <= 2
| order by total asc

Entre nomes esperados de ferramentas de inventário e agentes de backup, uma entrada chama atenção: um binário de acesso remoto aparece em exatamente um host, com 37 execuções em 14 dias. O hunter pivota para a timeline daquele host com grouping TH.7 em torno da âncora do binário, e o contexto revela o padrão: execução iniciada sempre por um usuário de suporte terceirizado, conexões de saída para endereço externo fixo, e criação de serviço de autoinicialização no primeiro dia.

A trilha continua no CMDB de INS.1 e na gestão de mudanças: o host pertence a um laboratório, o fornecedor tem contrato ativo, mas não existe registro de ferramenta de acesso remoto aprovada para esse fornecedor, apenas canal VPN governado. A sessão termina na caixa de tempo com o achado qualificado como suspeito de uso de ferramenta não governada, provavelmente conveniência do fornecedor e não intrusão. No dia seguinte, o achado vira hipótese formal em TH.6: SE ferramentas de acesso remoto não governadas existem no parque, ENTÃO a varredura por assinaturas de executáveis conhecidos dessa categoria, cruzada com serviços de autoinicialização, listará todas as ocorrências nos últimos 90 dias. A hipótese priorizada em TH.5 descobre, na execução posterior, mais dois hosts com o mesmo padrão e gera política de bloqueio com AUT.3.

A cronologia da sessão exemplifica a disciplina de caixa de tempo:

6. Riscos da Exploração e Como Mitigá-los

A mitigação mais importante é o registro do caminho. Diferente da caça por hipótese, que já nasce documentada, a exploração só tem valor organizacional se a trilha sobreviver: quais agregações foram vistas, qual pivô levou a qual descoberta, qual hipótese emergiu. Sem esse registro, o programa depende da memória individual e repete explorações que já foram feitas, ou pior, perde achados que não couberam na sessão.

A transformação de achado em hipótese formal é o segundo mecanismo de proteção. O achado exploratório é apenas a pergunta; a resposta robusta vem da hipótese testável com critério de refutação, executável por qualquer analista. Essa fronteira separa o papel saudável da curiosidade do risco de um programa baseado em talento individual não escalável.

O template abaixo registra a sessão e garante que a trilha sobreviva ao fim da caixa de tempo:

sessao_exploratoria:
  id: EXP-2025-007
  data: 2025-03-19
  duracao: "120 minutos"
  hunter: hunter.matricula-412
  datasets: ["DeviceProcessEvents 14d", "SecurityEvent 14d"]
  consultas_executadas:
    - "kql/exploracao/pilha_processos_hosts.kql"
    - "kql/exploracao/pilha_temporal_rajadas.kql"
    - "kql/exploracao/grupo_ancora_binario.kql"
  pivots:
    - "Binario de acesso remoto presente em um unico host"
    - "Timeline do host LAB-034 com grouping TH.7"
    - "Cruzamento com CMDB e gestao de mudancas"
  achado: "Ferramenta de acesso remoto nao governada usada por fornecedor de suporte"
  qualificacao: suspeito
  produto:
    - "Hipotese formal HIP-2025-021 proposta para TH.5"
    - "Lacuna de telemetria: logs de instalacao de software ausentes em 9 hosts"
  link_sessao: "repo/hunting/sessoes/EXP-2025-007.md"

7. Quando Usar a Exploração

A abordagem rende mais em três situações. Primeira, maturidade alta: com baselines sólidos e backlog diversificado, o hunter tem contexto suficiente para reconhecer raridade real; em programas imaturos, a exploração tende a terminar em lista de dúvidas sem resposta, o que ainda vale como inventário, mas não como caça. Segunda, após mudanças grandes no ambiente: migrações, aquisições, fusões de diretórios e novas plataformas criam estados de exceção que nenhum baseline capturou, e a exploração mapeia o novo normal antes que ele se consolide.

Terceira, quando a base de hipóteses está esgotada ou estagnada: se o backlog de TH.5 não recebe insumos novos de CTI, de simulação ou de incidentes, a exploração é o mecanismo de renovação. Nas demais situações, os tipos dirigidos devem dominar a agenda, e a exploração ocupa a fatia residual de até 10 por cento do tempo recomendada pelo capítulo 21, registrada no planejamento trimestral do grupo GOV.

8. Salvaguardas por Nível

Critérios de sucesso mostram se a prática está rendendo o que promete:

9. Erros Comuns e Pontos de Atenção

• Deixar a exploração virar o método principal. Sem os tipos dirigidos dominando a agenda, o programa fica dependente de sorte e de veteranos, sem replicabilidade nem métrica.
• Explorar sem caixa de tempo. Sessões abertas consomem a capacidade do time e produzem relatos orais que ninguém consegue auditar depois.
• Pular o registro do caminho. O pivô que levou ao achado vale tanto quanto o achado; sem ele, a próxima sessão começa do zero.
• Confundir exploração com resposta a alertas. Investigar alerta é trabalho reativo do SOC; exploração parte de agregações sem alerta, com intenção de descoberta.
• Fechar a sessão sem produto. Todo encerramento deve ter um dos três produtos: hipótese formal proposta, item de lacuna de telemetria em DAT.x ou atualização de conhecimento do ambiente em TH.1.
• Ignorar OPSEC e LGPD. Navegar por dados de usuário exige as mesmas restrições legais e de privacidade dos demais tipos, conforme o grupo GOV.
• Tratar curiosidade como substituta de critério. Intuição aponta onde olhar, mas a qualificação do achado usa as mesmas evidências e enriquecimentos dos outros tipos.

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

A exploração se alimenta do inventário de TH.1, da telemetria centralizada de DAT.4 e das agregações produzidas por TH.8 e TH.9, preferencialmente no ambiente isolado de TH.3. Na saída, ela abastece TH.5 com itens novos, TH.6 com hipóteses formais, DAT.x com pedidos de telemetria e CTI.9 com contexto interno que complementa a inteligência externa. O comparativo do capítulo 21 deixa claro o papel no conjunto: a inteligência dá o direcionamento, o comportamento valida o normal, a hipótese estrutura a busca, e a exploração descobre o que ainda não foi perguntado.

Em termos de métricas, o tipo exige tratamento especial em MET.2, pois produto por sessão não é achado de comprometimento, e sim hipótese originada, telemetria descoberta e conhecimento de ambiente registrado. Acompanhar essas três saídas evita o erro clássico de avaliar exploração com régua de detecção e, com isso, desestimular a prática que sustenta a renovação do backlog de todos os outros tipos.