Execução de Análises (Investigações)

Nota 04 do capítulo 07 (Processo e Metodologias de Hunting), cobrindo a etapa em que a hipótese é levada aos dados.
Trata da execução iterativa da busca, das técnicas de grouping, stack counting, clustering e hunting por sessão, da documentação em tempo real, das bifurcações, dos falsos positivos e dos critérios de encerramento.
Consome o plano da nota 01, a hipótese da nota 02 e os dados da nota 03, e entrega material para a documentação da nota 05.

1. Contexto e Posicionamento na Biblioteca

A execução é a etapa do processo em que o hunter testa a hipótese contra a telemetria, e é também a etapa em que o processo mais facilmente se dissolve: sem estrutura, a sessão de caça vira uma sequência de consultas improvisadas cuja memória morre quando a aba fecha. Esta nota organiza a execução como um ciclo iterativo e registrável, apresenta as quatro técnicas de busca que estruturam a maioria das investigações, e define como lidar com as duas situações que dominam a prática real: a bifurcação, quando um lead inesperado abre linha nova, e o falso positivo, quando a evidência esperada aparece por causa benigna.

Na biblioteca, a nota executa o plano da nota 01 dentro dos tetos declarados, consulta os dados mapeados na nota 03 e escreve seu rastro em formato que a nota 05 consome sem retrabalho. Dialoga com os controles de técnicas do capítulo 15, que formalizam grouping, stack counting e clustering como práticas nomeadas, e com a análise estruturada do capítulo 05, porque a interpretação de resultados de caça herda os mesmos vieses da análise de inteligência e exige a mesma disciplina de refutação.

2. Execução Iterativa da Busca

A busca de hunting é um ciclo curto e repetido, e não um único interrogatório aos dados. Cada iteração tem quatro passos: refinar a pergunta à luz do que a iteração anterior revelou, escrever a consulta mais estreita que responde à pergunta, triar o resultado com decisão explícita de prosseguir, refutar ou bifurcar, e registrar a iteração no log de caça. Começar estreito e expandir é mais seguro que o contrário, porque uma janela ampla com filtros frouxos afoga a triagem e consome o custo declarado no plano antes da hipótese ser testada de verdade.

Quatro regras de iteração valem para todo o ciclo:

• Uma pergunta por iteração, formulada antes da consulta, e reformulada se a resposta não couber na triagem.
• Janela mais estreita primeiro, com expansão só quando a janela curta não traz resposta suficiente.
• Filtros seletivos antes de projeções e agregações, respeitando a disciplina da nota 01.
• Nenhuma iteração sem registro, nem a que pareceu improdutiva, porque resultado vazio com cobertura verificada também é evidência.

A cadência das iterações precisa respeitar o tempo real do hunter, e a prática recomendada divide a caça em sessões de 2 a 4 horas com pausas de registro. Ao final de cada sessão, o estado da caça deve ser reconstruível por outra pessoa a partir do log, sem consulta à memória do autor. O quadro abaixo mostra o log em tempo real no formato mínimo da biblioteca, uma entrada por iteração, com a decisão tomada.

LOG DE CAÇA: HUNT-2025-014 (T1078.003, contas de serviço fora do padrão)

[S1-10:12] Pergunta: qual o baseline de logons por conta de serviço?
Consulta: baseline_30d.kql | Resultado: 412 contas, 9 sem logon em 30 dias
Decisão: prosseguir com as 9 contas quietas como faixa de interesse

[S1-11:05] Pergunta: onde essas 9 contas autenticaram nos últimos 45 dias?
Consulta: stack_account_host.kql | Resultado: 23 pares conta-host, 2 raros
Decisão: prosseguir com os pares raros; registrar FP conhecido do antivírus

[S2-09:30] Pergunta: o que aconteceu no host FILE04 após o logon raro?
Consulta: timeline_host.kql | Resultado: execução de gpupdate e nada mais
Decisão: bifurcar hipótese de tarefa administrativa não documentada;
linha principal segue com o segundo par raro

