Home Comunidade Eventos YouTube Networks Desafios // produtos Academy News CTI | CVE Contato

03 - Threat Hunting baseada em IoCs

video explicativo
Video explicativoEspaco reservado para o video desta anotação — adicione video: https://youtu.be/... no frontmatter da nota.

Threat Hunting baseada em IoCs

Nota 03 do capítulo 10 - Integração entre CTI e Threat Hunting. Examina a caça orientada a IOC, o modo mais rápido e mais perecível de consumir inteligência, com critérios explícitos de quando ela vale o ciclo.
Cobre o método de consulta retroativa no histórico, o pivô por IOC, os limites impostos pela expiração de indicadores e a automação da busca retroativa de feeds.
Dialoga com o controle TH.10 da seção 15, com as notas de IOC e de Pirâmide de Indicadores do capítulo 03 e com as notas 01 e 02 deste capítulo.

1. Contexto e Posicionamento na Biblioteca

A caça orientada a IOC é a ponte mais curta entre a inteligência recebida e a telemetria própria: um domínio, um hash ou um IP chegam com contexto, e a pergunta imediata é se esses artefatos já passaram por aqui. É também a técnica mais rápida do arsenal, uma consulta de minutos contra meses de histórico, e por isso é a primeira que o time executa quando um relatório de campanha ativa chega. A nota 01 deste capítulo mostrou como o relatório gera hipóteses de comportamento; esta nota cobre o outro ramo da conversão, em que o anexo técnico do relatório alimenta busca de presença com pivô.

A posição honesta da técnica exige defini-la pelo que não é. Buscar IOC não é caça por hipótese: a consulta responde uma pergunta binária sobre artefatos conhecidos, e não explora comportamento desconhecido; seu valor depende inteiramente da qualidade e do frescor da inteligência de origem, e seu resultado envelhece na velocidade em que o adversário rotaciona infraestrutura. O controle TH.10 da seção 15 formaliza o método, e a Pirâmide de Dor apresentada no capítulo 03 explica a limitação estrutural: indicadores atômicos estão na base da pirâmide, baratos de trocar. Usada com critério, a busca por IOC é complemento de alta velocidade da caça comportamental; usada sem critério, vira processamento infindável de feeds baratos com falso positivo caro.

No mapa do capítulo, a busca por IOC é o membro de menor custo e menor teto da família de caças dirigidas por inteligência, e essa posição define o papel dela no portfólio. A nota 04 vai mostrar a caça por TTP, de custo maior e teto maior; a hipótese comportamental da nota 02 do capítulo 06 ocupa o topo da família. O desenho correto não escolhe uma, e sim sequencia: IOC de alta qualidade executa em minutos e pode abrir a porta; o comportamento que cerca o acionamento sustenta a caça de dias. Operações iniciantes começam a porta errada, executando somente busca de IOC e chamando isso de hunting, e a diferença entre buscar presença e caçar é exatamente o que esta nota delimita.

2. Quando a Caça por IOC Faz Sentido

A decisão de gastar ciclo em busca por IOC combina quatro critérios, e a técnica se justifica quando a maioria deles é favorável. O primeiro é o frescor da campanha: IOC nascido há horas, de campanha ativa, tem janela real de acerto no ambiente; IOC reciclado de feed genérico há meses, quase nunca. O segundo é a qualidade do indicador: confiança declarada, fonte avaliada no padrão do capítulo 02, contexto de campanha e validade definidos são os atributos que separam IOC acionável de ruído com formato de IOC. O terceiro é a relevância setorial, que conecta a busca aos PIRs: campanha contra o próprio setor justifica busca imediata mesmo com confiança moderada, porque o custo-benefício muda com a probabilidade de exposição. O quarto é a janela de ação: campanha ativa com exfiltração em curso pede velocidade, e é exatamente a velocidade o que a busca por IOC entrega.

