Análise de Campanhas e Agrupamentos (Clustering)

Nota do capítulo 05 (Análise e Produção de Inteligência), núcleo analítico do ciclo.
Define o conceito de campanha e organiza o agrupamento de atividade por infraestrutura, TTPs, ferramentas e janela temporal, com critérios para clustering manual e automático.
Trata de nomenclatura temporária e definitiva e dos riscos de over-clustering, com exemplo completo de agrupamento de uma campanha de phishing. Dialoga com o Diamond Model, com a Pirâmide de Dor e com a nota de Atribuição de Ameaças.

1. Contexto e Posicionamento na Biblioteca

A análise de campanhas é o ponto em que observações soltas se transformam em conhecimento estruturado sobre a atividade de um adversário. Os capítulos de coleta e de indicadores entregam peças isoladas: um domínio recém-registrado, um hash desconhecido, uma onda de e-mails suspeitos, um certificado TLS emitido com padrão estranho. O clustering é o processo analítico que conecta essas peças em conjuntos com identidade própria, e é essa conexão que permite afirmar que uma operação coordenada está em curso, e não que incidentes sem relação aconteceram por coincidência.

Dentro da biblioteca, esta nota é o núcleo analítico do capítulo 05. O Diamond Model, do capítulo 04, fornece a unidade de evento que aqui se agrupa; a Pirâmide de Dor fornece a métrica de custo que hierarquiza a força dos vínculos; e a nota de Atribuição de Ameaças consome o cluster maduro como insumo para julgamentos sobre quem opera. No lado operacional, a técnica aparece como método de hunting no TH.9 da seção 15 e sustenta os produtos de relato do capítulo 06, que só têm valor quando decorrem de um agrupamento bem documentado e revisável.

2. O Conceito de Campanha

Campanha é uma operação delimitada no tempo, conduzida por um adversário contra um conjunto de alvos, com objetivo comum e recursos operacionais compartilhados. A delimitação temporal é o que separa campanha de atividade contínua: a campanha tem início, pico e declínio visíveis, normalmente associados a um esforço dedicado de infraestrutura, como um lote de domínios registrados na mesma semana. O objetivo comum pode ser monetização imediata, espionagem prolongada ou destruição, e é o objetivo que explica por que ferramentas, horários e rotinas se repetem dentro da campanha e mudam entre campanhas.

É essencial distinguir campanha de três conceitos vizinhos que relatórios apressados costumam confundir. O incidente é a ocorrência contra uma única vítima, com contorno forense próprio, e uma campanha madura costuma produzir muitos incidentes. O ator é a entidade que conduz campanhas ao longo do tempo e persiste quando as campanhas terminam, e a atribuição da campanha a um ator é julgamento separado, tratado na nota seguinte. O malware é um recurso dentro da campanha, e a mesma família pode aparecer em campanhas de atores distintos, especialmente no ecossistema de ransomware como serviço, no qual afiliados reciclam a mesma carga.

O ciclo de vida típico da campanha tem cinco fases que o analista deve tentar reconstruir. Na preparação ocorrem registro de domínios e montagem de infraestrutura; no lançamento ocorrem os primeiros envios ou explorações; no pico a atividade atinge o máximo observado; no declínio a infraestrutura queima ou é desativada; e na dormência a operação pode reaparecer sob nova infra. Mapear a fase atual tem valor operacional direto, porque as ações de defesa mudam conforme a fase: no lançamento valem bloqueios preventivos e caça retrospectiva, e no pico valem alertas reforçados e contenção ativa.

3. Dimensões de Agrupamento da Atividade

O agrupamento correto se apoia em quatro dimensões complementares, e a prática madura exige que pelo menos duas delas converjam antes de declarar que eventos distintos pertencem à mesma campanha. A tabela abaixo resume as dimensões, os artefatos típicos de cada uma e o peso relativo, herdando a lógica de raridade da Pirâmide de Dor.

Infraestrutura é a dimensão mais utilizada porque é a mais observável, mas é também a mais traiçoeira, porque grande parte da internet compartilha hospedagem. Vínculo por ASN ou por provedor de nuvem popular não agrupa nada por si só, e o analista deve escalar o vínculo até o artefato raro: nameserver dedicado, template de certificado, identificador embutido no kit de phishing. TTPs e ferramentas são mais estáveis no tempo, e o reuso de código entre atores distintos é justamente o ponto em que a dimensão de ferramentas exige cruzamento com tempo e infraestrutura antes de gerar conclusão.

