TH.10 - Busca Baseada em IOC e IOA

Controle TH.10 do grupo HNT (Threat Hunting) da seção "15 - Framework CTH - Controles".
Deriva do Capítulo 12 do PDF de referência, seção 12.5. Formaliza a busca por indicadores de
comprometimento (IOC) e indicadores de ataque (IOA), a ponte entre a inteligência de ameaças
produzida no ciclo de CTI e a execução operacional das caças do grupo HNT.

1. Contexto e Posicionamento no Framework CTH

O hunting baseado em inteligência parte de indicadores conhecidos e os expande até descobrir atividade previamente desconhecida. Essa abordagem é menos sofisticada que a caça por hipótese comportamental, mas é essencial e rápida, e cumpre uma função que nenhuma outra técnica substitui: traduzir o que a CTI reporta sobre o adversário em consultas concretas sobre a telemetria própria. Sem uma abordagem estruturada para busca de IOC e IOA, a inteligência coletada, comprada, compartilhada e produzida não gera valor operacional.

No Framework CTH, o TH.10 fecha o laço entre os grupos de CTI e de Hunting. O PLT.x fornece os indicadores pela plataforma de compartilhamento e pela plataforma de gerenciamento de CTI, o DAT.x garante a telemetria consultável, e o TH.10.1 estabelece a cadência mínima de consulta semanal do SIEM contra hashes, IPs, domínios e URLs das fontes de inteligência. Cada acionamento não é um fim: é o ponto de partida do pivoting amplo descrito pelo TH.10.2.

Dentro da sequência do grupo HNT, a técnica opera em dois regimes complementares. No regime reativo, uma campanha ativa ou um alerta setorial dispara a busca imediata, com janela curta e prioridade alta. No regime recorrente, consultas agendadas varrem continuamente o histórico contra indicadores de alta confiança, cobrindo o período anterior ao recebimento da inteligência e reduzindo o dwell time de intrusões que já estavam no ambiente.

2. Papel da Busca por Indicadores no Hunting

A busca por indicadores é a técnica mais rápida do arsenal de hunting, e isso é uma virtude operacional, não uma limitação a esconder. Uma consulta de hash ou de domínio contra trinta dias de telemetria executa em minutos e responde uma pergunta binária com valor imediato: o artefato já passou por aqui ou não. Em contexto de campanha ativa, essa velocidade é o que separa contenção oportuna de resposta tardia.

O papel estratégico é de ponte. A CTI produz entendimento do adversário, com atores, campanhas, TTPs e indicadores; o hunting produz descoberta no ambiente próprio. O TH.10 é o conversor entre os dois mundos: pega o relatório, extrai os indicadores acionáveis, valida, busca, pivotia e devolve ao ciclo de CTI o resultado da verificação, incluindo o feedback de quais fontes acionam e quais apenas ocupam espaço. Esse retorno qualifica as fontes e fecha o ciclo de retroalimentação do CTI.

É preciso reconhecer, com franqueza, o teto da técnica. Indicadores atômicos ficam na base da Pirâmide de Dor, são baratos para o adversário trocar e envelhecem rápido. A busca por IOC não substitui a caça por hipótese do TH.6; ela complementa, e serve de trampolim: o acionamento de um indicador frequentemente abre a porta para a caça comportamental sobre o mesmo ator, elevando o nível da análise da base da pirâmide em direção aos TTPs.

3. IOC e IOA: Definições e Diferenças

IOC (Indicator of Compromise) é o artefato estático que comprova que um comprometimento aconteceu: o hash do binário, o IP do C2, o domínio do phishing, a URL da landing page. IOA (Indicator of Attack) é o padrão comportamental que indica um ataque em andamento, independentemente do artefato específico: o ritmo de beaconing, o uso de PowerShell codificado, a cadeia de execução característica de uma família de malware. A diferença essencial é temporal e lógica: o IOC olha para o passado e confirma; o IOA olha para o comportamento e sinaliza, funcionando mesmo quando o malware é novo.

A coluna de cobertura temporal merece atenção operacional. IOC de rede vale dias; IOC de hash vale meses; IOA vale indefinidamente, porque comportamento não expira na mesma velocidade que infraestrutura. A política de busca deve refletir essas janelas: IP recebido há 90 dias raramente justifica varredura, enquanto hash da mesma campanha ainda pode revelar acionamento em arquivo morto. A idade do indicador é, portanto, um critério de priorização tão importante quanto a confiança.

4. Quando a Busca por IOC É a Técnica Certa

A regra de decisão combina frescor, confiança e relevância setorial. Indicador fresco, confiado e pertinente ao setor justifica busca imediata, inclusive fora da cadência semanal. Indicador velho, genérico ou de fonte não avaliada vira candidato a agendamento recorrente de baixa prioridade, ou nem isso. O TH.10.4 formaliza essa triagem ao priorizar a automação para IOC de alta confiança e relevância para o negócio. Na dúvida entre buscar e descartar, o enriquecimento do ciclo de vida decide: um indicador que sobrevive à checagem de idade, fonte e contexto entra na fila, e o que falha em qualquer critério é registrado como descartado, com o motivo, para que a mesma fonte não seja reavaliada em vão.

