Automatización de Recolección CTI: n8n, MISP y TheHive Cortex

La recolección manual de inteligencia no escala: automatizar es la diferencia entre un equipo reactivo y uno que anticipa amenazas

Un analista CTI medio revisa entre 5 y 15 fuentes de inteligencia cada día. Feeds RSS, APIs de amenazas, informes PDF, repositorios GitHub, canales de Telegram. Sin automatización, la recolección consume entre el 40% y el 60% del tiempo del analista, dejando poco margen para el análisis real.

La automatización de la recolección no es un lujo. Es el prerequisito para que el ciclo de inteligencia funcione. Sin ella, los IOCs llegan tarde, la deduplicación es manual y la correlación entre fuentes no ocurre.

Por qué automatizar la recolección

Tres razones concretas:

Velocidad. Un workflow automatizado puede ingestar, normalizar y alertar sobre un IOC nuevo en menos de 60 segundos. Un analista manual tarda entre 5 y 30 minutos por fuente.

Cobertura. Automatizar permite cubrir 20, 40 o 100 feeds simultáneamente. Un analista puede revisar 10 al día con atención real.

Consistencia. La normalización automática elimina variaciones de formato entre fuentes. Un hash SHA256 llega siempre en el mismo formato, independientemente de si viene de MalwareBazaar, ThreatFox o un feed MISP.

n8n para workflows CTI

n8n es una plataforma de automatización de workflows con un editor visual que permite conectar APIs, transformar datos y ejecutar lógica condicional sin escribir código complejo. Para CTI, n8n funciona como el pegamento entre fuentes de inteligencia y plataformas de gestión.

Arquitectura básica de un workflow CTI en n8n

[Trigger: Cron cada 15 min]
    │
    ├─→ [HTTP Request: MalwareBazaar API]
    │       │
    │       └─→ [Function: Normalizar IOCs]
    │               │
    │               ├─→ [IF: ¿IOC nuevo?]
    │               │       │
    │               │       ├─ SÍ → [MISP: Crear evento]
    │               │       │       │
    │               │       │       └─→ [Slack: Alertar al equipo]
    │               │       │
    │               │       └─ NO → [Fin]
    │
    ├─→ [HTTP Request: ThreatFox API]
    │       │
    │       └─→ [Misma lógica de normalización + dedup]
    │
    └─→ [HTTP Request: CISA KEV JSON]
            │
            └─→ [Misma lógica]

Nodos clave para CTI en n8n

Nodo	Uso CTI
HTTP Request	Consultar APIs de feeds (MalwareBazaar, OTX, ThreatFox, URLhaus)
Cron	Programar ejecución periódica (cada 5 min, cada hora, diaria)
Function	Normalizar formatos, extraer campos, validar IOCs
IF / Switch	Filtrar por tipo de IOC, severidad, TLP
MISP	Crear eventos, añadir atributos, buscar duplicados
Slack / Telegram	Notificar al equipo sobre IOCs críticos
Postgres / MySQL	Almacenar IOCs en base de datos local
Webhook	Recibir datos push de fuentes externas

Ejemplo: workflow de ingesta de MalwareBazaar

Trigger: Cron cada 30 minutos
  → HTTP Request: POST https://mb-api.abuse.ch/api/v1/
    Body: { "query": "get_recent", "selector": "time" }
  → Function: Para cada sample:
      - Extraer sha256_hash, md5_hash, sha1_hash
      - Extraer signature (familia de malware)
      - Extraer tags, file_type, first_seen
      - Normalizar a formato interno { ioc_type, value, family, source }
  → IF: ¿Existe en DB local?
      - NO → Insertar en DB + Crear evento MISP + Notificar Slack
      - SÍ → Actualizar last_seen + Fin

Buenas prácticas n8n para CTI

1. Rate limiting. Respetar los límites de las APIs. MalwareBazaar permite 10 requests por minuto. Configura delays entre llamadas.
2. Error handling. Cada nodo HTTP debe tener un flujo de error que registre el fallo sin detener el workflow completo.
3. Credentials. Usar el vault de credenciales de n8n, nunca hardcodear API keys en los nodos.
4. Idempotencia. El workflow debe poder ejecutarse dos veces seguidas sin crear duplicados.
5. Monitorización. Configurar alertas cuando un workflow falla tres veces consecutivas.

MISP: feeds y sincronización

MISP (Malware Information Sharing Platform) es la plataforma de referencia para compartir y almacenar inteligencia de amenazas en formato estructurado. Su sistema de feeds es nativo y potente.

Tipos de feeds en MISP

Tipo	Descripción	Ejemplo
MISP Feed	Feed nativo en formato MISP JSON	CIRCL OSINT Feed
Freetext Feed	Texto plano con IOCs (IPs, hashes, dominios)	Blocklists públicas
CSV Feed	Archivo CSV con columnas de IOCs	Feodo Tracker CSV
TAXII Feed	Protocolo STIX/TAXII 2.1	MITRE ATT&CK TAXII