4. Clustering Manual

O clustering manual é executado pelo analista por meio de pivoting interativo e julgamento fundamentado, e é o método padrão quando o volume é baixo ou o caso exige contexto. O fluxo típico parte de um artefato forte, como um domínio de phishing confirmado, e expande de forma controlada, registrando cada vínculo com evidência, fonte e data. A sequência abaixo é o roteiro de expansão mais produtivo em casos de phishing.

• Coletar a página hospedada em sandbox e extrair identificadores do template, comentários de código e parâmetros de coleta, que são artefatos raros e estáveis.
• Consultar DNS passivo e histórico de resolução para descobrir domínios irmãos que resolveram para o mesmo IP ou compartilharam nameserver.
• Consultar Certificate Transparency para listar certificados emitidos para o mesmo domínio base ou com o mesmo padrão de subdomínio.
• Abrir o whois histórico e comparar registrante, registradora e padrões de ofuscação entre os domínios candidatos.
• Verificar os IPs de envio nos logs do gateway e agrupar por ASN, reputação e janela de envio, marcando esse vínculo como fraco.
• Comparar o HTML das páginas por similaridade textual e estrutural, porque template idêntico é vínculo forte de operação.

A vantagem do método manual é a qualidade do julgamento contextual, que percebe quando um vínculo aparente é coincidência ou quando um detalhe pequeno invalida a fusão. A limitação é a escala, porque nenhum analista agrupa manualmente dezenas de milhares de eventos por mês, e o viés do caso dominante, que puxa novas atividades para a hipótese favorita do analista. Por isso o trabalho manual deve ser documentado aresta por aresta, de modo que outro analista consiga revisar e refutar cada vínculo declarado.

5. Clustering Automático

O clustering automático aplica cálculo de similaridade e algoritmos de agrupamento sobre conjuntos grandes, e a prática de mercado usa três famílias complementares. A similaridade por sobreposição calcula proporção de atributos compartilhados, com métricas como Jaccard sobre listas de técnicas ATT&CK, de hashes ou de infraestrutura. Os algoritmos por densidade, como DBSCAN, e os hierárquicos, como aglomeração por ligação média, organizam vetores de características em grupos sem número pré-definido de clusters. A similaridade semântica usa embeddings de texto sobre relatórios e descrições para encontrar atividade parecida com a já documentada, recurso presente em plataformas como o OpenCTI e em pipelines de enriquecimento modernos.

Plataformas consagradas oferecem a mecânica pronta. O MISP correlaciona atributos por valor exato e por similaridade, com clusters e galáxias nomeando conjuntos consagrados. O OpenCTI modela relações entre entidades e permite visualizar o grafo da campanha conforme a semântica do Diamond Model. Ferramentas de grafo como Maltego e yEd servem à exploração manual assistida, e bibliotecas do ecossistema Python servem a pipelines sob medida. A escolha da ferramenta importa menos que a disciplina de dados: sem campos padronizados de fonte, data e confiança, nenhum algoritmo produz agrupamento auditável.

Criterios minimos de agrupamento (politica da equipe)

Vinculo forte:   1 artefato raro (chave TLS, template de kit, build de malware)
                 OU 3 artefatos medios com janela temporal compativel

Vinculo medio:   2 artefatos medios sem conflito temporal
Vinculo fraco:   ASN, provedor de hospedagem, TLD, setor das vitimas

Regra de declaracao: cluster se declara com 1 vinculo forte,
                     ou com 2 medios + 1 fraco, sempre com evidencia,
                     fonte e data registradas para cada aresta do grafo.

Na prática, os dois métodos se combinam: a automação propõe grupos candidatos e o analista valida, recusa ou fragmenta. Automatizar sem validação transforma erro sistemático de coleta em erro sistemático de análise, e validar tudo manualmente devolve o gargalo ao analista. O equilíbrio operacional é tratar a saída do algoritmo como hipótese a verificar, nunca como veredito, e medir a taxa de concordância do analista com as propostas para calibrar os parâmetros ao longo do tempo.

6. Nomenclatura Temporária e Definitiva

