INT.4 - Integração EASM com Threat Hunting

Nota do grupo INT (Integração CTI-TH-EASM) da seção 15 do Framework CTH.
Deriva do Capítulo 17 do PDF de referência, controle INT.4, com os subcontroles INT.4.1 a INT.4.5.
Define como cada exposição identificada na superfície externa abre hipóteses de caça para verificar uso indevido dentro do ambiente.

1. Contexto e Posicionamento no Framework CTH

O hunting tradicional parte do ambiente interno em direção à evidência, e o EASM parte da Internet em direção ao inventário. Os dois movimentos são complementares, e a união deles forma a visibilidade completa que o Framework CTH persegue. Quando o EASM identifica uma exposição relevante, a pergunta imediata deixa de ser apenas quando corrigir e passa a ser se o adversário já chegou lá primeiro, e essa pergunta só tem resposta com caça no ambiente interno.

No Framework CTH, o INT.4 conecta os IOEs (Indicators of Exposure) do INS.4 à fila de priorização do TH.5, transforma cada indicador em hipótese estruturada pelo TH.6 e executa a busca com o TH.10, nas técnicas de busca baseada em IOC e IOA. O achado resultante pode gerar caso no grupo IR, observáveis no INT.2, detecção permanente no AUT.3 e, quando há uso ativo confirmado, contenção imediata. A integração é especialmente valiosa nas fases iniciais do ataque, como reconhecimento e exploração, em que as detecções tradicionais ainda não dispararam.

2. Da Exposição à Hipótese de Caça

Um IOE é uma afirmação sobre o lado externo: existe um serviço exposto, uma credencial vazada, um certificado emitido sem registro. A hipótese de caça é a tradução dessa afirmação para o lado interno: se essa exposição existe e é conhecida de alguém, então devem existir evidências de reconhecimento, tentativa de exploração ou uso legítimo e anômalo na telemetria. O princípio operacional é direto: toda exposição relevante deve ter ao menos uma hipótese de uso indevido correspondente, escrita antes da remediação, porque a remediação destrói a janela temporal em que a evidência pode ser confirmada.

Essa antecipação é o que diferencia a integração madura de uma reação tardia. Quando a organização caça antes de corrigir, o hunt preserva o período em que a exposição esteve aberta e busca nele toda atividade associada, o que transforma a remediação em ponto de partida da investigação e não em ponto final. Quando corrige primeiro e investiga depois, a evidência externa desaparece e a interna envelhece, reduzindo a investigação a uma busca retroativa incompleta.

3. Tipos de Hipótese Geradas por EASM

Cada classe de achado externo abre uma família específica de hipóteses internas. A tabela mapeia as quatro classes de maior valor, com a formulação SE-ENTÃO correspondente e as fontes internas necessárias para testá-las.

A última linha da tabela merece destaque pela assimetria de informação que explora. O registro de um domínio similar à marca é visível publicamente minutos depois de criado, enquanto a detecção clássica de phishing só acontece quando a mensagem chega ou quando a vítima clica. Caçar resoluções internas para a infraestrutura recém-registrada antecipa a descoberta da vítima para antes do clique, transformando dado de ameaça em defesa preventiva.

O catálogo de hipóteses por tipo de exposição é o artefato que organiza essa variedade. Cada linha do catálogo descreve o tipo de achado externo, a hipótese padrão, as consultas associadas e as fontes internas necessárias, e serve de biblioteca para o TH.6 acelerar a formulação. Um catálogo começando com as quatro classes da tabela já cobre a maior parte dos achados de um programa iniciante, e novas linhas são acrescentadas a cada classe de exposição que o EASM revelar na prática.

4. Fluxo de Trabalho: do IOE à Busca Interna

O fluxo formaliza o caminho do indicador de exposição até o encerramento do hunt. A cadência básica é diária para a triagem, e o subcontrole INT.4.3 automatiza o disparo no SOAR quando a severidade do achado é crítica. O roteiro abaixo descreve as etapas e as condições de decisão.

FLUXO: da exposição externa à busca interna
1. GATILHO: novo IOE na watchlist do INS.4, com severidade alta ou crítica
2. TRIAGEM no TH.5:
   validar pertinência, dono do ativo e janela de telemetria disponível
   SE o ativo não tem dono nem registro ENTAO abrir achado no INS.1 em paralelo
3. FORMULAÇÃO no TH.6:
   traduzir o IOE em hipótese SE-ENTÃO com critério de validação objetivo
4. EXECUÇÃO no TH.10:
   buscar reconhecimento, tentativa de exploração e uso legítimo anômalo
5. DECISÃO:
   SE evidência de uso ativo ENTAO abrir caso no IR.x e acionar contenção
   SE evidência de reconhecimento ENTAO registrar observables e reforçar coleta
   SENAO registrar resultado negativo e manter o IOE em monitoramento recorrente
6. FECHAMENTO:
   atualizar o baseline do TH.2, reportar no CTI.9 e avaliar detecção no AUT.3

