AvanzadoCTIcampañasIOCsclusteringanálisis avanzadografos

Tracking Campaigns: De IOCs Aislados a Clusters de Actividad

Metodología para conectar IOCs aislados en clusters de actividad y campañas completas: overlap de infraestructura, similitud de código, patrones de TTP, victimología, herramientas de pivoting, convenciones de naming y automatización con grafos.

MalwareIntel Research··13 min lectura
Serie: Cyber Threat Intelligence — Parte 21

Un IOC aislado es un dato. Un cluster de actividad es inteligencia. La diferencia es conectar los puntos

Un analista recibe una alerta: una IP marcada como maliciosa en un feed CTI ha contactado con un host interno. Es un IOC. Un dato. La pregunta que transforma ese dato en inteligencia es: ¿a qué campaña pertenece esta IP? ¿Qué actor la opera? ¿Qué otros IOCs comparten infraestructura con ella? ¿Qué víctimas ha atacado? ¿Qué TTPs usa?

El proceso de campaign tracking toma IOCs individuales y los conecta en clusters de actividad que revelan campañas coordinadas. Este artículo cubre la metodología de clustering, las dimensiones de correlación, las herramientas de pivoting, las convenciones de naming de la industria y cómo automatizar el proceso con grafos.

De IOC a campaña: el proceso de correlación

El camino de un IOC aislado a una campaña documentada sigue un patrón reconocible:

IOC individual (IP, hash, dominio)
    │
    ▼
Pivoting: buscar relaciones con otros IOCs
    │
    ▼
Cluster: grupo de IOCs relacionados por infraestructura/código/TTPs
    │
    ▼
Campaña: cluster con timeline, víctimas, objetivos y atribución
    │
    ▼
Actor: campaña(s) atribuida(s) a un grupo conocido o UNC

Cada paso añade contexto y confianza. Un hash aislado tiene valor táctico (bloquear). Un cluster tiene valor operacional (cazar). Una campaña atribuida tiene valor estratégico (predecir).

Dimensiones de clustering

Los IOCs se correlacionan a través de múltiples dimensiones. Cuantas más dimensiones coincidan, mayor confianza en que los IOCs pertenecen al mismo cluster.

1. Overlap de infraestructura

La dimensión más directa. Dos IOCs comparten infraestructura cuando:

  • Mismo servidor: Múltiples dominios resuelven a la misma IP (DNS pasivo)
  • Mismo registrador: Dominios registrados con el mismo registrar, mismo email de contacto o mismos datos WHOIS (antes de GDPR)
  • Mismo proveedor de hosting: Mismo ASN, mismo rango de IPs, mismo proveedor VPS
  • Mismo certificado TLS: Certificados compartidos entre dominios aparentemente no relacionados
  • Misma infraestructura de DNS: Mismo nameserver, mismo patrón de delegación
  • Cadena de redirección: Dominio A redirige a dominio B que descarga desde IP C

Ejemplo: un dominio de phishing resuelve a una IP en AS174xx. Un C2 de Cobalt Strike detectado en otro incidente resuelve a otra IP en el mismo /24 del mismo ASN. Ambas IPs fueron provisionadas el mismo día. Esto sugiere que el mismo actor registró ambas.

2. Similitud de código

El malware evoluciona pero mantiene rasgos genéticos. La similitud de código conecta variantes:

  • SSDEEP/TLSH: Hashes fuzzy que detectan similitud parcial entre binarios. Dos samples con SSDEEP match > 60% probablemente comparten código base.
  • YARA rules: Reglas que identifican patrones de bytes, strings o estructura compartidos entre muestras.
  • Imphash: Hash de la tabla de imports de un PE. Binarios con el mismo imphash usan las mismas funciones en el mismo orden.
  • Rich header hash: Hash del rich header del PE. Identifica el entorno de compilación (compilador, versión, librerías).
  • String overlap: Strings compartidas (rutas de PDB, user-agents custom, mutex names, C2 paths).
  • Code reuse: Funciones o módulos reutilizados entre familias distintas del mismo actor.

Ejemplo: dos ransomware aparentemente distintos comparten el mismo imphash, las mismas rutas de PDB con el mismo username de desarrollador y el mismo mutex name. Son variantes del mismo toolkit, probablemente del mismo grupo de desarrollo.

3. Patrones de TTP

Los actores cambian sus herramientas pero mantienen sus hábitos operacionales:

  • Misma cadena de infección: Phishing → macro → PowerShell → C2 → lateral movement → exfiltración. El flujo se repite entre campañas.
  • Mismas técnicas ATT&CK: Un actor que siempre usa T1059.001 (PowerShell), T1055.012 (Process Hollowing) y T1071.001 (HTTPS C2) tiene un fingerprint de TTPs.
  • Mismo horario operacional: Actividad consistente en horario laboral de una zona horaria específica (indicador débil pero útil en combinación).
  • Mismas herramientas: Preferencia por Cobalt Strike con configuración específica, o uso recurrente de herramientas custom.
  • Mismo patrón de exfiltración: DNS tunneling con el mismo encoding, o RAR + password con el mismo patrón.