Toda atividade nova deve nascer com identificador temporário, neutro e estável, antes de qualquer nome de difusão. O padrão recomendado é um código com ano, número sequencial e tema técnico, como CLUSTER-2025-041-PHISH-FIN, que não presume ator, objetivo nem severidade. O identificador temporário cumpre função de rastreabilidade: permite que vítimas, eventos e artefatos sejam associados ao mesmo conjunto desde o primeiro dia, mesmo sem saber ainda quem opera e com qual objetivo.

A nomenclatura definitiva entra apenas quando o cluster atinge maturidade analítica, com contorno temporal fechado, infraestrutura principal documentada e julgamento sobre ator registrado com confiança explícita. Nomes definitivos devem ser estáveis, pronunciáveis e livres de humor ou de sensibilidade política, porque nomear é decisão de comunicação que dura anos e é cobrada publicamente. Quando fornecedor ou autoridade já nomeou a atividade, a tabela de aliases mantém a correspondência, e o relatório interno usa o nome interno com os aliases públicos documentados em campo próprio, evitando que nomes de mercado diferentes fragmentem o mesmo conjunto na base organizacional.

registro_cluster:
  id: CLUSTER-2025-041-PHISH-FIN
  nome_definitivo: null
  aliases_publicos: []
  janela: "2025-03-28 a 2025-04-14"
  fase: declinio
  status: temporario
  confianca_agrupamento: alta
  base:
    dominios: 17
    nameserver_dedicado: "ns1.servico-rodando[.]net"
    kit_phishing: "template webmail-login v3.2"
    envio: "40 IPs em 2 ASNs de baixa reputacao"
  tecnicas_attack: [T1566.002, T1071.001, T1140]
  hipoteses:
    - "ator financeiro regional, confianca baixa, pendente de triangulacao"
    - "reuso de kit comercializado, a validar pela assinatura do template"

7. Over-Clustering e Under-Clustering

Over-clustering é a fusão indevida de atividades distintas em um único conjunto, e é o erro de maior custo analítico, porque contamina todas as conclusões derivadas do cluster. As causas típicas são três: vínculo por artefato denso, como ASN ou hospedagem compartilhada; reuso real de recursos por atores diferentes, como kit de phishing vendido e usado por vários grupos; e viés de confirmação, quando o analista quer que a nova atividade pertença ao caso que domina. As assinaturas do problema são visíveis e devem ser tratadas como alarmes de revisão obrigatória.

• Cluster com janela temporal que não fecha, reunindo atividade de 2023 e de 2025 sem continuidade explicada entre os períodos.
• Cluster com famílias de malware incompatíveis entre si, como ransomware de afiliados rivais e spyware de perfil estatal no mesmo grafo.
• Cluster que cresce em saltos por pivô de artefato denso, dobrando de tamanho a cada expansão por ASN ou por provedor de hospedagem.
• Conclusões de atribuição que mudam de ator a cada revisão, sem nova evidência material que justifique a alteração.

Under-clustering é o problema oposto e é mais frequente do que se admite: atividades da mesma operação tratadas como casos isolados, com o time de resposta a incidentes reabrindo o mesmo padrão de intrusão três vezes sem perceber. A assinatura típica é a detecção recorrente da mesma sequência de técnicas com infraestrutura nova a cada semana, padrão que o agrupamento por TTPs captura e que o agrupamento por IOC (Indicator of Compromise) perde. A revisão periódica de clusters abertos, comparando novos eventos contra os existentes antes de criar novos, é o controle de rotina contra os dois excessos, e deve ter cadência definida em política, com registro de quem revisou e do que mudou.

8. Exemplo Prático: Agrupamento de uma Campanha de Phishing

O caso abaixo acompanha o agrupamento de uma campanha de phishing contra o setor financeiro, partindo de três e-mails reportados por usuários em 48 horas. A análise começa pelos artefatos observáveis das mensagens: domínios remetentes distintos, links para páginas de login falsas e o mesmo template visual. O pivoting inicial pelos domínios revela que os três resolvem para o mesmo nameserver dedicado e apresentam certificados emitidos no mesmo intervalo de 48 horas, o que configura vínculo forte conforme os critérios da seção 5.

Com o cluster declarado, a caça retrospectiva valida o alcance interno antes das ações de bloqueio, e a consulta abaixo é o ponto de partida padrão em plataforma de estilo KQL.

