TH.11 - Hunting de Endpoint

Nota do grupo HNT (Threat Hunting) do Framework CTH, seção "15 - Framework CTH - Controles".
Deriva do Capítulo 13, controle TH.11, e opera sobre a telemetria definida em DAT.1 e DAT.4.
Papel no programa: caçar atividade adversária direto nos endpoints, onde payloads executam,
persistência é instalada e a maioria das técnicas ATT&CK deixa rastro antes de qualquer alerta.

1. Contexto e Posicionamento no Framework CTH

O hunting de endpoint é o controle TH.11 do grupo HNT e representa a camada de investigação mais próxima do comportamento real do
adversário. A maior parte da cadeia de ataque se desenrola na máquina: o payload executa, a persistência é registrada, as credenciais
são acessadas e os dados começam a se mover. Ferramentas automatizadas como antivírus e regras de EDR cobrem parte desse espaço, mas
técnicas living-off-the-land, malware fileless e uso criativo de binários nativos frequentemente passam sem disparar um único alerta.

Este controle assume que a organização já coleta telemetria de endpoint por meio de DAT.1 (logs de endpoints), com Sysmon ou
equivalente, e que essa telemetria chega ao SIEM por DAT.4. O hunter não cria dados novos aqui: ele formula hipóteses com o método de
TH.4 e TH.6, prioriza em TH.5 e executa consultas repetíveis sobre o acervo existente. Quando a telemetria de longo prazo não alcança o
que se procura, TH.3 fornece o ambiente isolado e o Velociraptor oferece coleta sob demanda, tema tratado mais adiante nesta nota.

A diferença entre hunting de endpoint e resposta a incidentes é de intenção e de escopo. A resposta a incidentes parte de um alerta ou
denúncia confirmada; o hunting parte de hipótese não confirmada e busca evidências em massa de dados que ninguém olhou antes. O
resultado positivo de um hunt qualifica uma atividade suspeita, gera caso de IR quando confirmado e produz detecções novas quando
confirmado como benigno, alimentando o ciclo de melhoria contínua do framework.

2. Telemetria de Endpoint como Campo de Caça

O campo de caça principal é o conjunto de fontes que descreve o que aconteceu na máquina. Em ordem de valor para o hunter, destacam-se
as seguintes fontes, todas cobertas pelo guia de coleta de DAT.1.

A regra prática é que cada hipótese de endpoint deve citar explicitamente qual dessas fontes vai consumir e qual campo vai examinar. Um
hunt sem fonte definida vira exploração aleatória e consome horas sem produzir decisão. O mapeamento ATT&CK de TH.1 fornece a ligação
entre técnica adversária, fonte de dados e evento concreto, e vale reabrir esse inventário antes de escrever a consulta.

3. Padrões de Suspeita Recorrentes

Alguns padrões aparecem em quase toda caça de endpoint madura. Eles não são maliciosos por si só, mas formam a base estatística das
hipóteses de TH.6 e merecem domínio de cor pelo analista.

3.1 LOLBins e binários nativos

Living-off-the-land é o uso de binários assinados e presentes por padrão no sistema para fins adversários. Os campeões de frequência em
relatos de incidentes são os seguintes, com o padrão que costuma diferenciá-los do uso legítimo.

3.2 Execução de temp e AppData

Binários executados de diretórios graváveis pelo usuário são o padrão clássico de queda inicial de malware. Executáveis em temp,
AppData Local, AppData Roaming e em caminhos de descompactação de browser merecem hunt permanente. A variação útil é comparar
assinatura e editor: um binário legítimo de software corporativo quase nunca roda desses caminhos, e quando roda, tem publisher
reconhecível e estável no tempo.

3.3 Ofuscação em PowerShell

PowerShell com o flag -enc entrega a linha de comando em Base64, o que esconde o conteúdo real do analista desatento. Padrões de caça
incluem: comando codificado seguido de downloadString ou Invoke-Expression, concatenação de strings para montar comandos, uso de
backtick ou aspas quebradas para evitar correspondência de assinatura, e execução com -w hidden ou -nop -noni. O evento 4104 do
PowerShell permite ver o bloco de script decodificado, e o hunt deve cruzar 4104 com o Sysmon 1 para ligar o que foi escrito ao
processo que executou.

3.4 Persistência em Run keys e tarefas agendadas

Mecanismos de persistência que sobrevivem a reboot são o objetivo quase universal do adversário após acesso inicial. Os pontos de caça
prioritários são: escrita em Run e RunOnce por processo não instalador, criação de serviço com binário em caminho gravável pelo
usuário, tarefa agendada com gatilho de logon e ação apontando para temp ou PowerShell codificado, e WMI subscription por evento. O
evento 4698 registra a criação de tarefa com a ação em texto plano, e o Sysmon 13 cobre as escritas de registro com o valor final
gravado.

3.5 Mapeamento rápido para ATT&CK

Os padrões desta seção se conectam direto ao mapeamento de técnica usado nas hipóteses de TH.6. Ter o mapeamento à mão evita retrabalho
na hora de registrar o hunt e de propor a detecção correspondente.

4. Consultas de Exemplo em KQL

A consulta a seguir procura linha de comando com combinação de download e execução indireta, reduzindo ruído com whitelist de caminhos
de ferramenta interna.

DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("powershell.exe", "pwsh.exe", "cmd.exe", "mshta.exe",
                      "rundll32.exe", "certutil.exe", "bitsadmin.exe")
| where ProcessCommandLine has_any ("-enc", "FromBase64String",
      "downloadstring", "IEX ", "Invoke-Expression", "urlcache",
      "-w hidden", "-nop", "http://", "https://")
| where InitiatingProcessFileName !~ ("sccm agent.exe", "chef-client.exe")
| where ProcessCommandLine !contains "microsoft.com"
| project Timestamp, DeviceName, FileName, ProcessCommandLine,
          InitiatingProcessFileName, InitiatingProcessCommandLine,
          AccountName
| sort by Timestamp desc

A segunda consulta busca processos de Office iniciando filhos incomuns, padrão de entrega de phishing com macro ou exploração de
documento.

DeviceProcessEvents
| where Timestamp > ago(30d)
| where InitiatingProcessFileName in~ ("winword.exe", "excel.exe",
      "powerpnt.exe", "outlook.exe")
| where FileName !in~ ("regsvr32.exe", "winword.exe", "excel.exe")
| where FileName in~ ("cmd.exe", "powershell.exe", "wscript.exe",
      "cscript.exe", "mshta.exe", "rundll32.exe", "certutil.exe")
| summarize NetCount = dcount(ProcessCommandLine), Hosts = dcount(DeviceName)
          by InitiatingProcessFileName, FileName, AccountName
| where NetCount > 1
| sort by Hosts desc

5. Coleta Sob Demanda com Velociraptor

Quando a hipótese exige dado que não está no SIEM, como inventário atual de tarefas agendadas ou listing de Run keys em centenas de
hosts, o Velociraptor resolve com coleta sob demanda. A consulta VQL abaixo, por exemplo, lista tarefas agendadas cujo executável está
em caminho gravável pelo usuário, resultado direto de uma hipótese de persistência.

SELECT TaskName, Path, Action,
       concat(Action.Executable, " ", Action.Arguments) AS FullCommand
FROM Artifact.Windows.System.TaskScheduler()
WHERE FullCommand =~ "(?i)(temp|appdata|powershell|-enc|http)"

O padrão de trabalho recomendado é implantar o cliente do Velociraptor com agentes de longa duração em TH.3, criar o hunt como artefato
versionado, executar contra o fleet inteiro ou contra um grupo de hosts críticos e armazenar o resultado para análise offline. Cada
coleta deve registrar data, hosts alvo e artefato usado, para que o hunt seja reprodutível por outro analista. Essa reprodutibilidade é
o que distingue hunting profissional de curiosidade ad hoc.

6. Correlação de Eventos para Qualificar um Achado

Um processo suspeito isolado quase nunca fecha um hunt: é a correlação de três planos que qualifica o achado como incidente em
potencial. O plano de execução mostra o processo, o plano de arquivo mostra o que ele escreveu no disco e o plano de rede mostra para
onde ele falou. A tabela abaixo resume a checagem padrão de qualificação.

Um exemplo encadeado: rundll32 com URL na linha de comando, filho de winword, que escreveu DLL em AppData Roaming, resolveu domínio
recém-registrado e criou tarefa agendada com -enc é caso fechado de IR, não é hunt pendente. Já rundll32 com URL disparado por software
de gestão reconhecido, sem escrita de arquivo e sem persistência, tende a ser falso positivo de gestão interna, anotado no registro do
hunt e transformado em exceção de detecção.

7. Salvaguardas por Nível de Maturidade

As salvaguardas abaixo seguem o padrão de subcontroles do framework, do nível Básico ao Avançado, e descrevem o compromisso mínimo de
cada patamar.

8. Erros Comuns e Pontos de Atenção

O erro mais frequente é tratar processo suspeito como evidência fechada. Software legítimo de backup, agente de gestão, deploy e até
ferramentas de TI interna usam exatamente os padrões que o hunter procura: execução de temp, linha de comando longa, conexão a domínio
externo. Antes de escalar, o analista precisa validar publisher do binário, presença do mesmo padrão em outros hosts da mesma função e
histórico do par processo e pai no baseline de TH.2. Sem essa validação, o hunt vira fonte de alarme falso e perde crédito interno.

Scripts de gestão interna são a segunda armadilha. Equipes de infraestrutura criam tarefas agendadas com PowerShell codificado, baixam
pacotes de repositórios internos e executam binários de caminhos não padrão, e tudo isso aparece no hunt como suspeito. A mitigação é
documentar essas ferramentas com o time de TI e embutir a lista no processo de qualificação, em vez de descartar achados manualmente a
cada execução. Outra falha comum é caçar apenas por nome de binário, ignorando a linha de comando: rundll32 sem argumento é ruído,
rundll32 com função exportada suspeita é sinal, e só a linha de comando separa os dois.

A conversão em detecção fecha o ciclo: todo achado recorrente benigno deve virar regra de supressão documentada, e todo achado
malicioso deve virar detecção de alta confiança no DET.x ou regra Sigma versionada no pipeline de AUT.3. A integração natural deste
controle é com TH.12, que pega a ponta de rede do mesmo achado, com TH.13, quando a suspeita exige análise de memória, e com IR.1,
quando a qualificação confirma comprometimento real.