4. Victimología

Los actores tienen objetivos consistentes:

  • Mismo sector: Un cluster que ataca exclusivamente utilities europeas sugiere un actor state-sponsored con mandato específico.
  • Misma región geográfica: Ataques concentrados en un país o bloque (EU, MENA, SEA).
  • Mismo tipo de organización: Solo PYMEs, solo gobierno, solo defensa.
  • Mismo tipo de datos: Siempre exfiltra propiedad intelectual, o siempre despliega ransomware.

La victimología es un indicador de motivación y, por extensión, de tipo de actor (state-sponsored vs. criminal vs. hacktivista).

Herramientas de pivoting

Maltego

Plataforma de link analysis y OSINT. Permite pivotar entre IPs, dominios, hashes, emails, certificados y organizaciones usando transforms que consultan múltiples fuentes.

Flujo típico: Dominio sospechoso → DNS pasivo (IPs históricas) → Reverse DNS (otros dominios en esas IPs) → WHOIS (registrador, email) → Certificados (otros dominios en el mismo cert) → VirusTotal (samples que contactaron esos dominios).

DomainTools Iris

Especializada en DNS e infraestructura de dominios. Su base de datos histórica de WHOIS, DNS pasivo y hosting permite pivotar entre dominios registrados por el mismo actor incluso cuando los datos WHOIS están redactados (GDPR).

Features clave: Iris Investigate (pivoting interactivo), Risk Score (scoring de dominios), Connected Infrastructure (dominios relacionados automáticamente).

PassiveTotal / RiskIQ

Plataforma de inteligencia de infraestructura de Microsoft (adquirida en 2021). DNS pasivo, WHOIS histórico, certificados SSL, trackers web (analytics IDs compartidos), host pairs (relaciones padre-hijo entre dominios).

Un uso potente: buscar el mismo Google Analytics ID o Meta Pixel en múltiples dominios de phishing. Si todos comparten el mismo tracker, el actor es el mismo.

MISP

Plataforma de sharing CTI open source. Cada evento MISP puede contener IOCs, objetos, galaxies (actores, malware) y relaciones. La correlación automática de MISP identifica cuando IOCs de eventos distintos coinciden.

MISP galaxies permiten enriquecer clusters con taxonomías estandarizadas: threat actor, malware family, sector objetivo, país de origen.

VirusTotal Graph

Visualización de relaciones entre ficheros, dominios, IPs y URLs basada en la base de datos de VirusTotal. Muestra automáticamente: ficheros que contactan un dominio, dominios que resuelven a una IP, ficheros que comparten imphash o rich header.

Limitación: solo muestra datos que VirusTotal tiene. Si un sample no fue subido a VT, no aparece.

Building activity clusters

El proceso de construir un cluster sigue un patrón iterativo:

Paso 1: Seed IOC

Empieza con un IOC de alta confianza. Puede venir de un incidente, un feed CTI, un report de otro vendor o una detección del SOC.

Paso 2: Pivoting en múltiples dimensiones

Desde el seed IOC, pivotar en todas las dimensiones disponibles:

Seed: hash SHA256 (malware sample)
  │
  ├─ DNS pasivo → dominios C2 contactados
  │     ├─ Reverse DNS → otros dominios en mismas IPs
  │     └─ WHOIS → registrador, email, nombre
  │
  ├─ Sandbox reports → TTPs observados, artefactos de red
  │     ├─ User-agents custom → buscar en otros reports
  │     └─ Mutex names → buscar en MalwareBazaar
  │
  ├─ SSDEEP/imphash → samples similares
  │     └─ Esos samples → nuevos C2s → más infraestructura
  │
  └─ VT relations → ficheros padres/hijos, URLs de distribución

Paso 3: Evaluar confianza de cada relación

No todas las relaciones tienen el mismo peso:

RelaciónConfianza
Mismo certificado TLS customAlta
Mismo imphash + mismo C2Alta
Mismo ASN + mismo /24Media
Mismo registrador de dominioBaja (millones de dominios por registrador)
Mismo hosting provider genéricoBaja
Mismo SSDEEP match > 80%Alta
Mismo horario operacionalBaja (indicador de apoyo, no determinante)

Paso 4: Documentar el cluster