Cada consulta citada no log existe em repositório versionado, e o identificador da consulta é o que o relato da nota 05 referencia. Versionar consulta é barato e evita o desencontro clássico do relato que não consegue reproduzir o próprio achado, porque a versão executada não é a versão salva. O repositório também é a memória técnica da operação: consultas antigas com exceções documentadas mostram aos novos hunters por que um filtro existe, e evitam que a mesma cegueira seja redescoberta.

3. Técnicas de Busca: Grouping, Stack Counting, Clustering e Hunting por Sessão

Quatro técnicas estruturam a maioria das investigações, e dominar quando usar cada uma evita o erro de aplicar a mesma forma de busca a tudo. O grouping agrupa eventos por entidade, host ou identidade, para observar comportamento composto em vez de eventos isolados, e é a técnica de abertura para quase toda hipótese de movimento ou uso de conta. O stack counting empilha ocorrências por valor de um campo e examina os extremos da pilha, os valores raros e os valores excessivamente frequentes, porque ambos fogem do padrão; é a técnica mais barata e mais produtiva da caixa de ferramentas.

O clustering agrupa comportamentos semelhantes entre entidades, tipicamente por similaridade de linha de comando, de caminho de arquivo ou de sequência de eventos, e é a técnica que revela famílias de atividade que nenhuma lista de exceção cobriria. O hunting por sessão correlaciona tudo o que uma entidade fez dentro de uma janela coerente, por usuário e dispositivo, ou por sessão web, e é a técnica adequada quando a hipótese envolve sequência, como acesso inicial seguido de descoberta.

Na prática, as técnicas se combinam dentro da mesma caça, e a sequência típica abre com grouping, prossegue com stack counting sobre os campos discriminantes e fecha com hunting por sessão sobre os candidatos. O clustering entra quando a pilha de valores individuais não discrimina, e a similaridade estrutural revela família. A escolha é guiada pela evidência esperada da hipótese: hipótese de uso de conta pede pilha por identidade, hipótese de ferramenta nova pede clustering de linha de comando, e hipótese de sequência pede sessão.

A tabela abaixo posiciona as quatro técnicas por pergunta respondida e exemplo de aplicação.

4. Documentação em Tempo Real e Decisões de Bifurcação

A documentação em tempo real não é burocracia posterior, e sim parte do método, porque a decisão de parar ou bifurcar depende do que já foi testado. O log de caça da seção 2 registra três coisas por iteração: a pergunta, a consulta e a decisão. Sem o registro, a caça longa se perde no próprio caminho, leads promissores são retestados duas vezes e leads abandonados não podem ser retomados semanas depois com contexto. Com o registro, a caça pode ser pausada no teto de esforço e devolvida ao backlog sem perda, exatamente como o plano da nota 01 prevê.

A bifurcação é o momento mais delicado da execução: um lead inesperado promete resultado mais rápido que a linha principal, e seguir sem critério destrói o escopo da caça. A regra da biblioteca é bifurcar registrando, e não bifurcando e esquecendo: o lead vira uma hipótese filha no backlog da nota 02, com vínculo para a caça que o gerou, e a linha principal continua até critério de parada ou encerramento. Bifurcações legítimas incluem infraestrutura desconhecida no caminho de um padrão conhecido, identidade com comportamento composto estranho e campo que revela processo nunca visto no ambiente. A bifurcação ilegítima é aquilo que na verdade é uma segunda hipótese pessoal sem registro, que ninguém mais poderá caçar.

A sessão de execução abre e fecha com checklist mínimo, que mantém a disciplina quando o lead empolga. Na abertura: plano à mão, tetos relidos, log vazio criado e consultas do pacote importadas do repositório. No fechamento: log revisado com decisão por iteração, consultas versionadas, bifurcações registradas no backlog e estado da linha principal descrito em duas frases. A checklist custa cinco minutos e é o que garante que a caça pausada possa ser retomada por outra pessoa.

5. Falsos Positivos e Critérios de Encerramento

