Pivoting e Correlação de Infraestrutura

Nota da seção "06 - Análise de Infraestrutura" do capítulo 03 (Indicadores de Ameaças: IOC, IOA, IOB, IOE).
Formaliza o pivoting como método analítico: catálogo de pivôs por robustez, falsos pivôs criados por CDN e compartilhamento, construção de clusters de infraestrutura e documentação do grafo com confiança explícita.
Consome as notas de Certificados TLS, de Hosting e CDN e de Domínios desta seção, e dialoga com o Diamond Model do capítulo 04.

1. Contexto e Posicionamento na Biblioteca

Um indicador isolado é um dado; a inteligência nasce da relação entre indicadores. O pivoting é a operação que expande um indicador conhecido em outros, seguindo vínculos reais de infraestrutura: do hash do malware para o domínio de C2, do domínio para o certificado, do certificado para os domínios irmãos, do whois para o operador. É a técnica que transforma a denúncia de um único endereço na cartografia completa de uma campanha, e é também a técnica que mais produz erros quando aplicada sem método, porque nem todo vínculo observado é vínculo real de dono.

Esta nota organiza o método em quatro partes. O catálogo de pivôs classifica cada tipo de vínculo pela robustez, ou seja, pela probabilidade de que o vínculo sobreviva à rotação do adversário e a revisão crítica. O tratamento dos falsos pivôs neutraliza as relações acidentais que CDN, certificados compartilhados e privacidade de registro fabricam. A construção de clusters converte cadeias de pivôs em conjuntos de infraestrutura com confiança calculada. A documentação do grafo garante que o resultado seja reproduzível, auditável e reutilizável pelas demais notas da biblioteca.

2. O Pivô como Operação Lógica

O pivô parte de um objeto conhecido, chamado âncora, aplica um vínculo e obtém novos objetos, que por sua vez viram âncoras de novas expansões. A direção importa e carrega significado analítico diferente. No pivô direto, também chamado de forward, parte-se do artefato do adversário e caminha-se para o resto da infraestrutura, como do domínio para o IP. No pivô reverso, ou backward, parte-se de um atributo e busca-se quem mais o usa, como do IP para a lista de domínios que já resolveram para ele. No pivô cruzado, troca-se de plano, como do plano de rede para o plano de registro, ao buscar o e-mail de whois do domínio que resolveu para o IP.

A disciplina de expansão segue três regras que evitam o crescimento descontrolado do grafo. Primeiro, cada pivô novo exige verificação de janela de tempo, porque infraestrutura gira e o vínculo sem data não é evidência. Segundo, cada expansão deve registrar a fonte que sustenta o vínculo, seja consulta direta, DNS passivo ou relatório de terceiro. Terceiro, a expansão para quando o retorno marginal cai: se três domínios irmãos vieram do certificado e nada novo surgiu deles, a cadeia está madura, e o esforço deve migrar para validação.

3. Catálogo de Pivôs e Robustez

A tabela abaixo cataloga os pivôs de uso mais frequente, com a robustez de cada um e a ferramenta típica de execução. Robustez alta significa que o vínculo raramente existe por acidente e sobrevive à troca de domínio ou de IP; robustez baixa significa que o vínculo é barato de criar e de trocar, e serve como pista, não como prova.

Os comandos abaixo ilustram três pivôs do catálogo em execução real, do domínio suspeito para o certificado, do IP para a lista de domínios que já o usaram e do favicon para a busca por infraestrutura idêntica.

# Pivo 1: certificado coletado no host, hash SHA-1 e SAN para busca cruzada
echo | openssl s_client -connect alvo-suspeito.top:443 2>/dev/null \
  | openssl x509 -noout -fingerprint -sha1 -ext subjectAltName

# Pivo 2: Shodan busca hosts que apresentam o mesmo certificado
# shodan search 'ssl.cert.fingerprint:<hash_sha1>'

# Pivo 3: hash mmh3 do favicon e busca por servidores com o mesmo template
cat favicon.ico | openssl dgst -md5 | cut -d' ' -f2
# shodan search 'http.favicon.hash:<hash>'

4. Falsos Pivôs e Sua Neutralização

O falso pivô é o vínculo que a observação confirma e que a lógica de dono não sustenta. Ele surge quando a infraestrutura compartilhada fabrica coincidências estatisticamente fortes e analiticamente vazias, e é a principal fonte de relatórios de atribuição desmentidos depois. A tabela abaixo lista os falsos pivôs de maior incidência e a verificação que os neutraliza.