O passo 5 é deliberadamente humano no nível básico e intermediário. A diferença entre tentativa frustrada e exploração bem sucedida raramente é evidente na primeira consulta, e a decisão de abrir incidente tem custo organizacional. A automação prepara a consulta, junta as evidências e abre o rascunho do caso, mas a classificação inicial permanece com o hunter até que os padrões estejam maduros o bastante para o gate automático.

5. Exemplo Completo: Credencial de Conta de Serviço em Repositório Público

O monitor de exposição do INS.4, alimentado por busca externa periódica em repositórios públicos, encontra um arquivo de configuração com a senha da conta de serviço svc_backup e a chave de API do portal de armazenamento, publicadas há seis dias por um desenvolvedor que copiou o repositório local para um fork público. O IOE é registrado com severidade crítica, porque a conta tem acesso a compartilhamentos de arquivo em três filiais e o ambiente permite autenticação externa.

A triagem confirma que a conta não permite MFA por ser do tipo serviço, o que eleva o risco, e o TH.5 aceita o hunt com prioridade máxima. A hipótese formulada no TH.6 é testável em duas frentes: logons de rede com a conta a partir de origens novas e autenticações no provedor de identidade fora do padrão de horário e de geografia do serviço. A consulta abaixo cruza as duas frentes em um único pivô.

let Conta = "svc_backup";
union
(SecurityEvent
| where EventID == 4624 and LogonType == 3
| where TargetUserName =~ Conta
| project Tempo = TimeGenerated, Origem = Computer, IpOrigem = IpAddress,
    Fonte = "logon rede 4624"),
(SigninLogs
| where Identity contains Conta
| project Tempo = TimeGenerated, Origem = AppDisplayName, IpOrigem = IPAddress,
    Fonte = "Entra ID")
| summarize Logons = count(), Primeiro = min(Tempo), Ultimo = max(Tempo),
    Ips = dcount(IpOrigem) by Fonte, Origem
| order by Primeiro asc

O resultado mostra logons de rede legítimos da rotina de backup e, há nove dias, uma sequência de logons tipo 3 a partir de um IP sem histórico na organização, seguida de leitura massiva em dois compartilhamentos e de autenticação no portal de armazenamento com o User-Agent de uma ferramenta de linha de comando, às 04:37. O padrão é compatível com acesso ativo usando a credencial vazada, e o achado é classificado como verdadeiro positivo em menos de quatro horas desde o gatilho.

A contenção executa três ações coordenadas: revogação e rotação imediata da senha e da chave de API, bloqueio do IP no firewall de borda com monitoramento de variação e abertura do caso no IR.x com escopo de exfiltração, incluindo revisão dos eventos 4663 de leitura na janela do acesso. A remediação da fonte acontece em paralelo, com limpeza do fork, análise do histórico do repositório e implantação de verificação automática de segredos no pipeline de desenvolvimento. O fechamento gera detecção permanente para padrões de logon anômalo da conta, atualiza o baseline do TH.2 e registra no CTI.9 a lição de que credenciais de serviço sem MFA exigem restrição de origem compensatória.

6. Cadência e Automação: Watchlists de IOE

A escala do fluxo depende de automatizar a parte recorrente. A watchlist de IOEs é alimentada pela plataforma de EASM e pelo INS.4, e as consultas de caça correspondentes rodam agendadas, diariamente para severidade alta e crítica e semanalmente para as demais. O exemplo abaixo consulta a watchlist e busca conexões internas para os domínios sinalizados na última janela.

let IOEs = _GetWatchlist("ioes_easm")
| where Severidade in ("alta", "critica")
| project Dominio = tostring(Entidade), Severidade, CriadoEm;
DeviceNetworkEvents
| where Timestamp > ago(1d)
| extend Dominio = tostring(parse_url(RemoteUrl).Host)
| join kind=inner (IOEs) on Dominio
| summarize Conexoes = count(), Endpoints = dcount(DeviceName),
    Ultima = max(Timestamp) by Dominio, Severidade
| order by Conexoes desc

O padrão de watchlist tem três vantagens operacionais. Primeiro, mantém a memória da exposição viva mesmo depois da remediação, permitindo caçar o período anterior à correção. Segundo, dá às consultas uma fonte única e versionada, evitando busca manual por achado. Terceiro, cria a infraestrutura natural para o workflow do INT.4.3 no SOAR, que dispara as mesmas consultas na hora do achado crítico e abre o rascunho do caso quando o resultado não é vazio.

A janela de retenção da watchlist deve ser calibrada pelo dwell time típico do adversário, e não pela conveniência de limpeza da lista. Remover o IOE na semana seguinte à remediação apaga a possibilidade de caçar o período em que a exposição esteve aberta, janela em que o adversário pode ter operado sem ser notado. A regra prática é manter cada IOE por ao menos o dobro da retenção da telemetria consultada, e expirar com revisão registrada, e não com exclusão silenciosa.

