De IOC a Detección: Workflow Completo para Operacionalizar Inteligencia

La inteligencia que no se convierte en detección es solo ruido

Cada semana llegan cientos de IOCs a tu SOC. Feeds de abuse.ch, OTX, MISP, CISA KEV, informes de vendors. Hashes, IPs, dominios. Los metes en el SIEM, bloqueas algunos en el firewall, y pasas al siguiente ticket. Pero la pregunta incómoda persiste: ¿cuántos de esos IOCs se convierten en detecciones que sobreviven al primer cambio del atacante?

El gap entre "recibir inteligencia" y "tener detecciones que funcionen" es donde fracasan la mayoría de equipos de seguridad. No es un problema de herramientas. Es un problema de proceso.

Este artículo presenta un workflow completo de 7 pasos para convertir cualquier IOC en una detección accionable, usando la Pyramid of Pain como brújula para decidir dónde invertir tu esfuerzo.

El gap entre inteligencia y detección

La mayoría de equipos SOC operan en modo reactivo con IOCs. El flujo típico:

Feed IOC llega → copiar hash/IP → pegar en SIEM watchlist → esperar match → nunca llega

Este flujo tiene tres problemas fundamentales:

1. Los IOCs caducan rápido. Un hash SHA256 dura minutos como indicador útil. El atacante recompila y genera uno nuevo.
2. Sin contexto no hay priorización. Un IOC sin saber qué familia, qué actor, qué TTP, es un dato sin valor operativo.
3. Las watchlists no escalan. 50.000 hashes en una watchlist degradan rendimiento y generan falsa sensación de cobertura.

El objetivo no es acumular IOCs. Es convertir inteligencia en detecciones que funcionen cuando el atacante cambie sus indicadores pero mantenga su comportamiento.

La Pyramid of Pain como brújula

La Pyramid of Pain de David Bianco (2013) no es solo un modelo teórico. Es una herramienta de decisión para detection engineering. Cada nivel de la pirámide implica un enfoque de detección diferente:

NIVEL          │ INDICADOR               │ ENFOQUE DE DETECCIÓN
───────────────┼─────────────────────────┼──────────────────────────────────
6. TTPs        │ Técnicas ATT&CK         │ Sigma behavioral rules
5. Tools       │ Cobalt Strike, Mimikatz │ YARA + Sigma combinados
4. Artifacts   │ Named pipes, mutex, UA  │ Sigma con campos específicos
3. Domains     │ C2 domains              │ DNS logs + Suricata
2. IPs         │ C2 IPs                  │ Firewall/IDS watchlist
1. Hashes      │ SHA256, MD5             │ EDR hash blocklist

La regla de oro: invierte proporcionalmente al nivel de dolor. Si el 80% de tu tiempo va a bloquear hashes (nivel 1, dolor trivial), estás optimizando para algo que el atacante cambia en 30 segundos. Si inviertes en detectar TTPs (nivel 6, dolor extremo), el atacante necesita semanas para cambiar su operativa.

Esto no significa abandonar los niveles bajos. Un hash blocklist sigue siendo útil para detección automatizada inmediata. Pero tu inversión principal debe ir hacia la cima de la pirámide.

Workflow completo: de IOC a detección en 7 pasos

┌──────────────────────────────────────────────────────────────────────┐
│                    WORKFLOW IOC → DETECCIÓN                         │
│                                                                      │
│  [1] Recibir      [2] Clasificar    [3] Enriquecer                  │
│  IOC + contexto → en Pyramid  →    con fuentes  →                  │
│                    of Pain          adicionales                      │
│                                                                      │
│  [4] Decidir      [5] Escribir      [6] Testear                    │
│  tipo de       →  la regla      →   con datos   →                  │
│  detección        (Sigma/YARA)      reales                          │
│                                                                      │
│  [7] Deploy + tuning + feedback loop                                │
└──────────────────────────────────────────────────────────────────────┘

Paso 1: Recibir IOC con contexto

Un IOC sin contexto es un dato. Un IOC con contexto es inteligencia. Antes de invertir tiempo en crear una detección, verifica estos atributos:

Atributo	Pregunta	Ejemplo
Fuente	¿De dónde viene? ¿Es fiable?	MalwareBazaar (alta), tweet aleatorio (baja)
TLP	¿Puedo compartirlo y operarlo?	TLP:GREEN (compartible), TLP:RED (restringido)
Confianza	¿Cuánta certeza hay?	90% (verificado en sandbox) vs 30% (solo mencionado)
Familia	¿Qué malware es?	Emotet, Cobalt Strike, desconocido
Campaña	¿Es parte de algo mayor?	Campaña Emotet Epoch4 Q1 2026
Relevancia	¿Afecta a mi sector/región?	Sector financiero EU: sí. Sector agrícola APAC: no

Si el IOC llega sin familia, sin contexto y con confianza baja, la respuesta correcta puede ser no crear detección. No todo IOC merece tu tiempo de ingeniería.

Paso 2: Clasificar en Pyramid of Pain

Identifica en qué nivel de la pirámide cae el IOC recibido. Esto determina dos cosas: la vida útil esperada de la detección y el enfoque que vas a tomar.

IOC recibido	Nivel Pyramid	Vida útil	Acción
SHA256: a1b2c3...	1 (Hash)	Minutos	Blocklist automatizada, pero no pares aquí
45.33.32.156	2 (IP)	Horas a días	Watchlist, pero busca qué hay detrás
evil-update.com	3 (Domain)	Días	DNS monitoring + buscar patrón DGA
\pipe\MSSE-*-server	4 (Artifact)	Semanas	Sigma rule para named pipe
Cobalt Strike beacon	5 (Tool)	Meses	YARA + Sigma + Suricata combinados
T1059.001 PowerShell	6 (TTP)	Meses a años	Sigma behavioral rule

La clave: cada IOC de nivel bajo contiene pistas hacia niveles superiores. Un hash de Emotet (nivel 1) te lleva a la cadena de infección completa (nivel 6): macro Office que lanza PowerShell que descarga DLL que se inyecta en un proceso legítimo. La detección que vale la pena es la behavioral, no el hash.

Paso 3: Enriquecer

El enriquecimiento transforma un IOC aislado en inteligencia con contexto operativo. Fuentes clave:

Fuente	Qué aporta	Ejemplo
VirusTotal	Detecciones AV, relaciones, comportamiento sandbox	Hash → familia, IPs contactadas, ficheros creados
MalwareBazaar	Tags, familia, signature, first/last seen	Hash → "Emotet", tags: epoch4, dropper
OTX AlienVault	Pulsos con IOCs relacionados, TTPs, actores	IP → pulso "Emotet Q1 2026" con 200 IOCs más
MITRE ATT&CK	Técnicas documentadas por familia	Emotet → T1566.001, T1059.001, T1055.001, T1071.001
ANY.RUN	Comportamiento dinámico paso a paso	Hash → proceso tree, network, file drops, registry
MalwareIntel	Familia completa con TTPs, actores, artefactos	Contexto consolidado con confianza y fuentes

El resultado del enriquecimiento es un perfil de la amenaza, no solo un IOC individual. Ese perfil es lo que alimenta la detección.

Ejemplo de enriquecimiento de un hash Emotet:

IOC original:     SHA256: 7a5b3e... (hash de documento .xlsm)
Familia:          Emotet (Epoch4) ← MalwareBazaar tag
Actor:            TA542 / Mummy Spider ← MITRE ATT&CK
Cadena:           .xlsm → macro VBA → cmd.exe → PowerShell → DLL download
                  → regsvr32.exe → C2 HTTPS
TTPs ATT&CK:     T1566.001 (Spearphishing Attachment)
                  T1059.001 (PowerShell)
                  T1218.010 (Regsvr32)
                  T1071.001 (Web Protocols)
                  T1055.001 (DLL Injection)
Artefactos:       Registry: HKCU\Software\Microsoft\Windows\CurrentVersion\Run
                  Named pipe: no (Emotet no usa named pipes)
                  User-Agent: variado (copia de navegadores legítimos)
C2 conocidos:     45.33.32.156:443, 185.7.214.12:8080

Con este perfil, puedes crear detecciones en los niveles 4, 5 y 6 de la pirámide. Sin el enriquecimiento, solo tendrías un hash de nivel 1.

Paso 4: Decidir tipo de detección

Cada tipo de indicador tiene una herramienta de detección óptima:

Qué quiero detectar	Dónde buscar	Herramienta	Formato
Hash de archivo malicioso	Endpoint (disco, memoria)	EDR / YARA	Hash blocklist / YARA rule
IP/dominio de C2	Tráfico de red, DNS logs	Firewall, IDS, SIEM	Suricata rule, Sigma (DNS)
Named pipe, mutex, registry	Logs de host (Sysmon)	SIEM	Sigma rule
Comportamiento de proceso	Logs de host (Sysmon, EDR)	SIEM	Sigma rule
Patrón en fichero (strings, estructura)	Endpoint (disco, memoria)	YARA	YARA rule
Patrón de red (JA3, HTTP, DNS)	Tráfico de red	IDS	Suricata rule
TTP completo (cadena de ejecución)	Logs + red combinados	SIEM + correlación	Sigma rules (múltiples)

Para la mayoría de los casos, la combinación ganadora es:

• Sigma para detectar comportamiento en logs (Sysmon, Windows Security, proxy)
• YARA para detectar patrones en ficheros (muestras en disco, memoria, tráfico)
• Suricata para detectar patrones en red (JA3 fingerprints, HTTP headers, DNS)

Paso 5: Escribir la regla

Aquí es donde la ingeniería reemplaza a la intuición. Vamos con dos casos prácticos completos.

Caso práctico A: Emotet (de hash a detección behavioral)

IOC inicial: SHA256: 7a5b3e... (documento .xlsm con macro Emotet)

Después del enriquecimiento (Paso 3), sabemos que la cadena de ejecución de Emotet Epoch4 sigue un patrón consistente: documento Office con macro que lanza PowerShell para descargar un payload DLL, que se ejecuta con regsvr32.

Detección nivel 1 (hash, vida útil: minutos):

# No recomendado como detección principal
# Solo útil para detección inmediata de samples conocidos
- hash: 7a5b3e...
  action: block

Detección nivel 4 (artefacto behavioral, vida útil: meses):

title: Emotet - Office Application Spawning Scripting Engine
id: e4a74a6c-5f3b-4d8a-9c2e-1b7f8d3a5c9e
status: stable
description: |
    Detecta procesos de Microsoft Office (Word, Excel) que lanzan
    intérpretes de scripting (PowerShell, cmd, wscript, cscript).
    Patrón consistente de Emotet Epoch4 y otros loaders que usan
    macros como vector de entrada.
references:
    - https://attack.mitre.org/techniques/T1566/001/
    - https://attack.mitre.org/techniques/T1059/001/
author: MalwareIntel Research
date: 2026/06/05
tags:
    - attack.execution
    - attack.t1059.001
    - attack.initial_access
    - attack.t1566.001
logsource:
    category: process_creation
    product: windows
detection:
    selection_parent:
        ParentImage|endswith:
            - '\WINWORD.EXE'
            - '\EXCEL.EXE'
            - '\POWERPNT.EXE'
    selection_child:
        Image|endswith:
            - '\powershell.exe'
            - '\pwsh.exe'
            - '\cmd.exe'
            - '\wscript.exe'
            - '\cscript.exe'
            - '\mshta.exe'
    condition: selection_parent and selection_child
falsepositives:
    - Macros legítimas que lanzan scripts (documentar excepciones)
    - Complementos de Office que usan COM automation
level: high

Esta regla Sigma no depende del hash. Detecta el comportamiento: Office lanzando un intérprete de scripting. Funciona contra cualquier variante de Emotet (y contra otros loaders como QBot, IcedID, Pikabot) que usen macros como vector. El atacante tendría que cambiar su cadena de ejecución completa para evadirla.

Detección nivel 6 (TTP, regsvr32 como proxy de ejecución):

title: Emotet - Regsvr32 Executing DLL from Suspicious Location
id: b2d4c8e1-7f9a-4b3c-8d5e-2a1f6c9b7d4e
status: stable
description: |
    Detecta regsvr32.exe ejecutando DLLs desde ubicaciones atípicas
    (carpetas de usuario, temp, AppData). Patrón usado por Emotet
    para ejecutar su payload DLL evitando detección directa.
references:
    - https://attack.mitre.org/techniques/T1218/010/
author: MalwareIntel Research
date: 2026/06/05
tags:
    - attack.defense_evasion
    - attack.t1218.010
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        Image|endswith: '\regsvr32.exe'
        CommandLine|contains:
            - '\Users\'
            - '\Temp\'
            - '\AppData\'
            - '\ProgramData\'
    filter_legitimate:
        CommandLine|contains:
            - '\Microsoft\Teams\'
            - '\Microsoft\OneDrive\'
    condition: selection and not filter_legitimate
falsepositives:
    - Instaladores legítimos que registran DLLs en AppData
level: medium

