Automação e Repetição (Hunting contínuo)

Nota 06 do capítulo 07 (Processo e Metodologias de Hunting), fechando o capítulo com a transformação da caça pontual em programa contínuo.
Cobre o caminho da caça manual à agendada, os critérios de quando automatizar, a fronteira entre promoção para detecção e agendamento como analytics, crawlers de hipóteses, métricas e uma agenda semanal de exemplo.
Consome as notas 01 a 05 e entrega continuidade operacional ao programa medido pelos KPIs do capítulo 15.

1. Contexto e Posicionamento na Biblioteca

Uma operação que só caça quando sobra tempo não é um programa, e sim um evento ocasional. A automação e a repetição convertem o esforço analítico pontual das notas anteriores em rotina sustentada: consultas estáveis passam a executar em agenda, hipóteses engavetadas entram em fila de execução periódica, e o hunter humano concentra o tempo no que a máquina não faz, que é interpretar contexto, formular hipótese nova e decidir sobre ambiguidade. Esta nota fecha o capítulo explicando como uma caça manual se torna contínua sem virar fábrica de falsos positivos nem substituir a engenharia de detecção do capítulo 18.

Na biblioteca, a nota consome tudo o que o capítulo produziu: o plano e seus critérios da nota 01, o backlog da nota 02, os dados normalizados da nota 03, o log de execução da nota 04 e o relato com desdobramentos da nota 05. Dialoga com os controles de automação do capítulo 15, que formalizam orquestração e agendamento, e com os KPIs de hunting do mesmo capítulo, porque caça automatizada sem métrica é apenas cron rodando às cegas. A fronteira com o capítulo 18 é um dos pontos centrais desta nota: automação de caça e engenharia de detecção são caminhos distintos para o mesmo achado, e confundi-los produz os dois erros clássicos de programa.

2. Da Caça Manual à Caça Agendada

A transição da caça manual para a agendada segue um caminho de maturidade previsível, e tentar pular etapas é a causa mais comum de automação fracassada. A primeira execução é manual e registrada no formato da nota 04, porque o log revela quais iterações são estáveis. A segunda passagem é manual repetida em janela nova, validando que a consulta resiste a dados diferentes e que a triagem tem critério objetivo. A terceira etapa é a encapsulação: a sequência de iterações vira um pacote de caça com consultas versionadas, parâmetros de janela e procedimento de triagem escrito. Só então vem o agendamento, com frequência definida pela cadência da ameaça e pelo custo da execução.

O pacote de caça é a unidade de automação da biblioteca, e seu conteúdo mínimo garante que a execução agendada produza material triável e não apenas listas de eventos. O quadro abaixo mostra o manifesto de um pacote de caça pronto para agendamento, com os campos que a orquestração lê.

Manifesto de pacote de caça: HB-2025-011

- Nome: contas de serviço fora do padrão
- Hipótese de origem: HYP-2025-037 | Relato original: HUNT-2025-014-R
- Consultas versionadas: q1_baseline.kql, q2_stack.kql, q3_novos.kql
- Janela padrão: últimas 24 horas | Frequência candidata: diária
- Entrada: fonte de logon normalizada | Saída: tabela de pares novos
- Critério de triagem: par novo com host fora da lista de jump servers
- Custo estimado por execução: 40 segundos, 2.1 GB escaneados
- Dono: [nome] | Revisão semestral: [data]

O pacote agendado é parametrizado, e não fixo: janela, teto de itens e filtros de exceção são variáveis lidas na execução, o que permite rodar o mesmo pacote com janela de 24 horas na rotina e janela de 7 dias na retomada após período sem execução. A parametrização também é o que permite testar o pacote em ambiente de menor custo antes de subir a agenda, executando com janela curta e comparando o resultado com a execução manual registrada no relato de origem.

Cada pacote tem versão, e a versão avança quando consulta, filtro ou critério de triagem muda, com histórico no mesmo repositório das consultas da nota 04. O vínculo entre versão e métrica é o que permite julgar mudanças de comportamento: queda brusca de itens após mudança de filtro pode ser melhoria de precisão ou cegueira acidental, e só o histórico de versões responde. Sem versionamento, a automação envelhece em segredo, porque a agenda continua verde enquanto a lógica por baixo apodrece.

