Hunting-to-Detection Bridge

Nota do Capítulo 18, pasta de Frameworks de Detecção.
Estrutura a ponte entre threat hunting e detection engineering: o que vira detecção, o que vira analytics agendado, o que permanece caça manual, com critérios de promoção, template e exemplo completo.
Dialoga com a ADS da pasta, com as métricas de qualidade e com os controles HNT do capítulo 15, que formam as hipóteses que aqui chegam ao destino final.

1. Contexto e Posicionamento na Biblioteca

O capítulo 7 tratou a documentação de descobertas de caça como fim do ciclo, e esta nota reabre o ciclo na ponta oposta: toda caça madura precisa ter um destino decidido, e o destino mais valioso costuma ser uma detecção permanente. A Hunting-to-Detection Bridge é o conjunto de critérios e artefatos que governa essa transição, evitando os dois defeitos clássicos do programa de hunting: achados que morrem em relatório e caças que viram regras ruins por pressa de mostrar resultado.

O posicionamento na biblioteca é o de transformador de investimento em ativo. Caça é trabalho caro, executado por gente sênior, e a promessa do programa é que o ambiente fica mais seguro a cada ciclo, e não apenas que o time fica mais informado. A ponte é o mecanismo que cumpre a promessa, convertendo padrões descobertos em alertas, analytics agendados ou caças recorrentes formalizadas, cada um com o custo de manutenção adequado ao valor entregue.

A nota adota deliberadamente o vocabulário das notas vizinhas. O destino detecção recebe o formato de ADS da nota anterior, com todos os campos preenchidos pelo conhecimento acumulado na investigação. A decisão de destino usa as métricas de qualidade da pasta anterior, prevalência e custo estimado de ruído, e o exemplo final demonstra o caminho completo, do achado bruto à regra validada em produção com SNR monitorado.

2. O Problema da Transição de Caça para Detecção

A transição é difícil por razões estruturais, e não por falta de boa vontade. A caça é exploratória e foge ao padrão, a detecção é permanente e precisa de padrão estável, e o que conecta os dois é a decisão de que o comportamento observado é recorrente o bastante para valer automação. Sem critérios explícitos, essa decisão é tomada pela pressão do calendário, e o resultado é previsível: regras apressadas que afogam a fila de falsos positivos e descredenciam o programa de hunting perante o SOC.

O segundo problema é a perda de contexto na conversão. Uma caça acumula semanas de conhecimento: quais processos participam do padrão, quais softwares legítimos produzem eventos parecidos, quais lacunas de telemetria limitaram a busca. Quando a caça vira regra sem documento, tudo isso se perde, e a regra nasce órfã, sem blind spots e sem falsos positivos conhecidos, exatamente os campos que a ADS existe para preservar. A ponte existe para que o conhecimento caro da caça sobreviva à automação.

O terceiro problema é de expectativa. Nenhum padrão descoberto em caça merece virar alerta automático imediatamente, e a fila de triagem é o recurso mais escasso do SOC. A ponte introduz a disciplina de graduar o compromisso: o padrão entra em produção como observação silenciosa, como analytics agendado ou como alerta, conforme a confiança e a estabilidade medidas, e sobe degraus com evidência, em vez de nascer no degrau mais alto.

Há também um problema de política interna na transição, e ele explica por que a ponte precisa de critérios escritos. Quando a conversão em regra depende do carisma do hunter ou da urgência do momento, o catálogo absorve prioridades flutuantes, e o time de detecção perde a capacidade de planejar sprint. Critérios explícitos transferem a discussão do carisma para o método, e o documento de promoção é a materialização desses critérios em forma auditável.

3. Os Três Destinos do Achado de Caça

Todo achado de caça que produz um padrão candidata-se a um dos três destinos, e a escolha é uma decisão de engenharia com critérios explícitos. A tabela a seguir resume os destinos, o que cada um entrega e as condições típicas de escolha. A regra de ouro é que o destino mais caro de manter, o alerta permanente, só se justifica quando o padrão é estável, discriminante e material para o negócio.