// Caca retrospectiva por kit v3.2 e dominios do cluster
DeviceNetworkEvents
| where Timestamp between (datetime(2025-03-01) .. datetime(2025-04-14))
| where RemoteUrl has_any ("webmail-login", "kit/v3.2")
   or RemoteUrl endswith_any (".top", ".shop", ".icu")
| summarize Contagem = count(), PrimeiroVisto = min(Timestamp),
            UltimoVisto = max(Timestamp) by DeviceName, RemoteUrl
| order by UltimoVisto desc

A delimitação temporal fecha com base nas datas de registro dos domínios, entre 28 de março e 2 de abril, e no último avistamento de envio, em 14 de abril. As saídas operacionais seguem diretamente do agrupamento: a lista dos 17 domínios vira regra de bloqueio preventivo no gateway, o identificador do template vira caça retrospectiva por kits idênticos em proxies e sandboxes, e a janela de envio vira janela de alerta reforçado para a próxima onda. A hipótese de ator permanece aberta com confiança baixa, e é essa separação entre agrupamento técnico maduro e atribuição imatura que protege a credibilidade do produto final.

9. Métricas e Revisão Periódica

O cluster é artefato vivo, e viver sem medição é a receita do acúmulo descontrolado. A política de análise deve definir métricas de qualidade do agrupamento e revisar cada cluster aberto em cadência fixa, normalmente mensal para clusters ativos e trimestral para clusters dormentes. A tabela abaixo traz o conjunto mínimo recomendado.

A revisão deve gerar três desfechos possíveis, todos registrados: confirmação do cluster como está, fragmentação com reaproveitamento dos identificadores filhos, ou arquivamento com motivo documentado. Revisão sem desfecho formal é burocracia sem efeito, porque o grafo volta a crescer com os mesmos vícios da revisão anterior.

10. Erros Comuns e Pontos de Atenção

• Agrupar por artefato denso: ASN, TLD, provedor de hospedagem e setor de vítima são contextos, não vínculos, e a raridade do artefato compartilhado deve ser verificada antes de qualquer fusão.
• Declarar campanha sem janela temporal: conjunto sem início e fim verificáveis não delimita operação, e a ausência de fronteira impede medir pico, declínio e reaparecimento.
• Nomear antes de maturar: nome difundido cedo cria compromisso público com hipótese frágil, e a correção posterior custa mais que a paciência inicial.
• Tratar saída de algoritmo como veredito: modelo de similaridade sobre dados de coleta enviesados produz clusters que espelham o viés, e a validação analítica é obrigatória.
• Ignorar reuso intencional de recursos: kits comercializados, ferramentas vazadas e infraestrutura alugada circulam entre atores, e a dimensão de ferramentas exige cruzamento com infraestrutura e tempo.
• Manter cluster sem revisão: grafos vivos acumulam vínculos fracos agregados ao longo de meses, e a revisão periódica com critérios explícitos evita que o conjunto vire colcha de retalhos.
• Documentar vínculo sem evidência: cada aresta precisa carregar fonte, data e método, porque link sem proveniência não é verificável e não sobrevive a revisão por pares.
• Confundir densidade com certeza: cluster com muitas observações é apenas um cluster grande, e a força do conjunto está na raridade e na consistência dos vínculos, não no volume.

11. Integração com o Restante da Biblioteca

O cluster bem construído é o insumo direto da nota seguinte sobre atribuição, que parte do agrupamento técnico maduro para julgar quem opera, com confiança calibrada e separando evidência de inferência. No capítulo 04, o Diamond Model fornece os eventos que aqui se agrupam e a lógica de travessia de vértices que o analista executa no pivoting, e a Pirâmide de Dor explica por que alguns vínculos pesam mais que outros. No capítulo 06, os produtos de relato assumem o cluster como unidade narrativa: o perfil de ator agrega vários clusters, e o flash report de campanha em curso descreve a janela ativa com indicações acionáveis.

No lado operacional da seção 15, o TH.9 usa clustering como técnica de hunting para descobrir atividade não reportada, o TH.7 agrupa eventos por comportamento em vez de infraestrutura, e os controles CTI.6 e CTI.7 transformam o cluster validado em relatório com estrutura e público definidos. A síntese que esta nota deixa é de disciplina: agrupar é decidir, e cada decisão de agrupamento deve ser reversível, evidenciada e revisável, porque é sobre esses conjuntos que a organização constrói detecções, respostas e julgamentos estratégicos.