Exercício de Threat Hunting - Caça Baseada em Hipótese

Terceira nota do capítulo 16 - Exercícios Práticos. Exercício guiado de caça orientada por hipótese, do formato SE-ENTÃO à promoção do achado em detecção permanente, sobre o abuso de ferramenta administrativa legítima para persistência.
A hipótese do exercício cruza WMI e tarefa agendada (T1047 e T1053.005), a execução usa KQL completo passo a passo, a análise aplica stack counting com baseline de exceções e a documentação segue o padrão do caderno de caça.
Dialoga com a nota 02 do capítulo 06 (hipótese), com o capítulo 07 (processo), com as notas 01 e 02 do capítulo 08 (persistência e movimento lateral) e com as salvaguardas TH.6 e TH.8 do capítulo 15.

1. Contexto e Posicionamento na Biblioteca

Os dois exercícios anteriores treinaram a esteira de resposta e o ciclo analítico; este treina a competência central do hunter, formular uma hipótese sobre o próprio ambiente e executá-la até o veredicto documentado. O cenário é o mais produtivo para treinar: abuso de ferramenta administrativa legítima, porque é o padrão que o antivírus ignora por definição, que o alerta de assinatura não pega e que só a caça descobre. A hipótese cruza duas técnicas que raramente aparecem juntas em automação legítima, execução remota com WMI e criação de tarefa agendada, e o que dá força à hipótese é exatamente essa conjunção no mesmo host, na mesma janela e pela mesma conta.

O exercício dura três horas e exige um SIEM ou plataforma equivalente com os eventos preparados na seção 2. O formato é guiado como os anteriores, mas com um giro deliberado: as consultas entregues são o roteiro, e não a resposta, e o leitor deve ajustar nomes de campo, contas de automação e exceções do próprio ambiente antes de acreditar em qualquer saída. O veredicto da caça, confirmado, refutado ou inconclusivo, é tão válido quanto o achado, e o exercício pontua a honestidade da conclusão tanto quanto a detecção do anômalo.

A caça descrita é fictícia no cenário, mas a estrutura, hipótese, execução, stack, relato e promoção, é a mesma aplicada no caso real HUNT-2025-014 documentado no capítulo 07, e o leitor que já estudou aquela nota reconhecerá o esqueleto; a diferença está no par de técnicas, aqui WMI e tarefa, lá contas de serviço fora do padrão.

2. Preparação: Dados Necessários e Escopo

A caça morre na preparação quando o dado não existe, e a verificação de cobertura é o primeiro passo executável:

O escopo recomendado é de 30 dias, suficiente para capturar cadências de automação mensal e pequeno o bastante para iterar consultas rápido, e o pacote de exceções deve nascer aqui, com as contas de deploy, help desk e backup que o ambiente declara documentadas, porque o stack counting da seção 5 depende desse pacote para não confundir volume com ataque. A lacuna de telemetria é registrada nesta fase: se 4688 não captura linha de comando em parte do parque, o exercício registra a lacuna como achado de preparação, no padrão da nota 03 do capítulo 07, e segue com o dado que existe.

3. Geração e Priorização da Hipótese

A hipótese segue a gramática SE-ENTÃO da salvaguarda TH.6, com critério de validação explícito e mapeamento ATT&CK declarado:

HIPOTESE HYP-2026-009 - Abuso de ferramenta administrativa para persistência
SE um invasor com credencial válida abusa de ferramentas administrativas
legítimas para manter acesso, ENTÃO serão observadas, no mesmo host e em
janela de minutos, execuções de wmic.exe com os argumentos process call
create e criações de tarefa agendada (4698) cujo conteúdo chama
interpretadores (powershell, cmd, mshta, wscript), executadas por conta
interativa fora do pacote de automação documentado.
CRITÉRIO DE VALIDAÇÃO: par wmic mais tarefa correlacionado por host e
conta, com conta ausente da lista de automação e comando fora da janela
de mudança declarada.
ATT&CK: T1047 (Windows Management Instrumentation), T1053.005
(Scheduled Task). Fontes: 4688, 4698, Sysmon 1, telemetria de EDR.

A priorização justifica por que essa hipótese entre outras da fila, e a tabela do exercício usa os três eixos do capítulo 07: dor que a técnica representa, dado disponível e lacuna de detecção atual:

Com os três eixos altos, a hipótese sobe no backlog, e o exercício registra a decisão de priorização com data e responsável, porque backlog sem registro vira fila de simpatia. O erro clássico desta fase é formular a hipótese depois da consulta; quem escreve o SE-ENTÃO primeiro se protege da caça dirigida pelo que a consulta já sabe fazer.

4. Execução Passo a Passo com KQL

O passo 1 caça a execução remota com WMI, com janela fixa e filtro que evita varredura desnecessária:

SecurityEvent
| where TimeGenerated > ago(30d)
| where EventID == 4688
| where NewProcessName has "wmic.exe"
| where CommandLine has "process call create"
| project TimeGenerated, Computer, SubjectUserName, CommandLine, ParentProcessName
| order by TimeGenerated asc

O passo 2 caça as tarefas agendadas cujo conteúdo chama interpretadores, usando o campo de conteúdo validado por ambiente como a nota 01 do capítulo 08 orienta:

SecurityEvent
| where TimeGenerated > ago(30d)
| where EventID in (4698, 4702)
| where TaskContentNew has_any ("powershell", "cmd ", "mshta", "wscript", "rundll32", "regsvr32")
| project TimeGenerated, Computer, SubjectUserName, TaskName, TaskContentNew

O passo 3 correlaciona os dois sinais por host em janela de 10 minutos, que é a materialização do critério de validação da hipótese:

let wmic = SecurityEvent
  | where TimeGenerated > ago(30d) and EventID == 4688
  | where NewProcessName has "wmic.exe" and CommandLine has "process call create"
  | project T_wmic = TimeGenerated, Computer, SubjectUserName;
let tarefas = SecurityEvent
  | where TimeGenerated > ago(30d) and EventID == 4698
  | project T_task = TimeGenerated, Computer, SubjectUserName, TaskName;
wmic | join kind=inner tarefas on Computer, SubjectUserName
  | where abs(datetime_diff("minute", T_wmic, T_task)) <= 10
  | project Computer, SubjectUserName, T_wmic, T_task, TaskName

O passo 4 empilha os eventos por host e conta, preparando a leitura de stack counting da seção seguinte:

let wmic = SecurityEvent
  | where TimeGenerated > ago(30d) and EventID == 4688
  | where NewProcessName has "wmic.exe" and CommandLine has "process call create"
  | summarize Execucoes = count() by Computer, SubjectUserName;
let tarefas = SecurityEvent
  | where TimeGenerated > ago(30d) and EventID == 4698
  | summarize Tarefas = count() by Computer, SubjectUserName;
wmic | join kind=fullouter tarefas on Computer, SubjectUserName
  | extend Execucoes = coalesce(Execucoes, 0), Tarefas = coalesce(Tarefas, 0)
  | order by Execucoes desc

Cada consulta é salva com comentário, data e hipótese no cabeçalho, e a regra do exercício é que nenhuma consulta se perde em histórico de editor: o ambiente de análise isolado da salvaguarda TH.3 é o lugar delas, porque a reprodutibilidade é parte do produto da caça.

5. Análise de Resultados com Stack Counting

Stack counting, a técnica TH.8 do capítulo 15, transforma milhares de eventos em pilhas por atributo e lê os extremos: o topo é automação, a base raramente é interessante, e o que interessa é a pilha que quebra o padrão de volume e de conta. A saída esperada do passo 4, com os dados do exercício:

A leitura correta do stack inverte a intuição de novato: a pilha de 214 execuções é a menos suspeita da tabela, porque volume alto e conta de serviço estável é a assinatura de automação declarada, e a pilha suspeita é a de execução única por conta humana em host que não é servidor de gestão. A confirmação do caso WS-FIN-12 desce ao passo 3, que mostra o par correlacionado: wmic com process call create às 14:02 e tarefa SysHealthTask executando powershell com linha codificada às 14:04, ambos pela conta r.almeida fora da janela de mudança. O exercício termina a análise com o confronto do par contra o pacote de exceções da seção 2, e a conta r.almeida não está nele, o que fecha o critério de validação da hipótese.

6. Documentação do Achado

O relato segue o template do capítulo 07, e o exercício exige as cinco seções preenchidas antes de qualquer promoção:

# Relato de Caça: HUNT-2026-002
Hipótese: HYP-2026-009 | Janela: 30 dias | Fontes: 4688, 4698, MDE
Veredicto: CONFIRMADO (1 host) | Refutado (4 hosts) | Inconclusivo: nenhum
Evidências: 4688 14:02 wmic.exe process call create powershell -enc ...
            4698 14:04 SysHealthTask com powershell -enc, conta r.almeida