Caso práctico B: Cobalt Strike (de IP a detección multicapa)

IOC inicial: IP: 45.33.32.156:443 (C2 de Cobalt Strike beacon)

El enriquecimiento revela: beacon HTTPS, JA3 fingerprint conocido, named pipes por defecto, sleep con jitter 40%.

Capa 1: YARA para detectar el beacon en memoria

rule CobaltStrike_Beacon_Strings
{
    meta:
        description = "Detecta strings características de Cobalt Strike Beacon en memoria"
        author = "MalwareIntel Research"
        date = "2026-06-05"
        reference = "https://attack.mitre.org/software/S0154/"
        tlp = "WHITE"
        score = 75

    strings:
        $s1 = "%s as %s\\%s: %d" ascii
        $s2 = "beacon.dll" ascii nocase
        $s3 = "beacon.x64.dll" ascii nocase
        $s4 = "%s (admin)" ascii
        $s5 = "powershell -nop -exec bypass" ascii nocase
        $s6 = "IEX (New-Object Net.Webclient).DownloadString" ascii nocase

        $cfg1 = { 00 01 00 01 00 02 ?? ?? 00 02 00 01 00 02 ?? ?? }
        $cfg2 = { 00 01 00 02 00 04 ?? ?? ?? ?? 00 02 00 01 00 02 }

    condition:
        (3 of ($s*)) or (1 of ($cfg*) and 1 of ($s*))
}

Capa 2: Sigma para named pipe por defecto

title: Cobalt Strike - Default Named Pipe Pattern
id: d3f5a7c9-1b2e-4d6f-8a0c-3e5b7d9f1a2c
status: stable
description: |
    Detecta la creación de named pipes con el patrón por defecto
    de Cobalt Strike (MSSE-*-server). Indicador de nivel 4
    (Network/Host Artifact) en la Pyramid of Pain.
references:
    - https://attack.mitre.org/techniques/T1570/
author: MalwareIntel Research
date: 2026/06/05
tags:
    - attack.lateral_movement
    - attack.t1570
logsource:
    category: pipe_created
    product: windows
detection:
    selection:
        PipeName|startswith: '\MSSE-'
        PipeName|endswith: '-server'
    condition: selection
falsepositives:
    - Ninguno conocido (patrón exclusivo de Cobalt Strike default config)
level: critical

Capa 3: Suricata para JA3 fingerprint

alert tls $HOME_NET any -> $EXTERNAL_NET any ( \
    msg:"MALWAREINTEL Cobalt Strike Beacon JA3 Fingerprint"; \
    ja3.hash; content:"72a589da586844d7f0818ce684948eea"; \
    sid:2026001; rev:1; \
    metadata:attack_target Client_Endpoint, \
    deployment Perimeter, \
    signature_severity Major, \
    created_at 2026_06_05, \
    mitre_attack_tactic Command_And_Control, \
    mitre_attack_technique T1071; \
)

Con tres capas (YARA en endpoint, Sigma en logs, Suricata en red), el atacante necesita cambiar simultáneamente el beacon en memoria, la configuración de named pipes y el perfil TLS. Eso es dolor de nivel 5 (Tools): requiere reconfigurar completamente el Malleable C2 profile o migrar a otra herramienta.

Paso 6: Testing

Una detección sin testear es una detección que no existe. Dos métodos principales:

Atomic Red Team: ejecutar la técnica ATT&CK de forma controlada y verificar que la regla dispara.

# Testear T1059.001 (PowerShell execution desde Office)
# Atomic Red Team test para la regla Sigma de Emotet
Invoke-AtomicTest T1059.001 -TestNumbers 1

# Verificar en SIEM que la alerta se genera
# Buscar: EventID 1, ParentImage *WINWORD.EXE, Image *powershell.exe

Replay de logs: usar logs reales (o generados con herramientas como Chainsaw o Hayabusa) para verificar que la regla matchea contra eventos conocidos.

# Testear regla Sigma contra logs exportados
sigmac -t splunk regla_emotet_macro.yml | \
  splunk search -index test_logs

# Contar matches esperados vs reales
# Resultado esperado: 3 matches en 500 eventos de test
# Si 0 matches: la regla tiene un error o el log no tiene el campo

Cada regla debe tener al menos:

Test	Objetivo
True Positive	La regla dispara contra la amenaza conocida
True Negative	La regla NO dispara contra actividad legítima
False Positive Rate	Ejecutar contra 1 semana de logs reales, contar FP
Variantes	Probar con al menos 2 variantes del malware/técnica

