Threat Hunting: Como Conduzir uma Caçada Real (2026)

O que é threat hunting?

Threat hunting é a prática de buscar proativamente, nos dados de segurança, atividade de invasor que a detecção automatizada não capturou. Em vez de esperar um alerta, o caçador formula uma hipótese sobre como uma intrusão específica apareceria na telemetria disponível, consulta esse padrão e então o confirma, o descarta ou descobre que os dados necessários para responder nunca foram coletados.

Esse terceiro desfecho é o que ninguém divulga, e é o resultado mais comum em um programa de caça jovem. Você levanta a hipótese de que um invasor criou uma tarefa agendada para persistência, sai atrás dos eventos de criação de tarefas e descobre que a política de auditoria que os gera nunca foi habilitada fora dos controladores de domínio. Você não pegou nenhum intruso. Descobriu, porém, que 4.000 estações estão cegas para uma das técnicas de persistência mais usadas no mundo real, o que vale mais do que mais um alerta fechado.

Três coisas separam a caça do monitoramento. A caça é conduzida por humanos: a consulta nasce do raciocínio de um analista, não de um motor de regras. É guiada por hipótese, ou seja, você decide o que procura antes de procurar. E ela pressupõe comprometimento: a premissa de trabalho é que algo já está dentro e cabe a você provar ou descartar, não esperar confirmação.

Uma caçada tem exatamente três finais honestos. Você encontra atividade maliciosa e a entrega à resposta a incidentes. Você não encontra nada e converte a consulta em uma detecção agendada, para que o mesmo terreno seja coberto automaticamente da próxima vez. Ou você conclui que a pergunta não tem resposta possível, e a entrega passa a ser uma lacuna de coleta de logs com um chamado aberto.

Threat hunting, resposta a incidentes e threat intelligence

Os três termos aparecem como sinônimos em vagas de emprego, mas são atividades genuinamente distintas que apenas compartilham um conjunto de dados.

Os três se alimentam em ciclo. A inteligência indica quais técnicas um ator relevante prefere, e isso vira sua hipótese de caça. A caçada ocasionalmente acha algo real, que vira um incidente. O incidente produz artefatos que retornam à inteligência. Se sua organização não tem uma área de inteligência, a base de conhecimento gratuita MITRE ATT&CK substitui bem o suficiente para começar, e mapear as fases de uma intrusão na cyber kill chain ajuda a decidir em qual estágio sua cobertura é mais fraca.

As cinco etapas de uma caçada

Quais são as etapas de uma caçada a ameaças? Escolher uma hipótese, definir qual telemetria a provaria ou descartaria, consultar e reduzir os resultados a um conjunto revisável, triar o que sobrou e transformar o resultado em algo permanente, como uma regra de detecção ou um ajuste de coleta de logs.

1. Escolha uma hipótese estreita o bastante para poder falhar. "Existe malware na rede" não é hipótese, é ansiedade. "Um invasor estabeleceu persistência no nosso parque Windows usando tarefas agendadas que executam a partir de um diretório gravável pelo usuário" é testável, e você já sabe de antemão como é a resposta.
2. Defina quais dados responderiam à pergunta, antes de consultar qualquer coisa. Escreva as fontes de eventos e os campos necessários. É aqui que a maioria das caçadas morre em silêncio, e descobrir isso no papel em cinco minutos é melhor do que descobrir depois de duas horas ajustando consultas.
3. Consulte e depois reduza. A primeira consulta sempre devolve demais. A redução é a habilidade de verdade: filtre o bom conhecido por certificado de assinatura e processo pai em vez de por nome de arquivo, agregue em vez de listar e chegue a um conjunto pequeno o suficiente para um humano olhar linha por linha.
4. Faça a triagem dos sobreviventes. Pivote em cada item restante: qual processo o criou, o que esse processo fez em seguida, qual conta, qual host, a mesma coisa aparece em outro lugar. A maior parte das linhas vai se resolver em um script administrativo incomum, porém legítimo, e cada descarte deve ser registrado para que a próxima caçada não reexamine o mesmo item.
5. Torne o resultado permanente. Converta a consulta em detecção agendada, registre o ponto cego e documente como o "normal" acabou se revelando. Uma caçada que você não consegue repetir é um hobby.

A etapa cinco é onde programas de caça prosperam ou estagnam. Uma equipe que caça toda semana e não automatiza nada roda as mesmas cinco consultas para sempre e aos poucos para de achar qualquer coisa, porque o terreno coberto nunca se amplia.

Técnicas de threat hunting que realmente encontram algo