7. Relação com o Hunting de Identidade (TH.14)

O hunting de identidade do TH.14 cobre o comportamento de contas, autenticações e uso de credencial no ambiente, e o INT.4 é um de seus gatilhos externos mais valiosos. Uma credencial vazada não é apenas um dado de exposição, é a chave de entrada mais usada por adversários que operam por login em vez de exploit. Quando o IOE de credencial alimenta uma caça de identidade, o programa cobre o ciclo completo da credencial: o vazamento externo, o primeiro uso interno, a persistência via mecanismo de acesso e a lateralidade subsequente.

A combinação também calibra as duas frentes. O TH.14 fornece ao INT.4 os baselines de horário, origem e dispositivo por conta, que são o critério de anormalidade nas consultas, e o INT.4 fornece ao TH.14 a lista priorizada de contas cujo risco de comprometimento é concreto, e não hipotético. Essa colaboração transforma o hunting de identidade de disciplina analítica em rotina operacional com gatilhos de negócio.

8. Métricas da Integração

O conjunto funciona como painel trimestral do controle. Tempo IOE à hipótese e cobertura de hunts medem o processo, VP originado de EASM mede a qualidade preditiva da integração, e as métricas de contenção e revogação medem o desempenho quando o pior cenário se confirma. A última métrica, de catálogo de hipóteses por tipo de exposição, é o indicador de maturidade que antecede a escala, porque automatizar o que não tem hipótese escrita apenas industrializa o vazio.

9. Salvaguardas por Nível de Maturidade

A evidência de maturidade acompanha o mesmo padrão dos demais controles do grupo. No básico, guardam-se os registros de escopo de hunting gerado por exposição e as consultas agendadas; no intermediário, os workflows versionados do SOAR e os casos abertos automaticamente; no avançado, os estudos de correlação temporal que fundamentaram decisões de priorização. Sem trilha de evidência, a integração se sustenta apenas em depoimento de equipe e se perde com a rotatividade.

10. Erros Comuns e Pontos de Atenção

• Tratar IOE como incidente: nem toda exposição sinalizada implica comprometimento, e inflar a classificação esgota a equipe; o fluxo distingue uso ativo, reconhecimento e resultado negativo antes de qualquer escalonamento.
• Hunt único e sem recorrência: caçar uma única vez e arquivar perde o adversário que chega depois; a watchlist agendada mantém o monitoramento vivo.
• Foco só em porta e serviço: hipóteses restritas a infraestrutura de rede ignoram credencial e identidade, que são o vetor majoritário de acesso inicial.
• Watchlist sem governança: lista que cresce sem expiração vira ruído permanente, e consulta lenta é consulta abandonada; cada IOE precisa de prazo de revisão e critério de encerramento.
• Remediar antes de caçar: corrigir a exposição e só então lembrar da investigação destrói a janela de evidência externa e envelhece a interna; a ordem do fluxo existe por uma razão técnica.
• Caça sem retorno ao CTI: achados desta integração seguem o mesmo destino dos demais e precisam da ficha do INT.2, sob pena de repetir o mesmo hunt trimestralmente sem aprendizado acumulado.
• Escopo sem titularidade: caçar uso indevido de um ativo sem dono identificado termina em contenção sem responsável de remediação; resolver o dono no INS.1 é pré-condição da triagem.

11. Integração com Outros Controles do Framework CTH

O INT.4 é consumidor dos achados do INS.3 e do INS.4 e dos metadados do INS.1 e do INS.2, que resolvem a titularidade do ativo, e opera com a fila do TH.5, as hipóteses do TH.6 e as buscas do TH.10. Os baselines do TH.2 definem o que é anômalo nas consultas, e o TH.14 recebe os gatilhos de credencial e identidade descritos na seção 7. Os observáveis gerados pela caça seguem para o TIP pelo INT.2 e se tornam detecção pelo AUT.3, enquanto os casos confirmados transitam pelo grupo IR.

No plano de dados, a integração depende da telemetria centralizada do grupo DAT, com destaque para autenticação, DNS, proxy e WAF, e das plataformas do grupo PLT para enriquecimento dos domínios e IPs associados. O INT.5 orquestra o disparo automático quando existe SOAR, e as métricas da seção 8 alimentam o grupo MET e a revisão do GOV. Com esses elos, a superfície externa deixa de ser um relatório periódico e passa a alimentar diretamente as caças que protegem o ambiente interno.

O encadeamento com o INT.3 merece leitura conjunta, porque os dois controles operam sobre os mesmos achados com perguntas diferentes. O INT.3 pergunta quando e como remediar, e o INT.4 pergunta se alguém já usou a exposição; um não substitui o outro, e a ordem entre eles é política de programa, com a caça preservando a evidência antes da correção sempre que a janela de risco tolerar. Essa dupla é o exemplo mais claro de como o Framework CTH converte um dado de inventário em duas linhas de defesa complementares.