Baselines: svc-deploy, svc-helpdesk e svc-backup documentados e excluídos
Lacunas: 4688 sem linha de comando em 40 estações do parque legado
Próximos passos: Sigma derivada, caça recorrente mensal, requisito de coleta

O veredicto separado por host, e não agregado, é o detalhe que evita o relato genérico: a caça confirmou a hipótese em um host e não encontrou nos demais, e essa contagem alimenta diretamente a métrica de caças do capítulo 11. A lacuna de telemetria do parque legado entra no relato com o mesmo peso do achado, porque o requisito de coleta que ela gera é produto tão válido quanto a detecção, e o capítulo 07 defende exatamente esse critério de sucesso.

7. Promoção para Detecção

A detecção permanente derivada do relato traduz a correlação para Sigma, versão do formato que o capítulo 18 adota como padrão de detecção como código:

title: Execução remota com wmic seguida de criação de tarefa agendada
id: 4b7d2c91-8e3a-4f1e-9c55-0a2f6d1b7e33
status: experimental
description: Derivada de HUNT-2026-002; cobre T1047 e T1053.005 em janela de 10 minutos.
logsource:
    product: windows
    service: security
detection:
    selecao_wmic:
        EventID: 4688
        NewProcessName|endswith: '\wmic.exe'
        CommandLine|contains|all:
            - 'process call create'
    selecao_tarefa:
        EventID: 4698
    condition: selecao_wmic | near selecao_tarefa
falsepositives:
    - Automação de deploy e help desk documentada no baseline do programa
level: high

A promoção só se completa com os dois casos de teste, o positivo gerado com Atomic Red Team no laboratório da nota 05 do capítulo 12, e o negativo com a execução da automação documentada de deploy, que não deve disparar. A regra entra versionada no repositório com dono, revisão de 90 dias e a citação do relato de origem, e a caça é convertida em rotina mensal recorrente com a mesma consulta, no padrão da nota 06 do capítulo 07, até que a detecção comprove recall suficiente para a caça passar a investigar outra hipótese.

8. Tabela de Checkpoints

9. Critérios de Avaliação

• Hipótese antes da consulta: o SE-ENTÃO existe por escrito com critério de validação, e a execução é dirigida por ele; consulta que saiu caçando sem hipótese perde o principal que o exercício treina.
• Disciplina de consulta: janela de tempo fixa, filtro de evento e nenhuma varredura de tabela inteira, com as consultas salvas e reprodutíveis por qualquer par.
• Leitura honesta de stack: volume alto interpretado como automação até prova em contrário, exceções confrontadas com o pacote documentado, e nenhuma pilha julgada por impressão.
• Documentação completa: relato com veredicto por host, evidências citadas com horário e lacunas de telemetria declaradas no mesmo peso do achado.
• Promoção efetiva: detecção escrita, testada com caso positivo e negativo, versionada com dono, e caça convertida em rotina recorrente.
• Tempo e postura: exercício completo em até 3 horas, com o analista devolvendo ao SIEM as consultas comentadas e o backlog atualizado com a hipótese seguinte.

10. Integração com o Restante da Biblioteca

O exercício executa na prática a cadeia TH.6, TH.8 e TH.10 do capítulo 15, formulação de hipótese estruturada, stack counting e busca por IOA, e usa as técnicas das notas 01 e 02 do capítulo 08 como repertório: persistência por tarefa agendada e movimento lateral com WMI são exatamente os dois capítulos que sustentam cada passo da execução. A estrutura de documentação vem das notas 05 do capítulo 07, e a conversão do achado em detecção segue o capítulo 18, com a métrica de conversão alimentando os KPIs de hunting do capítulo 11.

O diálogo com o exercício 01 deste capítulo é de complemento de domínio: lá o ponto de partida foi um IOC de campanha externa, aqui é uma hipótese comportamental sem indicador nenhum, e o time que executa os dois no mesmo trimestre treina os dois modos de entrada do framework do capítulo 10. O fechamento recomendado é agendar a caça recorrente derivada no calendário do programa, escolher a próxima hipótese da fila pelo mesmo critério de priorização da seção 3 e escrevê-la em SE-ENTÃO antes de abrir o SIEM, porque o hábito que este exercício instala é esse: primeiro a pergunta escrita, depois o dado.