Cada cluster necesita:

  • Identificador único (interno)
  • Lista de IOCs con confianza y fuente
  • Relaciones documentadas (qué conecta cada IOC con el cluster)
  • TTPs observados (mapeados a ATT&CK)
  • Timeline de actividad
  • Victimología conocida
  • Hipótesis de atribución con nivel de confianza

Convenciones de naming

La industria CTI no tiene un naming system unificado. Cada vendor asigna nombres distintos al mismo actor, generando confusión.

Microsoft: taxonomía meteorológica (2023+)

Formato: [Nación/Motivación] + [Elemento meteorológico]

PrefijoPaís/Motivación
MidnightRusia
ForestRusia
AquaRusia
CharcoalIrán
MangoIrán
CitrineCorea del Norte
JadeChina
SilkChina
Storm-Clusters no atribuidos

Ejemplo: Midnight Blizzard = APT29 (SVR, Rusia). Forest Blizzard = APT28 (GRU, Rusia).

CrowdStrike: animales por país

AnimalPaís
BearRusia
KittenIrán
PandaChina
ChollimaCorea del Norte
SpiderCriminal (e-crime)
JackalHacktivista

Ejemplo: Fancy Bear = APT28. Cozy Bear = APT29. Charming Kitten = APT35.

Mandiant/Google: UNC y APT

  • UNC + número: Cluster no atribuido (uncategorized). Ejemplo: UNC3944 (Scattered Spider).
  • APT + número: Atribución confirmada a un actor state-sponsored. Ejemplo: APT28, APT29, APT41.
  • FIN + número: Actor con motivación financiera. Ejemplo: FIN7, FIN11.

Tabla de equivalencias

MITRECrowdStrikeMicrosoftMandiant
G0007Fancy BearForest BlizzardAPT28
G0016Cozy BearMidnight BlizzardAPT29
G0032Labyrinth ChollimaCitrine SleetLazarus (parcial)
G0096Wicked PandaBrass TyphoonAPT41
G0046Carbon SpiderSangria TempestFIN7

MITRE mantiene una tabla de equivalencias en cada página de actor (Aliases/Associated Groups). MISP galaxies también mantienen mappings entre naming systems.

Timeline analysis

La dimensión temporal es clave para entender campañas:

Timeline de infraestructura

2026-01-15  dominio-a.com registrado (Namecheap, privacy)
2026-01-18  dominio-a.com apunta a 185.xx.xx.10
2026-02-01  dominio-b.net registrado (mismo registrador)
2026-02-03  dominio-b.net apunta a 185.xx.xx.11 (mismo /24)
2026-02-10  Primer sample detectado contactando dominio-a.com
2026-02-15  dominio-c.org registrado, apunta a 185.xx.xx.10 (misma IP que A)
2026-03-01  Incidente en víctima 1 (sector energía, España)
2026-03-05  Incidente en víctima 2 (sector energía, Portugal)
2026-03-10  dominio-a.com cambia a nueva IP (rotación de infraestructura)

Esta timeline muestra: registro de infraestructura semanas antes de la campaña (preparación), reuso de IPs entre dominios (linking), rotación posterior al primer incidente (evasión).

Patrones temporales

  • Preparación: Infraestructura registrada semanas o meses antes del primer ataque
  • Burst: Múltiples víctimas en un periodo corto (campña masiva)
  • Rotación: Cambio de IPs/dominios después de ser quemados
  • Estacionalidad: Algunos actores operan en ciclos (campañas Q4, post-vacaciones)
  • Horario operacional: Actividad concentrada en horario laboral de una zona horaria

Campaign tracking en la práctica

Caso: Campaña de infostealer contra sector financiero

  1. Detección inicial: SOC detecta Lumma Stealer en un endpoint. Hash conocido, C2 en dominio DGA.

  2. Pivoting de infraestructura: El C2 resuelve a IP en AS174xx. Reverse DNS muestra 4 dominios más en esa IP. WHOIS revela registro el mismo día con el mismo privacy service.

  3. Pivoting de código: SSDEEP del sample matchea con 3 samples más en MalwareBazaar. Todos son variantes de Lumma con el mismo builder (mismo imphash, misma config de C2 con path /gate.php).

  4. Cluster emergente: 5 dominios, 2 IPs, 4 samples de Lumma, todos con el path /gate.php y el mismo certificado self-signed. Esto es un cluster.

  5. Victimología: Consultando con ISACs del sector financiero, 3 organizaciones más reportan IOCs del mismo cluster. Todas son bancos medianos en Europa occidental.

  6. Documentación: Cluster documentado con timeline, IOCs, TTPs, victimología. Se asigna identificador interno (CLUSTER-2026-042). No hay atribución a actor conocido. Se clasifica como "Campaña de distribución de Lumma Stealer contra sector financiero EU, actor desconocido, motivación financiera".

  7. Sharing: IOCs compartidos vía MISP con TLP:AMBER a ISACs del sector financiero. Informe operacional producido para los miembros.