Quatro técnicas cobrem quase tudo o que um caçador em atividade faz. Elas não têm o mesmo valor, e aquela por onde a maioria dos iniciantes começa é a mais fraca.

Contagem por pilha, o cavalo de batalha

Também chamada de análise de frequência ou análise de cauda longa. Você pega um campo, conta com que frequência cada valor distinto aparece no ambiente e ordena de forma crescente. Atividade maliciosa é rara por definição, então ela se acumula no fim dessa lista. Aplique a linhas de comando de processos, ações de tarefas agendadas, caminhos de binários de serviço, pares de processo pai e filho ou strings de user agent.

Funciona tão bem porque não exige conhecimento prévio da ameaça. Você não pergunta "isso é malicioso", pergunta "isso é incomum aqui", e essa é uma pergunta que seus próprios dados conseguem responder. Na prática, é daí que vem aproximadamente metade dos achados reais de caçada.

Linha de base e detecção de desvios

Construa um retrato do normal para um comportamento específico e depois procure o desvio. Quais contas normalmente se autenticam no servidor de arquivos do financeiro, e qual fez isso pela primeira vez na terça passada às 3 da manhã. Quanto tráfego DNS uma estação típica gera por hora, e qual host está produzindo oito vezes isso com rótulos de subdomínio anormalmente longos. Esse segundo exemplo é exfiltração por DNS de manual, e o lab DNS Tunneling Detective entrega uma captura para você praticar.

Busca por indicadores conhecidos

Você pega hashes, endereços IP e domínios de um relatório de inteligência e varre seus dados históricos atrás deles. É a técnica mais fácil e a menos valiosa, por causa do que David Bianco chamou de Pyramid of Pain: hashes e endereços IP ficam na base e um invasor os troca sem esforço. Comportamentos e TTPs ficam no topo e custam caro para mudar. Uma varredura de indicadores diz se você foi atingido por aquela campanha exata, naquela infraestrutura exata, o que é uma pergunta mais estreita do que parece à primeira vista.

Faça varreduras de indicadores porque são baratas, mas não construa um programa em cima delas. Se a única coisa que sua equipe de caça faz é colar IOCs em uma barra de busca, você automatizou o consumo de inteligência, não fez threat hunting.

Caça assistida por modelo

Use um modelo estatístico ou de aprendizado de máquina para levantar candidatos que um humano revisa depois: agrupar linhas de comando semelhantes, pontuar nomes de domínio por aleatoriedade, sinalizar combinações raras de processo pai e filho. A pesquisa SANS 2025 foi direta ao afirmar que o efeito das técnicas baseadas em IA sobre a descoberta efetiva de atores maliciosos segue limitado até aqui. Trate esses modelos como uma forma de ordenar o palheiro, não como uma detecção.

Uma caçada real, do início ao fim

Aqui está uma caçada escrita por completo, para dar às abstrações acima algo concreto em que se apoiar.

A hipótese

Um adversário com execução de código em uma estação criou uma tarefa agendada para persistência, executando um payload a partir de um caminho gravável pelo usuário. Em termos de ATT&CK, isso é T1053.005, Scheduled Task, associada às táticas Execution, Persistence e Privilege Escalation. É uma boa hipótese inicial porque é extremamente comum e porque tarefas agendadas legítimas são estáveis o bastante para que as anomalias se destaquem.

Os dados

Duas fontes respondem a isso. O evento 4698 do Windows Security registra a criação de tarefa agendada, e o evento 1 do Sysmon registra criação de processo, o que captura a invocação de schtasks.exe. Verifique as duas, porque tarefas registradas pela interface COM ou pelo Register-ScheduledTask do PowerShell nunca tocam schtasks.exe e ficariam invisíveis se você olhasse apenas a criação de processos.

Um pré-requisito pega todo mundo: eventos 4688 brutos do Windows não incluem a linha de comando a menos que ProcessCreationIncludeCmdLine_Enabled esteja habilitado via política de grupo. Sem isso, toda caçada por linha de comando no seu ambiente devolve silenciosamente nada de útil. Confirme isso antes da caçada, não durante.

As consultas

Contagem por pilha sobre criação de tarefas, no advanced hunting do Microsoft Defender XDR (KQL):

DeviceProcessEvents
| where Timestamp > ago(30d)
| where FileName =~ "schtasks.exe"
| where ProcessCommandLine has "/create"
| summarize Hosts = dcount(DeviceName), Runs = count()
    by ProcessCommandLine
| order by Runs asc

A mesma ideia no Splunk, sobre dados do Sysmon:

index=sysmon EventCode=1 Image="*\\schtasks.exe"
| search CommandLine="*/create*"
| stats count AS runs, dc(ComputerName) AS hosts,
    values(ParentImage) AS parents BY CommandLine
| sort runs asc

Leia a partir do topo da saída, onde ficam as linhas de comando mais raras. Uma linha de comando que aparece uma vez, em um único host, não prova nada, mas é ali que você investe sua atenção.

A triagem

Quatro perguntas decidem se uma linha merece escalonamento. Qual é o processo pai: uma tarefa criada por cmd.exe cujo avô é winword.exe conta uma história bem diferente de uma criada pelo seu agente de gerenciamento de configuração. Onde mora o binário da tarefa: C:\Windows\System32 não chama atenção, C:\Users\Public e %APPDATA% chamam. Qual conta a criou, e essa conta costuma administrar aquele host. E quando: uma criação de tarefa às 3h14 em uma máquina cujo usuário bate ponto às 9h merece uma ligação.

Espere falsos positivos, e espere que sejam interessantes. Ferramentas de distribuição de software, agentes de backup e instaladores criam tarefas agendadas de aparência estranha. Cada descarte deve terminar em uma lista de permissões documentada, porque o valor de uma caçada só se acumula se a próxima começar onde esta parou.

A entrega

Suponha que você não tenha achado nada malicioso. Ainda assim, você entrega três coisas: uma detecção agendada que dispara na criação de tarefa cujo caminho de ação fique sob um diretório gravável pelo usuário, uma linha de base escrita com as doze linhas de comando de tarefa que são normais no seu parque e um chamado para as quatro sub-redes de onde nenhum evento 4698 jamais chegou. Rode a mesma caçada no trimestre seguinte e ela leva vinte minutos em vez de um dia.

Frameworks de threat hunting e o modelo de maturidade

Dois trabalhos publicados valem seu tempo. O resto da literatura sobre frameworks é posicionamento de fornecedor.

PEAK

Desenvolvido pela equipe de pesquisa SURGe da Splunk, PEAK significa Prepare, Execute, and Act with Knowledge. Prepare cobre escolha de tema, pesquisa e planejamento. Execute cobre o trabalho sobre os dados. Act cobre documentação, automação e comunicação, e o conhecimento atravessa as três fases: você o usa antes da caçada, gera mais durante e age sobre ele depois.

A contribuição mais útil do PEAK é nomear explicitamente três tipos de caçada. As guiadas por hipótese testam uma afirmação específica. As de linha de base caracterizam o normal em uma área que você nunca examinou. As assistidas por modelo usam algoritmos para gerar candidatos. Equipes que só rodam o primeiro tipo acabam caçando repetidamente o mesmo punhado de técnicas bem documentadas, porque são as únicas sobre as quais conseguem formular uma hipótese.

O Hunting Maturity Model

O Hunting Maturity Model de David Bianco classifica um programa em cinco níveis:

• HMM0, Initial: a organização depende de alertas automatizados. Analistas resolvem alertas. Não há caçada alguma.
• HMM1, Minimal: a telemetria é coletada centralmente e analistas conseguem buscar no histórico por indicadores tirados de relatórios. É o primeiro nível em que a caça existe.
• HMM2, Procedural: a equipe roda rotineiramente procedimentos de caça publicados por outros, com pequenas modificações.
• HMM3, Innovative: a equipe cria os próprios procedimentos em vez de tomá-los emprestados.
• HMM4, Leading: toda caçada bem-sucedida é operacionalizada em detecção automatizada, o que libera os analistas para desenvolver novas técnicas.

Seja honesto sobre onde você está. Muitas equipes que se descrevem como HMM3 rodam consultas emprestadas em uma agenda, o que é HMM2, e o salto de HMM1 para HMM2 vale muito mais do que o rótulo. A distinção que importa no HMM4 é a automação: se caçadas bem-sucedidas não viram detecções, a equipe faz um trabalho manual cujo custo cresce na mesma proporção do quadro de pessoal.

Ferramentas de threat hunting que valem seu tempo

Você não precisa de uma plataforma de threat hunting. Precisa de acesso de consulta a uma telemetria realmente boa, o que é um problema de dados fantasiado de problema de ferramenta. Resolva a coleta primeiro e depois se preocupe com a interface.