A repetição agendada muda a natureza do trabalho humano sem eliminá-lo. A consulta passa a ser executada por máquina, mas o julgamento sobre pares novos permanece humano, e a agenda cria uma fila de triagem com prazo e dono. A disciplina que sustenta o programa é a mesma da nota 04: cada triagem agendada é documentada, e o resultado alimentado de volta no pacote, seja ajustando filtros, seja justificando exceções com validade.

3. Quando Automatizar: Frequência, Custo e Estabilidade

Nem toda caça merece agendamento, e a decisão é de portfólio. O primeiro critério é a frequência da ameaça: se a técnica observada é usada continuamente pelo adversário relevante, a janela entre caças manuais pode ser maior que o intervalo entre incidentes, e a automação é obrigatória. O segundo critério é o custo por execução: consulta que varre terabytes e exige dezenas de minutos de cluster precisa de justificativa de valor proporcional, ou de reformulação na nota 03 antes de entrar em agenda. O terceiro critério é a estabilidade: fonte estável, campo normalizado e critério de triagem objetivo são pré-condições, porque automação sobre fonte instável quebra em silêncio e produz falsa sensação de cobertura.

O quarto critério, menos óbvio, é o custo humano de triagem dos resultados. Um pacote que gera 40 itens por dia consome a capacidade que deveria caçar hipótese nova, e o programa troca caça por fila. A prática recomendada estabelece teto de itens por execução por pacote, e pacote que estoura o teto volta para refinamento, em vez de acumular fila. A tabela abaixo resume os critérios com perguntas de verificação e consequência prática.

A frequência da agenda não é estática, e revisá-la com a inteligência do capítulo 05 é parte da rotina. Campanha ativa relevante para o setor justifica elevar a frequência de pacotes ligados às técnicas da campanha, e período de silêncio justifica reduzir custo e devolver capacidade às caças manuais. A agenda que nunca muda é sinal de que o ciclo com a inteligência está quebrado, e a revisão mensal é o ponto formal onde essa mudança é decidida e registrada.

4. Promoção para Detecção versus Agendamento como Analytics

O destino de uma caça estável tem dois caminhos distintos, e escolher o errado gera os erros clássicos do programa. O primeiro caminho é a promoção para detecção no capítulo 18: quando a lógica é de alta fidelidade, acionável por evento e triável por um analista de alerta em minutos, o achado vira regra permanente com severidade e SLA, e a caça se aposenta, restando a tarefa de medir a regra. O segundo caminho é o agendamento como analytics: quando a lógica exige contexto acumulado, comparação com baseline ou julgamento de critério composto, o resultado não é um alerta por evento, e sim uma fila de triagem de hunting com prazo e dono, avaliada por quem caça.

A distinção tem teste prático direto. Se cada execução gera itens que uma pessoa consegue julgar individualmente com informação disponível, é detecção. Se o valor está na comparação do resultado com histórico, no agrupamento de itens relacionados ou na suspeita que exige investigação, é analytics agendado. O erro oposto ao exagero de automação também existe: manter como analytics agendado algo de fidelidade alta e custo baixo, apenas porque a conversão em detecção exige engenharia, é desperdício permanente de triagem humana que uma regra resolveria. O ciclo correto revisa analytics agendados periodicamente, e todo analytics estável há dois trimestres é candidato a promoção ou aposentadoria.

Toda decisão de destino é documentada no relato da nota 05 e no backlog, com data, autor e justificativa curta. A documentação evita o ciclo de idas e voltas em que a mesma lógica é promovida, rebaixada e promovida de novo por pessoas diferentes, sem memória do porquê. O histórico de destino também alimenta a métrica de conversão do capítulo 15, que precisa distinguir caças encerradas, caças automatizadas e regras promovidas, e sem registro cada figura é estimada à mão.

5. Crawlers de Hipóteses e Orquestração