Paso 7: Deploy y tuning

El deploy no es el final. Es el inicio del ciclo de feedback.

Semana 1 (modo observación):

• Deploy la regla en modo "alert only" (no bloquea)
• Monitorizar volumen de alertas y false positives
• Documentar cada FP con el proceso/aplicación que lo genera

Semana 2 (tuning):

• Añadir exclusiones para FP legítimos verificados
• Ajustar nivel de severidad si el volumen es excesivo
• Validar que los true positives siguen funcionando tras exclusiones

Semana 3+ (producción):

• Pasar a modo "alert + block" si aplica
• Integrar en playbook de respuesta del SOC
• Revisión trimestral: ¿la regla sigue siendo relevante? ¿ha cambiado el TTP?

Gestión de falsos positivos (el problema real):

Tipo de FP	Acción
FP por software legítimo conocido	Añadir exclusión permanente con comentario
FP por software interno custom	Añadir exclusión con revisión en 90 días
FP que indica regla demasiado amplia	Refinar la lógica de detección
FP frecuente que ahoga alertas reales	Separar en regla informativa (bajo) vs alta

Detection Packages: bundles por familia

Un concepto que lleva la operacionalización al siguiente nivel: en lugar de reglas individuales, crear paquetes de detección por familia de malware. Cada paquete incluye:

Detection Package: Emotet (Epoch4)
├── sigma/
│   ├── emotet_macro_spawn_scripting.yml      (T1059.001)
│   ├── emotet_regsvr32_suspicious_dll.yml    (T1218.010)
│   ├── emotet_scheduled_task_persistence.yml  (T1053.005)
│   └── emotet_c2_http_pattern.yml            (T1071.001)
├── yara/
│   ├── emotet_packed_dll.yar
│   └── emotet_unpacked_strings.yar
├── suricata/
│   └── emotet_c2_traffic.rules
├── iocs/
│   ├── hashes.csv
│   ├── c2_ips.csv
│   └── c2_domains.csv
├── tests/
│   ├── atomic_red_team_tests.md
│   └── sample_logs/
├── README.md                                  (cadena de infección, TTPs, fuentes)
└── CHANGELOG.md                               (versiones del paquete)

Este modelo permite actualizar la detección como un producto versionado. Cuando aparece una nueva variante de Emotet, actualizas el paquete en lugar de crear reglas sueltas que nadie mantiene. MalwareIntel ofrece este tipo de paquetes como parte de su catálogo de productos CTI.

Métricas del workflow

Medir el workflow es tan importante como ejecutarlo. Métricas clave:

Métrica	Qué mide	Objetivo
Time to Detect (TTD)	Tiempo desde publicación del IOC hasta regla en producción	< 24h para IOCs críticos
Pyramid Coverage	% de detecciones en cada nivel de la pirámide	> 40% en niveles 4-6
Detection Coverage ATT&CK	Técnicas con al menos 1 detección	> 60% de técnicas relevantes
False Positive Rate	FP por regla por semana	< 5 FP/semana por regla
Detection Packages	Familias con paquete completo de detección	1 paquete/mes mínimo
Rule Freshness	% de reglas revisadas en últimos 90 días	> 80%

Un dashboard con estas métricas muestra la salud real de tu programa de detection engineering. No cuántos IOCs tienes, sino cuántas detecciones accionables y mantenidas.

Recursos y referencias

Recurso	Uso
Pyramid of Pain (David Bianco)	Modelo original para clasificar IOCs por impacto
SigmaHQ	Repositorio de reglas Sigma de la comunidad
YARA (VirusTotal)	Documentación oficial de YARA
Atomic Red Team	Tests por técnica ATT&CK para validar detecciones
MITRE ATT&CK Navigator	Visualizar cobertura de detección sobre ATT&CK
MalwareIntel	Plataforma CTI con familias, IOCs y mapeo ATT&CK
Uncoder.IO	Convertir reglas Sigma a formato de tu SIEM
Chainsaw	Hunting rápido en logs EVTX con reglas Sigma

El workflow presentado no es una tarea puntual. Es un ciclo continuo: cada IOC es una oportunidad de subir un nivel en la pirámide. Cada detección behavioral que creas reduce la dependencia de IOCs atómicos que caducan. Y cada paquete de detección que mantienes multiplica el valor de tu programa CTI.