Situação Buscar por IOC? Justificativa
Campanha ativa contra o setor, IOC fresco de ISAC Sim, imediato Alta probabilidade de exposição e janela curta de ação
Hash de loader novo em relatório de fornecedor confiável Sim, retroativo Hash sobrevive meses e a caça retroativa cobre o dwell time
IP de C2 há 60 dias em feed público Prioridade baixa Provável rotação; busca só se a fonte for excepcional
IOC genérico sem contexto, sem fonte avaliada Não Falso positivo caro e nenhuma capacidade de julgamento
URL de phishing ativa mirando a marca Sim, imediato Artefato específico, fresco e diretamente acionável

A tabela traduz a regra de decisão do TH.10: frescor, confiança e relevância setorial, na ordem, definem o imediatismo da busca. Um detalhe operacional costuma ser esquecido e vale registrar: o IOC que falha na triagem não é descartado em silêncio, e sim registrado como descartado com o motivo, porque esse registro alimenta a avaliação de fontes e impede que a mesma fonte reciclique o mesmo ruído ciclo após ciclo. A busca barata não é desculpa para a triagem descuidada, porque o recurso escasso não é o processamento da consulta, é a capacidade de investigação do time quando os acionamentos aparecem.

Para equipes que preferem critério numérico, a triagem vira pontuação simples: cada um dos quatro critérios recebe nota de 0 a 2, e o limiar de execução imediata fica em 6 de 8, com faixa de 3 a 5 indo para a fila recorrente e abaixo de 3 para o registro de descarte. A pontuação não é ciência, é disciplina, e o valor dela está em forçar o analista a dizer por que busca: IOC fresco de campanha ativa setorial com confiança alta pontua no máximo e executa na hora; hash sem contexto de feed genérico pontua no mínimo e é arquivado com o motivo. A mesma régua serve de vocabulário comum entre CTI e hunting quando a fonte pergunta por que o material não foi consumido, e a resposta deixa de ser impressão para virar critério documentado.

3. Método: Consulta Retroativa no Histórico e Pivô por IOC

O método opera em dois regimes complementares. No regime retroativo, a busca cobre o histórico disponível, do presente até o limite de retenção da fonte de dados, e responde à pergunta de dwell time: o adversário já estava aqui antes de o IOC chegar? No regime recorrente, consultas agendadas reexecutam a busca enquanto o indicador permanece fresco, cobrindo os dias seguintes ao recebimento e encerrando a janela de exposição corrente. Os dois regimes são obrigatórios em conjunto, porque o acionamento histórico sem o recorrente deixa a porta aberta, e o recorrente sem o retroativo presume que a intrusão começou depois da inteligência, o que raramente é verdade.

O acionamento é o começo, não o fim. Um match isolado raramente conta a história, e o valor do acionamento se realiza no pivô, a expansão controlada a partir do indicador inicial para o contexto que o cerca. A cadeia de pivô abaixo ilustra a expansão típica a partir de um domínio, e a disciplina do TH.10.2 vale para qualquer ponto de partida:

Salto De Para Fonte típica
1 Domínio do beacon IPs de resolução no período DNS, proxy
2 IPs de resolução Hosts que resolveram ou conectaram DNS, firewall, NetFlow
3 Hosts Processos e contas ativas nos hosts Sysmon 1, 4624
4 Hosts Arquivos gravados e hashes gerados Sysmon 6, EDR
5 Hashes Outros hosts com o mesmo artefato EDR, SIEM
6 Domínio inicial Domínios do mesmo nameserver ou certificado DNS passivo, CT logs

Três regras governam o pivô na prática. Primeira, registrar cada salto com a consulta usada, porque a cadeia não documentada não é reprodutível nem auditável, e o relato final precisa da árvore completa. Segunda, limitar a profundidade conscientemente: três a cinco saltos costumam saturar o contexto útil, e além disso o esforço cresce mais rápido que o retorno, com reavaliação a cada nível. Terceira, alternar expansão e filtro: expandir demais sem filtrar produz centenas de hosts correlatos por coincidência de infraestrutura compartilhada, e o pivô só tem valor quando cada salto carrega critério de pertinência explícito, como janela de tempo e contexto de processo.