O destino de detecção dedicada é o mais conhecido e o mais restrito, porque exige que o padrão sobreviva ao ambiente real sem afogar a fila. O analytics agendado é o destino subutilizado e frequentemente o mais sábio, cobrindo padrões que valem olhar semanal, mas que não justificam interrupção de plantão, como contas de serviço com comportamento de logon atípico ainda dentro de margens. A caça manual formalizada é o destino honesto para achados exploratórios: o padrão ainda não é confiável, mas a consulta e a hipótese ficam prontas no catálogo de caças para reexecução quando a telemetria ou a ameaça amadurecerem.

Os destinos não são permanentes, e a ponte prevê migração entre eles com evidência. Analytics agendado que acumula três meses de resultados limpos e um padrão consolidado sobe para detecção dedicada com o histórico como prova. Detecção dedicada que degrada em ruído após mudança de parque desce para analytics até novo tuning. Essa mobilidade transforma o catálogo em sistema vivo, e o documento de promoção registra cada migração com a justificativa.

Dois exemplos ajudam a calibrar a escolha de destino em situações limítrofes.

• Padrão de acessos de conta de serviço fora de horário comercial: analytics agendado, porque o volume é alto, a ambiguidade é real e a interrupção de plantão não se justifica a cada ocorrência.
• Padrão de criação de tarefa agendada com binário em caminho de usuário: detecção dedicada, porque a prevalência é baixa, a materialidade é alta e o alerta raramente é falso.

4. Critérios de Promoção

A promoção para detecção dedicada passa por cinco critérios avaliados com dados da própria caça, e não por impressão do autor. Os critérios são deliberadamente operacionais, e cada um tem uma pergunta fechada que a investigação precisa conseguir responder com números, porque a decisão de colocar um padrão na fila de triagem de um SOC é decisão de orçamento de atenção humana.

• Frequência: o padrão aparece em janela razoável, com volume esperado conhecido, porque regra que nunca dispara não se valida e regra que dispara mil vezes por dia não se sustenta.
• Estabilidade: o padrão sobrevive a variações de versão, horário e usuário, observado em pelo menos dois ciclos de negócio, e não é artefato de uma semana de patch ou de uma campanha pontual.
• Discriminância: a prevalência do comportamento legítimo é baixa o suficiente para prometer SNR aceitável, medida com o método da nota de prevalência da pasta anterior.
• Custo de consulta: a consulta roda dentro do orçamento do índice no volume de produção, com custo medido e registrado, porque regra tecnicamente correta que custa caro demais morre no primeiro mês de fatura.
• Materialidade: o comportamento se conecta a um cenário de ataque relevante para o perfil de ameaça, e não apenas a curiosidade técnica do hunter, com a conexão escrita na ADS.

O fragmento a seguir ilustra o formato de registro de avaliação que acompanha a proposta de promoção, anexado ao documento e calculado a partir da janela de observação da caça. O formato força a decisão a ser auditável e permite comparar propostas entre si na reunião de priorização.

avaliacao_promocao CT-2025-014
frequencia:        63 execuções em 90 dias, media de 0,7 por dia
estabilidade:      observado em 2 ciclos, sobreviveu a patch de junho
discriminancia:    prevalencia de 0,4% do parque, 26 hosts
custo_consulta:    1,8% do orcamento de indice em teste de 7 dias
materialidade:     padrao alinhado a T1055 e a perfil de ameaça LockBit
veredito:          promove para detecção dedicada com nível high
condições:         manter analytics agendado por 30 dias em paralelo

A condição de paralelismo merece destaque, porque é a prática que melhor protege a promoção. Manter o analytics agendado rodando por 30 dias após o alerta entrar em produção permite comparar os dois registros, validar que o alerta captura tudo que o analytics capturava e capturar regressões precoces. Ao fim do paralelismo, o analytics é aposentado ou mantido como observação, com a decisão registrada no histórico do documento de promoção.

Além de governar a promoção individual, os critérios alimentam três métricas de acompanhamento do programa de ponte.

• Percentual de caças com destino decidido no prazo de um ciclo após o relatório, que mede se a fila da ponte está sendo consumida.
• Tempo médio entre achado e detecção implantada, que mede a agilidade da transição e tende a cair conforme a esteira amadurece.
• SNR das regras promovidas no primeiro trimestre, que mede a qualidade das promoções e aponta critérios que precisam de endurecimento.