Falso positivo em hunting tem nuances que a engenharia de detecção não tem, porque a caça lê contexto que regras automáticas ainda não têm. A classificação útil distingue três casos: o benigno verdadeiro, quando a atividade é maliciosa em forma e legítima em origem, como ferramenta administrativa que usa a mesma técnica do adversário; o ruído de cobertura, quando a fonte registra mais do que deveria e polui a pilha; e a lógica incompleta, quando a consulta acerta a família de eventos e erra o filtro discriminante. Cada caso tem tratamento próprio: o primeiro exige documentação e exceção justificada, o segundo exige ajuste de coleta na nota 03, o terceiro exige refinar a consulta e reexecutar.

Exceções de falsos positivo precisam dos mesmos três atributos de qualquer decisão de segurança: justificativa, dono e validade. Uma exclusão de consulta sem data de revisão é dívida silenciosa, e a prática recomendada é reavaliar exceções a cada 90 dias, porque software legítimo muda e a exceção que protegia a triagem passa a esconder adversário. A contagem e a natureza dos falsos positivos alimentam também a priorização da nota 02, pois hipóteses com ruído crônico precisam de coleta melhor antes de valer outra execução.

A classificação dos falsos positivos também produz inteligência interna, e não apenas limpeza de consulta. O benigno verdadeiro documenta que uma ferramenta legítima usa a mesma técnica do adversário, o que é insumo direto para a análise de TTPs e para as simulações de ataques, porque revela sobreposição entre ferramenta de administração e comportamento hostil. Ruído de cobertura recorrente, por sua vez, é evidência de problema de coleta que nenhuma consulta resolve, e deve gerar requisito na nota 03, e não mais uma exceção.

O encerramento segue os critérios do plano, e a lista abaixo resume os quatro encerramentos legítimos em execução.

• Achado confirmado: a evidência sustenta atividade maliciosa, e a caça abre caso de resposta com a nota 05, acionando o capítulo de resposta a incidentes com o material já organizado.
• Hipótese refutada: a telemetria verificada não sustenta a evidência esperada, e o relato registra a refutação provisória com as consultas executadas, permitindo recaça se a coleta melhorar.
• Lacuna documentada: a execução descobriu que a evidência esperada não é observável no ambiente, e o registro de lacuna da nota 03 gera requisito de coleta formal.
• Teto atingido: o esforço ou custo declarado no plano foi consumido sem encerramento analítico, e o estado congelado no log permite retomada limpa pelo próximo hunter.

6. Exemplo de Investigação Passo a Passo com KQL

O exemplo abaixo executa a hipótese SE o adversário usa contas de serviço fora do padrão, ENTÃO autenticações dessas contas em hosts nunca vistos serão vistas, sobre a fonte de logon da plataforma, com as consultas abreviadas para leitura. O passo 1 constrói o baseline de 30 dias por conta de serviço, e o passo 2 empilha os pares conta e host do último dia para encontrar raridades contra o baseline.

// Passo 1: baseline de logons de contas de serviço nos 30 dias anteriores
IdentityLogonEvents
| where Timestamp between (ago(30d) .. ago(1d))
| where AccountType =~ "Service"
| summarize Logons = count(), HostsDistintos = dcount(DeviceName)
  by AccountUpn
| where Logons > 0

// Passo 2: pilha de pares conta-host nas últimas 24 horas
IdentityLogonEvents
| where Timestamp > ago(1d)
| where AccountType =~ "Service"
| where ActionType =~ "LogonSuccess"
| summarize Logons = count() by AccountUpn, DeviceName
| order by AccountUpn asc, Logons desc

O passo 3 cruza a pilha do dia com o baseline, marcando os pares nunca vistos, e o passo 4 abre a sessão do par raro mais promissor, puxando o que aconteceu no host nas duas horas seguintes ao logon, que é onde a bifurcação ou o fechamento será decidido.