O ponto de partida muda a forma da cadeia, e o hunter escolhe o eixo que rende mais contexto por salto. IOC de rede, domínio ou IP, pede o caminho da resolução para o host e depois para o processo, como na tabela; hash de arquivo pede o caminho inverso, do arquivo para os hosts que o gravaram, para as contas que executaram e para a rede que os binários tocaram; IOC de memória ou mutex é tipicamente ponto de chegada, e não de partida, porque só existe em contexto de resposta. Há ainda o pivô lateral por infraestrutura compartilhada, nameserver, certificado, whois e mudança de hosting, que expande a busca para IOC irmãos que a fonte não listou, e é o salto de maior valor analítico porque descobre infraestrutura nova a partir de artefato conhecido.

4. Limitações: Expiração e Custo para o Adversário

A limitação estrutural da técnica é a expiração, e ela varia por tipo de indicador porque a vida útil acompanha o custo de troca para o adversário. A tabela abaixo resume as expectativas de validade operacional usadas nesta biblioteca, que o TIP materializa como data de expiração de cada IOC:

Tipo de IOC Vida útil típica Motivo
Endereço IP Dias a semanas Infraestrutura é alugada e rotacionada por hábito
URL e path de landing page Dias Página de phishing muda com o ciclo da campanha
Domínio Semanas a meses Registro é custo real e reuso é comum
Hash de arquivo Meses a mais de um ano Binário sobrevive enquanto não é recompilado
Mutex, chave de registro, nome de serviço Tempo da infecção Útil sobretudo na resposta e na erradicação

A consequência operacional direta é aritmética: IOC de rede com 90 dias de idade contra retenção de 60 dias de log de proxy é busca vazia por definição, e executá-la só produz a ilusão de cobertura. A política da organização deve cruzar a idade do indicador com a retenção real de cada fonte, no padrão do capítulo 02, e registrar quando a busca retroativa é impossível, porque essa impossibilidade é uma lacuna de cobertura que o capítulo 11 mede. O outro limite vem da Pirâmide de Dor: IOC barato de trocar entrega acionamento apenas enquanto o adversário não percebe a detecção, e por isso o produto maduro da busca por IOC é o trampolim, o match que abre a caça comportamental sobre o mesmo operador e sobe a pirâmide em direção às ferramentas e ao comportamento.

O resultado negativo também tem valor, com uma condição. Busca retroativa que fecha vazia com triagem registrada, janela coberta e telemetria confirmada é evidência de ausência naquele período, e alimenta a camada de cobertura validada que o capítulo 11 consolida por trimestre. A condição é a qualidade do fechamento: busca vazia por causa de retenção insuficiente, de fonte de log ausente ou de IOC não normalizado não é evidência de ausência, é busca cega, e registrá-la como cobertura é o tipo de contabilidade que corrompe a métrica. O estado de encerramento da busca, acionamento, limpo validado ou lacuna, deve sair da ficha da mesma forma que sai na caça por hipótese.

5. Automação da Busca Retroativa de Feeds

A automação existe para que a busca retroativa não dependa de alguém lembrar de colar IOC no console. O pipeline de referência sincroniza as fontes pelo TAXII 2.1 ou via API do TIP, normaliza e deduplica os indicadores na esteira do capítulo 02, aplica a pontuação de prioridade da seção 2 e materializa os IOC ativos numa tabela consultável do SIEM, com expiração automática pela validade declarada. A consulta agendada consome essa tabela, e não listas coladas no corpo da regra, o que torna a atualização de feeds transparente para as consultas:

Estágio do pipeline O que faz Cadência
Sincronização Puxa IOC das fontes via TAXII 2.1 ou API do TIP Contínua ou horária
Normalização Padroniza tipo, valor canônico, TLP, confiança e validade Por lote recebido
Deduplicação e pontuação Une repetidos, calcula prioridade e fonte primária Por lote recebido
Materialização Publica os IOC ativos na tabela consumível pelo SIEM Diária
Execução e registro Roda as consultas agendadas e grava resultado, inclusive vazio Diária para rede, semanal para hash
// Busca recorrente de IOC de rede ativos na telemetria de DNS e proxy
let iocs_ativos = materialize(_GetWatchlist("iocs_ativos")
    | where tipo in ("domain", "url") and todatetime(expira_em) > now()
    | where confianca >= 70 and todatetime(ultima_vez) > ago(30d)
    | project valor);
DnsEvents
| where TimeGenerated > ago(1d)
| where Name in~ (iocs_ativos)
| summarize Consultas = count(), Primeira = min(TimeGenerated), Ultima = max(TimeGenerated)
    by Dominio = Name
| extend Acionamento = "DNS"
| union (CommonSecurityLog
    | where TimeGenerated > ago(1d)
    | where RequestURL in~ (iocs_ativos)
    | summarize Consultas = count(), Primeira = min(TimeGenerated), Ultima = max(TimeGenerated)
        by Dominio = tostring(split(RequestURL, "/")[0])
    | extend Acionamento = "Proxy")
| order by Consultas desc

Três controles de qualidade acompanham qualquer automação dessa natureza. A deduplicação antes da materialização evita que dez fontes que repassam o mesmo domínio multipliquem o acionamento por dez e distorçam a contagem; a preservação da fonte de origem em cada IOC permite calcular a taxa de falso positivo por fonte, métrica central do capítulo 11; e a expiração automática impede o acúmulo silencioso de indicadores mortos, que é o modo mais comum de um watchlist degradar até virar ruído institucionalizado. O regime recorrente roda diário para IOC de rede, semanal para hash, e a cada execução o resultado, inclusive o vazio, é registrado, porque busca retroativa sem registro é métrica perdida.

A orquestração completa o desenho quando o disparo é externo. Com o workflow do INT.5, o alerta de campanha que chega pelo canal do ISAC aciona o fluxo que extrai os indicadores do comunicado, aplica a triagem da seção 2, cria a entrada na watchlist e dispara a primeira execução da consulta retroativa, entregando ao hunter o resultado já compilado para investigação. A regra é a mesma da ficha de descoberta da nota 02: automatizar o transporte e o cálculo, nunca o julgamento, e a decisão de investigar um acionamento ou arquivá-lo como ruído permanece humana, com o tempo ganho pela automação aplicado exatamente onde o analista vale mais.

6. Exemplo de Caça por IOC com Pivô

O cenário abaixo aplica o método ponta a ponta. O ISAC do setor dissemina, com TLP:AMBER, o domínio invoice-portal[.]top associado a uma campanha de phishing financeiro ativa na semana. O domínio passa na triagem da seção 2, fresco, de fonte confiável, setor pertinente, e a busca retroativa de 45 dias no DNS acerta uma ocorrência: a estação PC-FIN-114 resolveu o domínio nove dias antes do alerta, o que configura dwell time em potencial:

// Salto 1 e 2: quem resolveu o domínio e quando
DnsEvents
| where TimeGenerated > ago(45d) and Name =~ "invoice-portal.top"
| project TimeGenerated, Computer, ClientIP
// Resultado: PC-FIN-114, 2025-09-09, 4 resoluções em 6 minutos

O pivô segue a cadeia da seção 3. No host, a telemetria de processo da janela mostra o contexto do acionamento, e o salto 4 revela o artefato que a campanha entregou:

// Salto 3 e 4: contexto de processo e artefato no host acionado
DeviceProcessEvents
| where DeviceName =~ "PC-FIN-114"
| where Timestamp between (datetime(2025-09-09 14:00) .. datetime(2025-09-09 15:00))
| where InitiatingProcessFileName in~ ("OUTLOOK.EXE", "WINWORD.EXE", "EXCEL.EXE")
| project Timestamp, FileName, ProcessCommandLine, InitiatingProcessFileName
// Resultado: wscript.exe filha de WINWORD.EXE gravando loader em APPDATA