5. Template de Documento de Promoção

O documento de promoção é o artefato central da ponte, e o template a seguir deve ser preenchido por completo antes de qualquer conversão em regra. O formato é enxuto de propósito, cabível em uma página, porque documento longo não é lido, e cada campo aponta para o artefato onde o detalhe vive, mantendo a caça, a análise e a ADS conectadas por referência em vez de duplicação.

DOCUMENTO DE PROMOÇÃO
id_caça:            CT-2025-014
título:             Padrão de lançamento de carga por rundll32 em caminho de usuário
autor:              hunter responsável e data
hipótese_original:  referência ao documento de caça com hipótese e PIR
evidência:          resumo de achados, hosts, janelas e incidentes abertos
padrão_candidato:   descrição técnica precisa do comportamento observado
destino_proposto:   detecção dedicada / analytics agendado / caça formalizada
avaliação:          tabela de critérios da seção 4, com números e fontes
risco_de_ruído:     falsos positivos conhecidos e estratégia de tuning inicial
rascunho_ads:       rascunho da ADS com objetivo e cenário pretendido
paralelismo:        plano de comparação e prazo de aposentadoria do registro anterior
decisão:            aprovada, rejeitada ou condicionada, com revisor e data

Três práticas de uso mantêm o template vivo. O documento é versionado no repositório de detecções, ao lado da ADS, e nunca em sistema de tickets, porque ticket encerra e documento de promoção precisa sobreviver ao encerramento. O campo de decisão registra quem aprovou, porque promoção é decisão de orçamento de atenção, e rastreabilidade importa quando a fila reclama. E rejeições são mantidas no repositório tanto quanto aprovações, porque a lista de padrões avaliados e rejeitados, com motivos, é a memória que impede que a mesma caça seja reproposta a cada troca de hunter.

O preenchimento do template também tem uma ordem útil, que protege contra o viés de confirmação do hunter. Os campos de evidência e de avaliação vêm antes do destino proposto, porque a decisão deve ser consequência dos números, e não o contrário, e o risco de ruído é declarado por quem promove, e não descoberto depois por quem tria. Times que invertem a ordem produzem documentos que justificam decisões já tomadas, e a ponte perde a função de filtro.

6. Exemplo Completo: Caça que Virou Detecção

O exemplo a seguir percorre o caminho completo de uma promoção real em um ambiente hipotético. A caça CT-2025-014 partiu de hipótese de inteligência sobre loaders entregues por phishing, com padrão inicial de rundll32 executado como filho de aplicativos Office e conectando-se à rede nos sessenta segundos seguintes. A consulta bruta produziu 63 execuções em 90 dias no parque, e a investigação classificou 60 como instalações e reparos legítimos de suplementos, conhecidos e explicáveis, restando 3 execuções sem explicação que abriram incidentes e confirmaram um loader real em uma workstation de financeiro.

A avaliação de promoção seguiu o template, com os números da seção 4 registrados e o paralelismo acordado: o padrão entraria como alerta dedicado de severidade high, enquanto o analytics de descoberta continuaria rodando por 30 dias para comparação. A regra Sigma proposta carrega o contexto acumulado na caça, incluindo os falsos positivos conhecidos que viraram filtros, e o fragmento a seguir mostra o coração da regra, com os filtros derivados diretamente dos 60 casos legítimos estudados.

title: Office Spawn de Rundll32 com Rede Seguinte
status: stable
description: Promovida da caça CT-2025-014, cobre T1055 e cadeia de loader
logsource:
    product: windows
    service: process_creation
detection:
    selection_parent:
        ParentImage|endswith:
            - '\WINWORD.EXE'
            - '\EXCEL.EXE'
            - '\POWERPNT.EXE'
    selection_child:
        Image|endswith: '\rundll32.exe'
    filter_legitimo:
        CommandLine|contains:
            - 'shell32.dll,Control_RunDLL'
    condition: selection_parent and selection_child and not filter_legitimo
falsepositives:
    - Instaladores de suplementos Office homologados, ver EXC-2025-019
level: high