A regra prática que resume a tabela é a exigência de vínculo duplo: nenhum cluster relevante se fecha com um único tipo de pivô. Domínio irmão declarado apenas pela co-residência em IP de hospedagem compartilhada fica fora do grafo como aresta fraca, ou fica com confiança baixa explicitamente registrada, e arestas fracas não sustentam ação de bloqueio nem contato com provedor. Essa regra é o que separa o pivoting de alta qualidade da simples agregação de consultas.

5. Clusters de Infraestrutura e Cadeias de Pivôs

O cluster é o produto do pivoting: um conjunto de domínios, endereços, certificados e atributos de registro que formam uma unidade operacional do adversário, com fronteira e confiança declaradas. A construção segue a lógica do Diamond Model, detalhada no capítulo 04, no qual cada observação vira um evento com quatro vértices, e o pivô é exatamente a aresta entre eventos por um vértice compartilhado. O cluster maduro descreve, portanto, uma atividade, e não apenas uma lista de endereços: carrega janela de tempo, vínculos com campanhas conhecidas e o tipo de infraestrutura de cada nó, conforme a nota de Hosting e CDN.

A atribuição de confiança ao cluster é cálculo explícito, e não sensação. Cada aresta contribui pela robustez do pivô que a criou, pela quantidade de fontes independentes que a confirmam e pela janela de tempo que cobre. Um cluster com três domínios ligados por chave pública idêntica e whois comum tem confiança alta; a mesma lista ligada apenas por ASN tem confiança baixa e serve de hipótese de investigação. O parâmetro operacional é simples: ação de bloqueio imediato exige confiança alta em pelo menos uma aresta forte, e todo o restante entra como monitoramento.

A tabela abaixo propõe uma escala de referência para o cálculo, que cada equipe ajusta ao seu apetite de risco e à qualidade de suas fontes.

A regra complementar é que a confiança do cluster jamais supera a confiança da aresta mais fraca usada na conclusão que se pretende sustentar. Um relatório que afirma autoria comum precisa de pivô forte, mesmo que o cluster tenha trinta nós; a quantidade não substitui a qualidade do vínculo.

6. Documentação do Grafo e Registro de Evidência

O grafo precisa viver em ferramenta, e não em memória ou captura de tela. As opções comuns na prática de mercado vão do Maltego, com transforms comerciais, ao OpenCTI, que modela observáveis e relacionamentos em STIX 2.1, até desenho manual em yEd para casos rápidos. Independente da ferramenta, cada nó carrega tipo de objeto, valor normalizado, primeira e última observação, fonte e confiança, e cada aresta carrega o tipo de pivô, a fonte que o confirmou e a janela de tempo. O fragmento abaixo mostra uma aresta em STIX 2.1, formato que a nota de STIX e TAXII da seção 05 trata em profundidade.

{
  "type": "relationship",
  "spec_version": "2.1",
  "id": "relationship--3f1c9a2e-0000-4b21-9a11-6c9f2a1d0001",
  "created": "2025-05-14T12:00:00.000Z",
  "modified": "2025-05-14T12:00:00.000Z",
  "relationship_type": "resolves-to",
  "source_ref": "domain-name--1a2b3c4d-0000-4e11-8a22-7d8e3f4a0002",
  "target_ref": "ipv4-addr--5e6f7081-0000-4f12-9b33-8e9f4a5b0003",
  "confidence": 90,
  "description": "Resolução direta observada em DNS passivo entre 2025-05-10 e 2025-05-14"
}

A disciplina de documentação inclui o registro das consultas que produziram cada descoberta, porque a reprodução é o teste de qualidade do grafo. Um caso documentado permite que outro analista refaça a cadeia em minutos, confirme ou conteste cada aresta e reutilize os pivôs em campanhas futuras. Na prática da biblioteca, o relatório de caso inclui três produtos: o grafo exportado, a lista de indicadores com confiança e o registro de hipóteses não confirmadas, que permanecem visíveis para futura validação em vez de sumirem no rascunho.

A manutenção do grafo é tarefa rotineira, e não evento. A consulta abaixo, executada em cadência mensal sobre a base de arestas, lista os vínculos de rede que passaram do prazo de revalidação e precisam de checagem nova, evitando que o grafo acumule arestas mortas tratadas como vivas.

-- Arestas de rede que exigem revalidacao nesta rodada mensal
SELECT r.id,
       r.relationship_type,
       r.confidence,
       r.last_observed
FROM   relationships r
WHERE  r.relationship_type IN ('resolves-to', 'communicates-with')
  AND  r.last_observed < CURRENT_DATE - INTERVAL '30 days'
  AND  r.status = 'active'