5. Ciclo de Vida da Busca por IOC

• Receber e registrar: o indicador entra pelo TIP, com fonte, confiança, TLP, data e campanha associada. IOC recebido por mensagem direta, sem registro formal, é risco de perda de contexto e de rastreabilidade.
• Validar qualidade e idade: avaliar a reputação da fonte, o nível de confiança, a data de última observação e a sobreposição com os PIRs da organização. A validação é o que impede que feeds baratos dirijam o programa de hunting.
• Enriquecer: correlacionar com WHOIS, DNS passivo, reputação de arquivo e sandbox, e com a campanha de origem. O enriquecimento transforma um valor solto em contexto decidível, e revela indicadores relacionados que ampliam a busca.
• Buscar em histórico e em tempo real: a busca histórica cobre o período anterior ao recebimento, que é onde mora o dwell time; a busca em tempo real, agendada enquanto o IOC permanece fresco, encerra a janela de exposição. As duas são complementares, e não alternativas.
• Documentar o acionamento: para cada match, executar o pivoting do TH.10.2, identificando hosts que comunicaram, usuários logados, processos executados e IOCs relacionados presentes, e registrar o veredito no relatório do hunt.

O ciclo é curto por desenho, e a disciplina está nas etapas que os amadores pulam: validação e enriquecimento. Buscar sem validar inunda o time de falso positivo; acionar sem pivotar transforma a descoberta em aviso morto, pois o match isolado raramente conta a história completa. A documentação fecha o ciclo e alimenta as métricas de qualidade de fonte que o PLT.x consome.

6. Exemplo Prático de Consulta

O padrão operacional recomendado mantém os IOC do TIP em watchlists do SIEM, com expiração automática, e as buscas leem essas listas, e nunca valores literais espalhados em consultas. O exemplo a seguir cruza eventos de rede contra as watchlists de domínio e IP dos últimos 30 dias.

// Busca de IOC de domínio e IP a partir de watchlists alimentadas pelo TIP
let dominios = _GetWatchlist("ioc_dominios") | project Dominio = tostring(IOC);
let ips = _GetWatchlist("ioc_ips") | project Endereco = tostring(IOC);
DeviceNetworkEvents
| where Timestamp > ago(30d)
| where RemoteUrl in~ (dominios) or RemoteIP in (ips)
| project Timestamp, DeviceName, RemoteUrl, RemoteIP,
          InitiatingProcessAccountName, InitiatingProcessFileName

Em SPL, o lookup cumpre o mesmo papel, com a vantagem de trazer para o resultado os metadados de confiança, campanha e idade que a validação anexou ao indicador.

index=proxy OR index=dns earliest=-30d
| lookup ioc_lookup campo AS dest_host OUTPUT confianca, campanha, idade_dias
| where confianca >= 70
| stats count dc(src_ip) as hosts max(_time) as ultimo_acesso
        by dest_host, campanha, idade_dias
| sort - hosts

A leitura prioriza hosts por volume e por número de fontes: um host acessando o domínio de C2 centenas de vezes por dia é candidato imediato a contenção, enquanto um acesso único de um host que serve atualizações merece validação de destino antes do alarme. Cada linha do resultado abre o pivoting do TH.10.2, e é desse pivoting que nasce a investigação de verdade.

A mesma lógica de consulta serve aos IOA, com a diferença de que o padrão é comportamental, e não um valor literal. O exemplo a seguir aproxima a detecção de beaconing ao contar conexões HTTPS recorrentes de cada host para cada destino externo, sinalizando pares com ritmo elevado e persistência ao longo da janela.

// IOA de beaconing: pares host e destino externo com ritmo elevado e persistente
DeviceNetworkEvents
| where Timestamp > ago(7d) and RemotePort == 443 and RemoteIPType == "Public"
| summarize Conexoes = count(), BytesEnviados = sum(SentBytes),
            HorasAtivas = dcount(bin(Timestamp, 1h))
    by DeviceName, RemoteIP
| where Conexoes >= 200 and HorasAtivas >= 40
| order by Conexoes desc

O resultado é uma lista de candidatos, e não de incidentes: cada par host e destino suspeito passa pelo pivoting, pela checagem de categorização do destino e pela análise de regularidade de intervalo, que é o traço que separa beaconing de backup e de sincronização legítima. Essa consulta é a materialização do TH.10.3, a busca por padrões comportamentais de atores conhecidos.

7. Automação da Busca e Integração SIEM e TIP

A automação começa na sincronização do TIP com o SIEM: indicadores de alta confiança entram em watchlists com data de expiração, e o SIEM executa consultas agendadas contra elas, alertando sobre acionamentos sem intervenção manual. A deduplicação e o enriquecimento no momento da ingestão, como descreve o PLT.x, evitam multiplicar o mesmo indicador em dezenas de feeds e transformam cada registro em contexto decidível.