O resultado fechou o argumento da ponte com números. Nos 30 dias de paralelismo, a detecção produziu 11 alertas, dos quais 9 foram falsos positivos de instaladores não cobertos pelo filtro inicial, corrigidos na primeira versão de tuning com exclusão datada, e 2 foram verdadeiros positivos de atividade investigada, com SNR final de 4,5 no segundo mês e custo de consulta dentro do orçamento registrado. O analytics original foi aposentado no dia 31, e o documento de promoção, a ADS e o histórico de tuning vivem lado a lado no repositório, consultados por ocasião do primeiro exercício purple que validou a regra contra emulação do loader.

O que o exemplo demonstra, em síntese operacional, é a divisão correta do trabalho. A caça descobriu e explicou o padrão, o documento de promoção governou a decisão com critérios, a ADS preservou a intenção e os limites, o paralelismo protegeu a transição e as métricas da pasta anterior provaram o valor. Nenhuma etapa é dispensável, e a ausência de qualquer uma delas é a explicação da maioria das regras órfãs que qualquer SOC pode listar hoje.

O exemplo também ilustra o que fazer quando a promoção fracassa parcialmente. Se os 30 dias de paralelismo tivessem revelado ruído acima do aceitável, o destino correto seria a reescrita da condição com os novos falsos positivos conhecidos, e não a retirada da regra, porque a caça já pagou o custo de descobrir o padrão. Reescrita com contexto acumulado é barata, e é exatamente por isso que a ponte insiste em documentar tudo antes de automatizar.

7. Erros Comuns e Pontos de Atenção

• Promover por pressão de resultado, convertendo em alerta um padrão observado uma única vez, sem janela de observação nem avaliação de estabilidade.
• Converter a caça em regra sem documento, perdendo blind spots, falsos positivos conhecidos e a hipótese que deu origem ao padrão.
• Escolher alerta como destino padrão de tudo, ignorando analytics agendado e caça formalizada, e transferindo para a fila o custo de padrões ambíguos.
• Ignorar o custo de consulta na decisão, descobrindo o problema na fatura do índice ou na lentidão do SIEM após a implantação.
• Aposentar o registro original imediatamente após a promoção, perdendo o paralelismo que protege contra regressão silenciosa.
• Descartar rejeições, permitindo que padrões já avaliados e rejeitados voltem a consumir semanas de análise a cada novo membro do time.
• Tratar a ponte como obrigação exclusiva do hunter, quando a decisão de promoção é responsabilidade compartilhada com a engenharia de detecção, que recebe a nova regra na fila.

O ponto de atenção que consolida a nota é temporal: a ponte não é um evento, e sim uma fila com governança. Propostas de promoção são priorizadas como qualquer trabalho de engenharia, revisadas por pares e registradas, e o programa de hunting cobra do catálogo o percentual de caças com destino decidido, porque caça sem destino decidido é trabalho caro que evaporou.

8. Integração com o Restante da Biblioteca

Com a pasta, a ponte é consumidora direta: a ADS fornece o formato de destino, a nota de prevalência fornece o método de discriminância e o SNR fornece a meta de qualidade pós-promoção. Com o capítulo 7, a ponte completa o ciclo de caça, conectando a documentação de descobertas a um destino executável, e com os controles HNT do capítulo 15 ela formaliza o que o controle de automação e repetição de caça descreve conceitualmente.

Com o capítulo 19, a relação fecha o circuito de melhoria contínua: as detecções promovidas pela ponte entram na agenda purple do mês seguinte como candidatas a validação, e as lacunas encontradas nos ciclos purple alimentam novas hipóteses de caça, que voltarão pela ponte se descobrirem padrões. Esse circuito, caça, promoção, validação e lacuna, é a espinha dorsal da evolução de um programa de detecção maduro, e cada nota desta biblioteca cobre um trecho dele.

Uma observação de escala encerra a aplicação da ponte em programas grandes. Em ambientes com várias caças simultâneas, a reunião de promoção é o ritual que evita que o repositório vire competição entre hunters, e a agenda fixa, com os critérios da seção 4 impressos, transforma a reunião em leitura de números e não em disputa de narrativas. Programas que pulam o ritual relatam promoções por volume, e o catálogo sente o ruído antes que a gestão entenda o motivo.