ORDER BY r.confidence DESC;

7. Exemplo Prático de Cadeia de Pivôs

O caso abaixo encadeia os pivôs do catálogo em uma investigação realista de phishing bancário, com a âncora em um domínio denunciado por um cliente. A cadeia é apresentada na ordem de execução, com a justificativa de cada passo.

• Âncora: o domínio saca-rembolso.top é recebido por denúncia, com captura de tela e e-mail de origem preservados.
• Pivô de resolução: o DNS direto e o DNS passivo revelam dois endereços distintos em quatro dias, ambos em nuvem de VPS, com rotação típica descrita na nota de Hosting e CDN.
• Pivô de certificado: a coleta por SNI em cada endereço devolve certificado com SAN de três domínios adicionais, e a chave pública coincide entre todos os nomes.
• Pivô de registro: o RDAP dos quatro domínios mostra criação em janelas de minutos, o mesmo registrar e o mesmo nameserver dedicado em provedor pequeno.
• Pivô de conteúdo: a página de login de cada domínio carrega o mesmo favicon hash e a mesma ordem de cabeçalhos HTTP, confirmando template comum.
• Fechamento do cluster: quatro domínios, dois endereços ativos, um certificado, um nameserver e um template, com confiança alta sustentada por três tipos de pivô independentes.
• Produtos: bloqueio dos quatro domínios, regra de monitoramento por nameserver e por favicon hash, e hipótese de hunting no proxy por template.

O tempo total de análise, com as ferramentas descritas nesta seção, é de menos de duas horas para um analista treinado, e o grafo resultante serve de âncora para as próximas campanhas do mesmo operador, porque o nameserver e o template persistem quando os domínios são substituídos. Esse é o ganho estrutural do método: os pivôs fortes sobrevivem à rotação e acumulam valor a cada caso novo.

8. Erros Comuns e Pontos de Atenção

• Pivô sem janela de tempo: relação confirmada hoje pode não ter existido no período da campanha; toda aresta carrega início e fim de observação.
• Confundir co-residência com dono: em hospedagem compartilhada e em CDN, o mesmo IP abriga operadores distintos; a nota de Hosting e CDN traz os testes de diferenciação.
• Encadear pivôs fracos: dois vínculos de robustez baixa em sequência não viram um vínculo forte; a robustez não se soma, e o cluster exige pelo menos um pivô alto.
• Esquecer o pivô de conteúdo: certificado e whois são úteis, mas template, favicon e analytics ID costumam persistir além da troca de domínio e revelam o mesmo operador meses depois.
• Deixar hipóteses fora do registro: o grafo que só guarda o confirmado apaga as pistas não confirmadas, e a hipótese descartada hoje pode confirmar o caso de amanhã.
• Automatizar sem limite: expansão automática sem poda gera grafo de milhares de nós com confiança diluída; limite a profundidade da expansão e exija filtro de janela de tempo em cada nível.
• Ignorar a poda periódica: grafo sem expiração de arestas cresce para sempre e começa a sugerir relações entre ativos mortos; a revalidação mensal e o status expirado são parte do método, e não opcional.
• Publicar sem revisão de arestas: indicadores com confiança baixa compartilhados como confirmados contaminam a comunidade e a própria base; o nível de confiança acompanha o indicador em todo compartilhamento, conforme o TLP e os controles da seção 05.

9. Integração com o Restante da Biblioteca

O método desta nota é a formalização das fontes construídas nas três notas anteriores da seção: o certificado como pivô forte vem da nota de Certificados TLS, a diferenciação de hosting e a leitura de ASN vêm da nota de Hosting e CDN, e a enumeração e o padrão de nomenclatura vêm da nota de Domínios e Subdomínios. No capítulo 04, o Diamond Model fornece o modelo de evento em quatro vértices no qual cada pivô se encaixa como aresta, e a Pirâmide de Dor explica por que os pivôs de nível alto, como template e TTP, causam mais dor ao adversário. Na seção 15, os clusters alimentam o TH.9 de clustering e o TH.10 de caça por indicadores, e o compartilhamento com confiança segue o PLT.5.

O produto final desta nota, o grafo com confiança explícita, é também o insumo que mantém a base de indicadores saudável ao longo do tempo: arestas com data e fonte envelhecem de forma controlada, expiram quando a infraestrutura morre e preservam a história da campanha para análise de longo prazo. A partir daqui, o capítulo 04 assume os modelos que dão forma analítica a esses dados, começando pelo MITRE ATT&CK.