O crawler de hipóteses é o mecanismo que dá continuidade ao backlog da nota 02: um agendador que, em intervalo definido, seleciona as hipóteses priorizadas elegíveis e executa os pacotes de caça correspondentes, coletando resultados em fila de triagem. A eleição de elegíveis respeita três filtros: prioridade na razão valor sobre custo, dependência de coleta resolvida e ausência de bloqueio de janela ou ambiente. A orquestração mínima cabe nas ferramentas existentes, com agendador da plataforma de busca para pacotes simples, e com SOAR ou fluxo automatizado quando o pacote precisa de enriquecimento, notificação e registro de fila. O exemplo abaixo mostra o agendamento declarativo de dois pacotes em um fluxo semanal.

agenda_semanal_hunting:
  horario_base: "05:30 UTC"      # fora do pico de ingestão e do SOC
  concorrencia_maxima: 2
  notificacao_fila: canal-soc-hunting
  pacotes:
    - id: HB-2025-011            # contas de serviço fora do padrão
      frequencia: diaria
      janela: "ultimas_24h"
      teto_itens: 20
    - id: HB-2025-014            # PowerShell codificado de pais incomuns
      frequencia: diaria
      janela: "ultimas_24h"
      teto_itens: 15
    - id: HB-2025-019            # volume anômalo de DNS TXT
      frequencia: semanal
      dia: segunda
      janela: "ultimos_7d"
      teto_itens: 30
    - id: HB-2025-023            # criação de tarefa agendada em diretório de usuário
      frequencia: diaria
      janela: "ultimas_24h"
      teto_itens: 10
  revisao_mensal: segunda_quinta_feira

Entre o pacote totalmente automatizado e a caça manual há um meio termo produtivo: o notebook de caça, executado sob demanda ou em agenda leve, combinando consultas, enriquecimento e anotações no mesmo artefato. Bibliotecas como a msticpy, mantida para investigação com notebooks, formalizam esse padrão, e o notebook versionado preserva as duas coisas que o cron puro perde, o raciocínio do hunter e a flexibilidade de ajustar o caminho no meio da execução. Para hipóteses que exigem julgamento intermitente, o notebook agendado vale mais que o pacote rígido.

Três salvaguardas acompanham qualquer orquestração de hunting. Execuções precisam registrar custo real por rodada, para que a soma da agenda não estoure o teto acordado com a plataforma. Falhas de consulta precisam alertar, e não apenas registrar, porque agendamento que falha em silêncio é a falsa cobertura mais perigosa do programa. E a fila de triagem precisa de prazo de atendimento, porque item de caça agendado sem prazo vira ruído permanente que ensina a operação a ignorar o canal.

6. Métricas de Caças Automatizadas

A automação sem métrica degrada sem que ninguém perceba, e o conjunto mínimo de métricas cobre execução, qualidade e valor. Execução: rodadas realizadas versus rodadas esperadas, com custo real por execução, expõe falhas silenciosas e estouro de teto. Qualidade: itens gerados por rodada, taxa de falsos positivos na triagem e proporção de itens julgados dentro do prazo medem se a automação está triável ou virou ruído. Valor: hipóteses confirmadas, refutações, lacunas descobertas e conversões em detecção ou coleta ligam a rotina automatizada aos KPIs do capítulo 15, e permitem comparar o retorno da agenda com o retorno das caças manuais do mesmo período.

Métricas de execução, qualidade e valor precisam de definição estável, e as quatro abaixo fixam o vocabulário do programa:

• Rodada: execução completa do pacote dentro da agenda, registrada com custo e duração.
• Item: saída da execução elegível para triagem, contada antes e depois da aplicação de exceções.
• Desdobramento: qualquer saída institucional da triagem, como detecção candidata, requisito de coleta, hipótese filha ou caso de resposta.
• Cobertura viva: proporção de pacotes com rodadas executadas e triadas dentro do prazo na janela de 30 dias, e não a quantidade de pacotes cadastrados.

A métrica mais negligenciada é a idade das exceções acumuladas por pacote. Cada triagem que justifica um falso positivo cria ou estende uma exceção, e o pacote cuja lista de exceções cresce a cada mês está perdendo fidelidade, mesmo com taxa de rodadas verde. A revisão periódica recomendada compara três números por pacote: itens por rodada, exceções ativas e conversão em desdobramento nos últimos 90 dias, e pacote com exceções crescendo e desdobramentos zerados volta para caça manual para reformulação.