O hash do loader não constava do alerta do ISAC, e é exatamente esse o papel do pivô: a busca por IOC de entrada devolveu um IOC de saída. O loader entra na ficha de descoberta da nota 02 deste capítulo, com primeira e última vez, e retorna ao time de CTI, que correlaciona o hash com o cluster da campanha e dissemina o enriquecimento para o próprio ISAC. O veredicto da caça registra a cadeia completa de saltos com as consultas preservadas, a detecção Sigma do padrão de execução entra no pipeline do capítulo 18, e a busca recorrente pelos dois IOC, domínio e hash, segue agendada até a expiração declarada.

O exemplo também mostra onde a técnica termina, e reconhecer a fronteira é parte do método. A busca por IOC confirmou que o artefato conhecido passou por aqui e contextualizou o acionamento até o processo pai, mas o restante da história, o que o operador fez depois do loader, que credenciais tocou e que dados alcançou, pertence à caça comportamental sobre o mesmo host, formulada como hipótese e executada com as técnicas do capítulo 08. As duas caças compartilham a ficha, a linha do tempo e o caso, e é essa continuidade, e não a técnica isolada, que define a integração que o capítulo ensina.

7. Erros Comuns e Pontos de Atenção

  • Buscar sem triar: consulta de IOC genérico sem fonte avaliada produz falso positivo caro e desgasta a credibilidade da técnica; o antídoto é a triagem da seção 2 com registro dos descartes e dos motivos.
  • Buscar IOC mais velho que a retenção: execução que nunca poderia acertar produz ilusão de cobertura; o antídoto é cruzar idade do indicador com retenção real por fonte e registrar a impossibilidade como lacuna.
  • Acionar sem pivotar: match isolado sem expansão vira aviso morto, com o host indisponível para investigação; o antídoto é a cadeia de pivô obrigatória com saltos documentados.
  • Grep eterno: reexecutar a mesma busca de presença ciclo após ciclo sem subir para o comportamento mantém o time na base da Pirâmide de Dor; o antídoto é tratar todo match como trampolim para hipótese.
  • Bloquear e encerrar: bloqueio do IOC seguido de arquivamento do caso destrói a oportunidade de caça; bloqueio e caça convivem, com o bloqueio protegendo e a caça medindo o dano.
  • Alimentar a automação com feeds baratos: watchlist inflada de indicadores de baixa confiança enterra os acionamentos reais; o antídoto é a pontuação de entrada e a taxa de falso positivo por fonte do capítulo 11.
  • Esquecer o retorno: acionamento confirmado que não vira ficha de descoberta perde o IOC de saída e o enriquecimento; o antídoto é encerrar toda caça por IOC com a devolução da nota 02.

8. Integração com o Restante da Biblioteca

Esta nota consome o anexo técnico dos relatórios do capítulo 05, os IOC caracterizados no capítulo 03 e a esteira de normalização do capítulo 02, e entrega acionamentos para o processo do capítulo 07 e trampolins para a caça por TTP da nota 04. O controle TH.10 da seção 15 institucionaliza o método com cadência mínima semanal e pivô obrigatório, o DAT.1 garante a retenção que viabiliza a busca retroativa e o PLT.2 fornece a plataforma que hospeda os indicadores. No capítulo 11, a taxa de acionamento e o falso positivo por fonte medem a eficiência desta técnica, e a lacuna de retenção identificada em seção 4 entra como pedido de coleta.

O exercício de fixação usa o ambiente de estudo: escolher três IOC públicos de campanha setorial recente, triar pelos quatro critérios da seção 2, executar a busca retroativa no laboratório com a janela de retenção real e documentar a cadeia de pivô até o limite dos dados disponíveis. O exercício só está completo quando a saída entra na ficha de descoberta no formato da nota 02, porque caça por IOC sem devolução é metade do ciclo que o capítulo define.