Configuración de sincronización

MISP permite dos modos de sincronización entre instancias:

Pull. Tu instancia MISP descarga eventos de otra instancia. Configuras la URL del servidor remoto, la API key y los filtros (por organización, tags, TLP).

Push. Tu instancia envía eventos a otra instancia cuando se crean o actualizan. Requiere que la instancia destino acepte tu organización.

Flujo de sincronización típico

MISP Comunidad (CIRCL, FIRST)
    │
    └─→ [Pull: eventos con tag "malware" + TLP:GREEN]
            │
            ├─→ Correlación automática
            │   (MISP busca IOCs coincidentes entre eventos)
            │
            ├─→ Taxonomías y galaxias
            │   (ATT&CK, threat-actor, malware-type)
            │
            └─→ Warninglists
                (filtra IOCs contra listas de falsos positivos:
                 IPs de CDN, dominios de Microsoft, hashes de Windows)

Warninglists: reducir falsos positivos

MISP incluye warninglists que filtran IOCs conocidos como benignos:

• IPs de proveedores cloud (AWS, Azure, GCP, Cloudflare)
• Dominios de servicios legítimos (Microsoft, Google, Apple)
• Hashes de archivos del sistema operativo
• Rangos de IP de universidades y CERTs

Activar las warninglists relevantes antes de ingestar feeds externos reduce el ruido entre un 15% y un 30%.

TheHive + Cortex: enriquecimiento automático

TheHive es la plataforma de respuesta a incidentes que complementa a MISP. Mientras MISP almacena y comparte IOCs, TheHive gestiona casos de incidentes y, a través de Cortex, ejecuta enriquecimiento automatizado.

Cortex analyzers para CTI

Cortex ejecuta "analyzers": módulos que consultan fuentes externas para enriquecer un observable (IOC).

Analyzer	Fuente	Datos que aporta
VirusTotal	VT API	Detecciones AV, comunidad, relaciones
AbuseIPDB	AbuseIPDB	Reports de abuso, ISP, país
OTX	AlienVault	Pulsos asociados, reputación
Shodan	Shodan	Puertos abiertos, servicios, vulnerabilidades
MISP	Instancia local	Eventos correlacionados, atributos
MaxMind	GeoIP	Geolocalización, ASN
PassiveTotal	RiskIQ	DNS pasivo, WHOIS histórico
Yara	Reglas locales	Coincidencias con reglas YARA

Flujo de enriquecimiento automático

IOC detectado (IP sospechosa)
    │
    └─→ TheHive: Crear observable
            │
            └─→ Cortex: Ejecutar analyzers automáticos
                    │
                    ├─→ AbuseIPDB: 47 reports, ISP "BulletProof Hosting"
                    ├─→ Shodan: Puerto 443 abierto, cert self-signed
                    ├─→ VirusTotal: 12/90 detecciones como C2
                    ├─→ MISP: Correlaciona con evento de APT28
                    └─→ MaxMind: País = Moldavia, ASN = AS12345
                            │
                            └─→ TheHive: Observable enriquecido
                                + TLP:AMBER + Severity: HIGH
                                + Tags: [c2, apt28, moldavia]

Responders: acciones automáticas

Cortex también incluye "responders" que ejecutan acciones basadas en el análisis:

• Bloquear IP en el firewall (requiere integración)
• Añadir dominio a blocklist del proxy
• Crear ticket en el sistema de ticketing
• Notificar al equipo via Slack o email
• Actualizar el evento en MISP con los resultados

Construir el pipeline completo: arquitectura

La arquitectura de un pipeline de recolección CTI automatizado combina las tres herramientas:

                    FUENTES EXTERNAS
    ┌─────────────────────────────────────────┐
    │  MalwareBazaar  ThreatFox  URLhaus      │
    │  OTX  MISP Feeds  CISA KEV  Malpedia   │
    │  RSS Blogs  GitHub (SigmaHQ)  Shodan    │
    └──────────────┬──────────────────────────┘
                   │
            ┌──────▼──────┐
            │    n8n      │  ← Orquestador de recolección
            │  (workflows │     Cron cada 5-60 min por feed
            │   + lógica) │     Normalización + dedup inicial
            └──────┬──────┘
                   │
         ┌─────────▼─────────┐
         │      MISP         │  ← Almacén central de inteligencia
         │  (correlación,    │     Taxonomías, galaxias, warninglists
         │   sharing,        │     Sincronización con comunidades
         │   warninglists)   │
         └─────────┬─────────┘
                   │
        ┌──────────▼──────────┐
        │  TheHive + Cortex   │  ← Enriquecimiento + respuesta
        │  (casos, analyzers, │     Analyzers automáticos
        │   responders)       │     Acciones de contención
        └─────────────────────┘