Automatización con grafos

A escala, el tracking manual de campañas no escala. Las bases de datos de grafos permiten almacenar y consultar relaciones entre IOCs, actores, campañas y víctimas de forma eficiente.

Schema de grafo CTI

(IOC) ──[resuelve_a]──► (IP)
(IOC) ──[contacta]──► (Dominio)
(IOC) ──[descargado_de]──► (URL)
(Sample) ──[similar_a]──► (Sample)     // SSDEEP/imphash
(Sample) ──[usa_c2]──► (Dominio)
(Dominio) ──[resuelve_a]──► (IP)
(Dominio) ──[registrado_con]──► (Registrador)
(Dominio) ──[comparte_cert]──► (Dominio)
(IP) ──[en_asn]──► (ASN)
(Cluster) ──[contiene]──► (IOC)
(Cluster) ──[atribuido_a]──► (Actor)
(Cluster) ──[usa_ttp]──► (Técnica ATT&CK)
(Campaña) ──[parte_de]──► (Cluster)
(Campaña) ──[objetivo]──► (Sector)

Consultas de grafo

Con Neo4j (Cypher) o equivalente:

// Encontrar todos los IOCs a 2 saltos de un IOC conocido
MATCH path = (start:IOC {value: "185.xx.xx.xx"})-[*1..2]-(related:IOC)
RETURN path

// Encontrar clusters que comparten infraestructura
MATCH (c1:Cluster)-[:contiene]->(ioc:IOC)-[:resuelve_a]->(ip:IP)<-[:resuelve_a]-(ioc2:IOC)<-[:contiene]-(c2:Cluster)
WHERE c1 <> c2
RETURN c1, c2, ip, count(*)

// Timeline de actividad de un cluster
MATCH (c:Cluster {id: "CLUSTER-2026-042"})-[:contiene]->(ioc:IOC)
RETURN ioc.type, ioc.value, ioc.first_seen, ioc.last_seen
ORDER BY ioc.first_seen

Herramientas de grafo para CTI

HerramientaTipoUso CTI
Neo4jBase de datos de grafosAlmacenar y consultar relaciones IOC
JanusGraphBase de datos de grafos distribuidaEscala masiva
OpenCTIPlataforma CTI con grafo integradoKnowledge graph completo
MISPPlataforma de sharing con correlaciónCorrelación automática de eventos
MalwareIntel GraphKnowledge graph propioVisualización de relaciones malware/actor/TTP
MaltegoLink analysis visualPivoting interactivo

Automatización del clustering

El pipeline automatizado de clustering:

  1. Ingesta: Nuevos IOCs entran desde feeds (MalwareBazaar, ThreatFox, OTX)
  2. Enriquecimiento: DNS pasivo, WHOIS, sandbox, similitud de código
  3. Correlación: Buscar relaciones con IOCs existentes en el grafo
  4. Clustering automático: Algoritmos de community detection (Louvain, Label Propagation) identifican clusters de nodos densamente conectados
  5. Alerta: Si un nuevo IOC se conecta a un cluster existente, notificar al analista
  6. Revisión humana: Analista valida el cluster, ajusta atribución, produce informe

La automatización maneja el volumen (miles de IOCs diarios). El analista aporta el juicio (¿este cluster es una campaña? ¿de quién?).

Errores frecuentes en campaign tracking

Single-source attribution

Atribuir un cluster a un actor basándose en una sola dimensión (ej: "usan Cobalt Strike, por tanto es APT29"). Cobalt Strike lo usan cientos de actores. La atribución requiere múltiples dimensiones convergentes.

Confundir herramientas con actores

Que dos campañas usen el mismo malware no significa que sean del mismo actor. Las herramientas se venden, se comparten, se filtran y se copian. Emotet fue usado como loader por múltiples actores no relacionados.

Ignorar false flags

Actores sofisticados plantan indicadores falsos para atribuir sus operaciones a otros (language strings en ruso en malware chino, reutilización de infraestructura conocida de otro actor). El caso de Olympic Destroyer (2018) es el ejemplo clásico de false flag.

Over-clustering

Conectar IOCs con relaciones débiles (mismo hosting provider genérico, mismo TLD) genera clusters falsos. Cada relación debe evaluarse por su fuerza discriminatoria.

Recursos

Preguntas frecuentes

Artículos relacionados

Este contenido tiene fines exclusivamente educativos y de investigación en ciberseguridad defensiva. No se proporcionan binarios maliciosos ni payloads ejecutables. El uso indebido de esta información es responsabilidad exclusiva del usuario. Leer disclaimer completo.