// Passo 3: pares do dia que não existiam no baseline
let baseline = IdentityLogonEvents
| where Timestamp between (ago(30d) .. ago(1d))
| where AccountType =~ "Service" and ActionType =~ "LogonSuccess"
| summarize by AccountUpn, DeviceName;
IdentityLogonEvents
| where Timestamp > ago(1d)
| where AccountType =~ "Service" and ActionType =~ "LogonSuccess"
| join kind=leftanti baseline on AccountUpn, DeviceName
| project Timestamp, AccountUpn, DeviceName, Logons = 1

// Passo 4: linha do tempo do host após o logon raro (exemplo FILE04)
let janela = datetime(2025-05-07T02:10:00Z);
DeviceProcessEvents
| where DeviceName =~ "FILE04"
| where Timestamp between (janela .. janela + 2h)
| project Timestamp, AccountName, FileName, ProcessCommandLine,
  InitiatingProcessFileName
| order by Timestamp asc
| take 200

No exemplo, a leitura do passo 4 mostrou execução de gpupdate seguida de nada, o que classifica o par raro como benigno verdadeiro de tarefa administrativa e gera exceção justificada no log. A hipótese retorna ao backlog como parcialmente testada, com o restante dos pares raros agendado para a próxima sessão, exatamente o encerramento por teto previsto no plano.

A leitura final demonstra o critério de decisão em ação: execução de gpupdate seguida de silêncio processual, com identidade administrativa conhecida, fecha o par raro como benigno verdadeiro. Se o mesmo horário tivesse mostrado criação de conta local ou limpeza de log de segurança, a decisão seria bifurcar para o backlog e abrir caso. O exemplo vale menos pela resposta e mais pelo caminho: cada passo teve pergunta única, consulta estreita e decisão registrada, e a hipótese saiu da execução mais informada do que entrou.

7. Erros Comuns e Pontos de Atenção

O erro mais comum é a consulta larga no primeiro passo, que afoga a triagem e consome o custo do plano antes de testar qualquer coisa. O segundo é não registrar as iterações, transformando a caça em memória volátil e tornando impossível distinguir refutação de abandono. O terceiro é seguir leads sem bifurcação registrada, o que mantém a ilusão de foco enquanto a caça real escapa do escopo declarado e o relato final não descreve mais o que aconteceu.

Um erro sutil merece destaque: tratar o resultado vazio da consulta como refutação. Resultado vazio só refuta quando a cobertura foi verificada, com hosts amostrados confirmados como fonte ativa e campos confirmados como preenchidos, e a sequência correta é verificar cobertura antes, consultar depois e refutar por último. A distinção entre caça que refutou e caça que não olhou é exatamente o que separa um programa maduro de um programa que apenas executa consultas.

Um erro de ferramenta merece registro: confiar na função de histórico da plataforma como documentação, e descobrir meses depois que o histórico expirou junto com a retenção da interface. O histórico da ferramenta é conveniência de triagem, e o log de caça versionado no repositório é documento, com dono, data e vínculo ao plano. A distinção aparece justamente na auditoria, quando alguém precisa reconstruir o que foi consultado e por quê.

8. Integração com o Restante da Biblioteca

A execução desta nota consome o plano da nota 01, a hipótese da nota 02 e os dados da nota 03, e entrega à nota 05 o log de caça, as consultas versionadas e as decisões tomadas, que são a matéria-prima do relato. À nota 06, a execução deixa o critério prático de automação: iterações estáveis, com baixo julgamento humano e custo previsível, são candidatas a agendamento, e iterações que dependem de interpretação de contexto permanecem manuais.

Com o capítulo 15, esta nota operacionaliza os controles de grouping, stack counting e clustering, dando a eles o procedimento de execução que os controles apenas nomeiam. Com o capítulo 05, compartilha a disciplina de refutação e o cuidado com viés de confirmação, já que o hunter que quer achar vai achar, e o log de decisões é o antídoto auditável. Com o capítulo de resposta a incidentes, o achado confirmado entrega o caso com evidência organizada desde o primeiro minuto, reduzindo o tempo entre descoberta e contenção.