Threat Hunting: O Que É e Como Funciona

Threat hunting é a prática de buscar proativamente em redes e endpoints por atacantes que já ultrapassaram suas detecções existentes. Começa de uma suposição simples e desconfortável: algo ruim pode já estar dentro, e nenhum alerta disparou para isso. Em vez de esperar por uma regra SIEM disparar, um caçador forma uma hipótese e vai procurar evidências para confirmá-la ou descartá-la.

Por que apenas detecção não é suficiente

Detecção baseada em assinatura e em regras captura padrões conhecidos. Atacantes usando living-off-the-land binaries (LOLBins), credenciais válidas ou técnicas lentas e de baixo volume podem ficar abaixo desses limiares por semanas. Threat hunting preenche essa lacuna tendo um humano questionando ativamente os dados: faz sentido esse PowerShell invocado de uma estação de finanças às 2 da manhã? Por que svchost.exe está fazendo uma conexão de saída para um IP sem reverse DNS?

Isso não é resposta a incidente. IR começa depois que você sabe que algo aconteceu. Hunting começa quando você ainda não sabe, e o objetivo é descobrir isso antes que um evento maior force a questão.

Os três pontos de partida comuns

A maioria das buscas começa por um de três ângulos:

• Baseada em inteligência: um novo relatório de ameaça descreve um TTP (por exemplo, abuso de scheduled task para persistência), e você verifica se está presente no seu ambiente.
• Consciência situacional: você observa o que é realmente incomum para sua organização — uma conta de serviço autenticando de um país em que nunca o fez, ou um pico em tráfego SMB entre estações de trabalho que normalmente só conversam com servidores.
• Baseada em análise: você cria uma linha de base de comportamento normal (árvores de processo, horários de login, volume de consultas DNS) e busca por outliers estatísticos em relação a ela.

MITRE ATT&CK é a referência que a maioria das equipes usa para estruturar hipóteses. Em vez de "procurar por malware", você escolhe uma técnica como T1053 (Scheduled Task/Job) e pergunta: como isso se pareceria em seus Windows Event Logs ou telemetria EDR, e posso consultar isso agora?

Como o fluxo de trabalho real se parece

Uma busca geralmente segue este loop:

1. Forme uma hipótese específica e testável (não "verificar intrusões" mas "verificar novas scheduled tasks criadas fora das janelas de patch nos últimos 30 dias").
2. Identifique as fontes de dados necessárias — Sysmon Event ID 1 para criação de processo, Windows Security Event ID 4698 para criação de scheduled task, árvores de processo EDR, ou logs conn do Zeek para contexto de rede.
3. Consulte e explore. Na prática isso significa escrever KQL em Microsoft Sentinel, SPL em Splunk, ou consultas brutas contra um índice Elastic.
4. Faça triagem dos resultados — a maioria serão falsos positivos ou atividades benignas de administrador, e o trabalho é reduzir esse ruído para o que é genuinamente anômalo.
5. Documente achados, seja uma comprometimento confirmado, uma lacuna de detecção, ou apenas um