Scheduling y monitorización

Cada feed tiene un ritmo óptimo de recolección:

Feed	Frecuencia recomendada	Justificación
CISA KEV	1x/día	Actualización diaria
MalwareBazaar	Cada 30 min	Alto volumen, IOCs frescos
ThreatFox	Cada 15 min	C2 activos, urgencia alta
Feodo Tracker	Cada 1h	Botnet IPs, volumen medio
URLhaus	Cada 30 min	URLs de distribución, alta rotación
OTX	Cada 2h	Pulsos comunitarios, volumen variable
MISP Feeds	Cada 1h	Depende de la comunidad
RSS/Blogs	Cada 4h	Análisis de largo plazo

Monitoriza con dashboards que muestren:

• IOCs ingestados por hora y por fuente
• Tasa de duplicados (debería estabilizarse en 30-50% para feeds maduros)
• Errores de ingesta por fuente
• Latencia entre publicación del IOC y su ingesta

Normalización: el problema real

El mayor reto de la automatización no es conectar feeds. Es normalizar los datos.

Cada fuente usa formatos diferentes:

Campo	MalwareBazaar	ThreatFox	OTX
Hash	sha256_hash	ioc_value	indicator
Familia	signature	malware	pulse.name
Fecha	first_seen (UTC)	first_seen_utc	created (ISO)
Tipo	file_type	ioc_type	type
Confianza	No incluido	confidence_level	No incluido

Estrategia de normalización

1. Schema interno canónico. Define un formato interno al que todos los feeds se adaptan: { ioc_type, value, family, confidence, source, first_seen, tlp }.
2. Mappers por fuente. Cada feed tiene un mapper dedicado que transforma su formato al schema interno.
3. Validación post-normalización. Cada IOC pasa por validadores de formato: IPv4 válida, hash con longitud correcta, dominio con TLD real.
4. Enriquecimiento de campos vacíos. Si el feed no incluye confianza, asigna un valor por defecto según la fiabilidad histórica de la fuente.

Deduplicación: estrategias

Un IOC puede aparecer en múltiples feeds. La misma IP C2 aparece en ThreatFox, en un pulso de OTX y en un evento MISP. Sin deduplicación, acumulas ruido.

Estrategia 1: Clave única por tipo + valor

CREATE UNIQUE INDEX idx_iocs_type_value ON iocs(ioc_type, value);

Antes de insertar, busca si existe. Si existe, actualiza last_seen y añade la nueva fuente a la lista de sources. No crees un registro nuevo.

Estrategia 2: Ventana temporal

IOCs del mismo tipo, valor y fuente publicados en un intervalo menor a 24 horas se consideran el mismo IOC. Evita duplicados por re-fetching del mismo feed.

Estrategia 3: Merge de metadatos

Cuando un IOC aparece en múltiples fuentes, combina los metadatos:

• Confianza: promedio ponderado por fiabilidad de la fuente
• Tags: unión de todas las tags
• TLP: el más restrictivo (RED > AMBER > GREEN > WHITE)
• Familia: si hay conflicto, prioriza la fuente con mayor fiabilidad

Métricas de deduplicación saludables

Métrica	Valor esperado
Tasa de duplicados por feed	30-50% (feeds maduros)
IOCs únicos por día	500-5.000 (depende de feeds activos)
IOCs sin fuente	0% (siempre debe haber source_id)
IOCs sin tipo	0% (validación obligatoria)

Errores comunes en la automatización CTI

1. Automatizar sin normalizar. Ingestar feeds crudos sin normalización genera una base de datos inútil donde la misma IP aparece en 5 formatos diferentes.
2. No monitorizar los workflows. Un workflow que falla silenciosamente durante 3 días deja un gap de cobertura que ningún analista nota hasta que un incidente lo expone.
3. Confiar ciegamente en la automatización. Los feeds contienen falsos positivos. Las warninglists de MISP y la validación humana periódica son imprescindibles.
4. Volumen sobre calidad. 50 feeds mal normalizados generan más ruido que 15 feeds bien integrados.
5. No versionar los workflows. Exporta los workflows de n8n a JSON y almacénalos en Git. Un cambio accidental puede romper la ingesta sin trazabilidad.

Recursos

• n8n Documentation (workflows de automatización)
• MISP Project (plataforma de compartición CTI)
• TheHive Project (respuesta a incidentes)
• Cortex Analyzers (módulos de enriquecimiento)
• MISP Feeds (directorio de feeds públicos)
• abuse.ch (MalwareBazaar, ThreatFox, URLhaus, Feodo Tracker)
• Sherman Kent, Strategic Intelligence for American World Policy (fundamentos del ciclo de inteligencia)