As métricas vivem em painel com revisão mensal, e não em relatório anual, porque automação degrada em semanas e não em anos. O painel mínimo tem quatro visões: rodadas esperadas contra executadas por pacote, itens gerados e triados por pacote, custo real de consulta por semana e desdobramentos por trimestre. Cada visão tem dono, e o dono decide na revisão mensal entre manter, refinar, rebaixar para manual ou aposentar o pacote, com a decisão registrada no manifesto.

7. Exemplo de Agenda Semanal de Hunting

A agenda abaixo ilustra um programa com dois hunters em tempo parcial, combinando pacotes automatizados, caças manuais agendadas e governança. Ela pressupõe a fila do backlog da nota 02 e alimenta os KPIs do capítulo 15 com o registro das notas 04 e 05.

A agenda é deliberadamente realista sobre onde o tempo humano vai: metade da semana em triagem e caça, um bloco de governança e um bloco de estudo, porque programa que só tria não gera hipótese nova e programa que só estuda não caça. Os horários de execução automática ficam fora do pico, e toda fila tem prazo, o que mantém o canal confiável para a resposta a incidentes quando um item de caça precisa virar caso.

A agenda se adapta ao nível de maturidade da operação, e o formato acima pressupõe fila alimentada e pacotes já validados. Em maturidade inicial, com backlog curto e sem pacote automatizado, a mesma grade vale com caças manuais nos dois primeiros dias e governança na sexta, e a automação entra quando os primeiros pacotes completarem três execuções manuais estáveis. Em maturidade alta, os blocos de quarta e quinta tendem a se tornar triagem profunda de filas e engenharia de pacotes novos, com as caças manuais concentradas nas hipóteses de maior custo analítico.

8. Erros Comuns e Pontos de Atenção

O erro mais comum é automatizar a caça inteira em vez de automatizar iterações estáveis, o que congela a curiosidade analítica em cron e deixa de explorar o que mudou no ambiente. O segundo erro é usar o agendamento como refúgio da decisão de promoção, mantendo para sempre em analytics agendado o que deveria ser regra de detecção com SLA, e consumindo triagem humana em julgamento repetível. O terceiro é ignorar o custo acumulado da agenda, somando pacotes aprovados individualmente até o conjunto estourar o orçamento de consulta e de triagem da operação.

Um erro sutil merece destaque: medir o programa pelo número de consultas agendadas, que é métrica de esforço e não de resultado. A agenda com três pacotes bem triados e dois desdobramentos por trimestre vale mais que a agenda com vinte pacotes cuja fila ninguém abre. O indicador que resume a saúde do programa contínuo é a combinação de taxa de rodadas executadas com conversão em desdobramento, porque execução sem conversão revela pacotes mal formulados, e conversão sem execução revela agenda fantasma.

Um erro operacional recorrente é o pacote órfão, aquele cujo dono saiu da função e cuja fila continuou sendo gerada sem que ninguém a triasse. A revisão mensal deve verificar o dono de cada pacote como verifica as rodadas, e pacote sem dono ativo é automaticamente candidato a rebaixamento para caça manual, porque automação sem responsável é exatamente o tipo de cobertura que falha em silêncio. O inventário de pacotes com dono, frequência e última rodada triada é, na prática, a página inicial do programa contínuo.

9. Integração com o Restante da Biblioteca

Esta nota fecha o ciclo iniciado na nota 01: o plano ganha hipótese na nota 02, dados na nota 03, execução na nota 04, relato na nota 05 e continuidade aqui, com o retorno constante ao backlog garantindo que o processo seja espiral e não fila morta. Os pacotes de caça são a ponte formal com o capítulo 18, que recebe as promoções a detecção, e com o capítulo 15, que recebe as métricas de execução e conversão nos KPIs de hunting.

Com o capítulo 02, os requisitos de coleta gerados pela revisão dos pacotes mantêm a base de dados apta à automação, e com o capítulo 05, os resultados recorrentes alimentam a inteligência que gera as próximas hipóteses, fechando o loop inteligência e caça descrito nos capítulos de integração. O programa contínuo bem calibrado reduz o dwell time por verificação constante das técnicas mais prováveis, e liberta o tempo humano para o que a automação não cobre: formular a próxima pergunta certa.