• Sysmon para telemetria de endpoint Windows. Gratuito, e produz os eventos de criação de processo, conexão de rede e consulta DNS dos quais dependem quase todas as caçadas deste artigo. Parta de uma configuração mantida, como a configuração modular do Olaf Hartong, em vez de escrever a sua do zero, ou você vai coletar de menos ou de mais.
• Velociraptor para caçar em escala pelos endpoints. Sua linguagem de consulta VQL permite fazer uma pergunta a milhares de máquinas de uma vez e receber respostas em minutos, o que é o mais próximo de um superpoder nesta lista.
• Sigma para escrever a lógica de detecção uma vez e convertê-la para a sintaxe de consulta do seu SIEM. Combine com Hayabusa ou Chainsaw para rodar regras Sigma diretamente sobre arquivos de log de eventos do Windows durante uma investigação.
• Zeek para telemetria de rede. Ele transforma tráfego em logs estruturados de conexão, DNS, HTTP e TLS, muito mais úteis para caça do que uma captura completa de pacotes que você nunca terá tempo de abrir. O Wireshark segue tendo seu lugar no último quilômetro, depois que um log do Zeek apontou qual conexão vale a pena abrir.

Uma opinião que vale dizer sem rodeios: deixe de lado a categoria comercial de "plataforma de threat hunting" até ter caçado manualmente por seis meses. Esses produtos pressupõem que você já sabe quais perguntas fazer, e comprar um antes disso deixa você com um painel caro que ninguém abre.

Como referência de técnicas, o ATT&CK é o mapa que todo mundo compartilha. A versão v19, de 28 de abril de 2026, levou o Enterprise a 15 táticas, 222 técnicas e 475 subtécnicas, e dividiu a antiga tática Defense Evasion em Stealth e Defense Impairment. Se você acompanhava sua cobertura de caça pela lista anterior de táticas, essa divisão merece uma tarde de remapeamento: o abuso de rundll32.exe, por exemplo, agora fica sob Stealth como T1218.011.

Como se tornar um threat hunter

Como se tornar um threat hunter? A maioria dos caçadores vem da análise de SOC, da resposta a incidentes ou da administração de sistemas, e não direto da formação acadêmica. O critério de contratação é a capacidade de raciocinar sobre como um sistema operacional se comporta normalmente, somada a fluência suficiente em consultas para testar esse raciocínio contra dados reais.

Quatro capacidades sustentam a função, mais ou menos na ordem em que costumam ser o fator limitante:

• Funcionamento interno dos sistemas operacionais. Não dá para notar uma relação anormal entre processo pai e filho sem saber como é a normal. A árvore genealógica de processos no Windows, a mecânica de serviços e tarefas agendadas e os equivalentes em Linux importam mais do que qualquer ferramenta.
• Linguagens de consulta. KQL, SPL ou a sintaxe do Elasticsearch, conforme o que seu empregador usa. A parte a dominar é a agregação, não a filtragem.
• Conhecimento de técnicas ofensivas. Familiaridade ofensiva suficiente para prever o que um invasor tentaria em seguida. Caçadores que já elevaram privilégios na mão em uma máquina escrevem hipóteses visivelmente melhores do que quem só leu a respeito.
• Escrita. Caçadas não documentadas não podem ser repetidas, e o relatório de caçada é o artefato que a gestão enxerga. É a habilidade que os candidatos tecnicamente mais fortes mais negligenciam.

A situação de pessoal joga a seu favor. 61% das organizações na pesquisa SANS 2025 apontaram a escassez de profissionais qualificados como a principal barreira aos seus programas de caça, enquanto a fatia das que terceirizam totalmente a atividade caiu de 37% para 30%, com mais equipes internalizando a capacidade. Se você está traçando a rota para um cargo defensivo, nosso guia de carreira de analista SOC cobre a porta de entrada pela qual a maioria dos caçadores passa primeiro.

Considerações legais e éticas

Dois pontos pesam mais aqui do que na segurança ofensiva. Sob a LGPD, o GDPR e regimes de privacidade equivalentes, telemetria de endpoint e de autenticação é dado pessoal, então programas de caça precisam de base legal documentada, prazo de retenção e controles de acesso proporcionais ao quanto esses dados revelam. Envolva sua área jurídica ou de privacidade no desenho da coleta, e não depois que uma caçada trouxer à tona algo constrangedor sobre um funcionário nominalmente identificado.

O segundo ponto é o tratamento de evidências. No momento em que uma caçada revela atividade real de invasor, ela deixa de ser caçada e vira incidente, e sua próxima ação pode destruir provas. Não faça login no host suspeito para dar uma olhada, não apague a tarefa agendada que você encontrou e não alerte um intruso ativo. Entregue à resposta a incidentes sua consulta, seus resultados e seus horários, e deixe o processo desenhado para preservar evidências assumir.