O segundo nível de automação é o feedback. Todo acionamento retorna ao TIP com o veredito, verdadeiro ou falso positivo, e esse retorno qualifica fontes e indicadores ao longo do tempo. Fontes que acionam mal perdem peso; campanhas que acionam bem ganham prioridade no consumo. O TH.10.5 descreve o estágio avançado: consultas generativas que, a partir do IOC semente, expandem automaticamente para subdomínios do mesmo domínio, IPs da mesma rede e hashes da mesma família, multiplicando a superfície de descoberta a partir de um único indicador.

8. Limitações e Pirâmide de Dor

A limitação estrutural da busca por IOC está na Pirâmide de Dor: hashes e IPs estão na base, custam quase nada para o adversário trocar, e por isso a defesa sustentada só neles é corrida perdida. Infraestrutura rotaciona em dias, binários são recompilados por praticidade, e o adversário que percebe bloqueio e busca muda a pegada com esforço mínimo. A resposta defensiva madura é subir a pirâmide: converter IOC em IOA, e IOA em TTP, que exigem do adversário reescrever ferramentas e retreinar operadores.

As limitações operacionais são igualmente reais. A cobertura temporal da telemetria delimita o que a busca pode revelar, pois IOC de rede buscado depois que os logs rotacionaram é busca sem objeto. O match de IOC, além disso, não é veredito: um IP de scanning no log de firewall é ruído, e só o pivoting com contexto separa acionamento de comprometimento. Tratar todo match como incidente desgasta o time; tratar match como pista a pivotar é o uso correto da técnica.

A busca em arquivo frio merece caso a caso. Campanhas de alto valor, com atribuição relevante para os PIRs, justificam varreduras sobre a retenção de longo prazo mesmo com IOC de rede velho, pois o objetivo passa a ser forense: saber se a organização foi vítima naquele período. IOC comum de feed genérico não recebe esse tratamento, sob pena de gastar horas de consulta sem valor investigativo.

9. Conversão em Detecções Permanentes e Relação com TH.6

Acionamentos recorrentes pedem institucionalização. Um IOC que aciona de verdade, um padrão de beaconing que se confirma, um hash de loader que reaparece, cada um desses achados se converte em detecção permanente pelo DET.x, em regra Sigma ou em consulta agendada, com o IOC original incorporado à lógica e envelhecido com política de expiração. A busca manual termina quando a detecção assume, e o hunter volta ao desconhecido.

A relação com o TH.6 é de mão dupla e merece prática deliberada. O acionamento confirmado gera hipótese estruturada sobre o comportamento mais amplo do mesmo ator: um hash de loader casado em uma estação vira a hipótese SE-ENTÃO sobre a cadeia de entrega inteira, com técnica ATT&CK, fonte e critério de validação. No sentido inverso, hipóteses confirmadas produzem IOC e IOA novos para o acervo do TH.10. Esse trânsito constante entre indicador e hipótese é o que eleva o programa da base da pirâmide em direção ao topo.

A documentação da conversão registra a origem do padrão, o acionamento que o motivou e a regra resultante, com data e responsável. Essa rastreabilidade permite auditar, meses depois, por que uma detecção existe e qual inteligência a originou. Ela também evita a duplicação de regras sobre o mesmo padrão, que infla o volume de alertas sem ganhar cobertura.

10. Salvaguardas por Nível de Maturidade

11. Erros Comuns e Integração com Outros Controles

• Buscar IOC sem validar idade, confiança e fonte, tratando qualquer match de feed genérico como evidência de comprometimento.
• Encerrar o trabalho no match, sem o pivoting do TH.10.2, transformando descoberta potencial em aviso morto.
• Manter IOCs eternamente ativos no SIEM, sem política de expiração, varrendo valores mortos e gerando falsos positivos tardios.
• Confundir match com incidente, escalando ao IR.x sem o contexto mínimo que separa ruído de intrusão.
• Repetir manualmente buscas de indicadores recorrentes, em vez de converter acionamentos validados em detecções permanentes pelo DET.x.
• Consumir feeds inteiros sem triagem por PIR, deixando o volume bruto de indicadores definir a agenda do time em vez da relevância ao negócio.

A integração com o Framework CTH é a mais intergrupal do grupo HNT. O PLT.x fornece indicadores com contexto pelo MISP e pelo OpenCTI; o DAT.x garante que a telemetria consultável cobre as janelas relevantes; o TH.6 recebe as hipóteses nascidas de acionamentos; o DET.x e o AUT.x recebem as detecções e as buscas agendadas; o IR.x recebe os acionamentos confirmados; o MET.x mede taxa de acionamento, taxa de verdadeiro positivo e tempo entre recebimento e busca; o GOV assegura alinhamento com os PIRs. O SIM.4 complementa o quadro ao testar, com IOC e IOA controlados, se as detecções derivadas desta técnica disparam como deveriam. Operada com validação de idade, pivoting sistemático e conversão em detecção, a busca por IOC e IOA deixa de ser a técnica mais humilde do hunting e passa a ser o sensor de entrada mais valioso do programa.