De IOC a Detección: Crear Reglas YARA, Sigma y Suricata desde Inteligencia

El último paso del ciclo de inteligencia

La inteligencia de amenazas que no se convierte en detección es un documento que ocupa espacio. El ciclo de inteligencia termina cuando la información se traduce en una acción concreta: bloquear, detectar, alertar.

Este artículo cubre la traducción práctica de IOCs y reportes de threat intelligence en tres tipos de reglas de detección:

• YARA: detección en ficheros y memoria.
• Sigma: detección en logs de eventos.
• Suricata: detección en tráfico de red.

Cada tipo cubre una capa diferente del stack de defensa. Un programa CTI maduro produce los tres.

---

Mapeo: tipo de IOC a tipo de detección

No todos los IOCs se traducen al mismo tipo de regla. El mapeo depende de la naturaleza del indicador.

Tipo de IOC	Detección primaria	Detección secundaria
Hash (MD5, SHA256)	YARA (file scan)	SIEM (process creation logs)
IP maliciosa	Suricata (network)	Firewall blocklist
Dominio C2	Suricata (DNS query)	Proxy/DNS sinkhole
URL maliciosa	Suricata (HTTP)	Proxy blocklist
Email (sender/subject)	Sigma (email gateway logs)	Email gateway rules
Mutex / Named pipe	Sigma (Sysmon Event 17/18)	YARA (memory scan)
Registry key	Sigma (Sysmon Event 12/13)	EDR custom rule
Ruta de fichero	Sigma (file creation)	YARA (path scan)
Comportamiento (TTP)	Sigma (process chain)	YARA (memory patterns)
User-Agent string	Suricata (HTTP header)	Proxy logs
JA3/JA3S fingerprint	Suricata (TLS)	Zeek logs
Cadena de ejecución	Sigma (process tree)	EDR behavioral

La regla general: si el IOC vive en un fichero, YARA. Si vive en un log, Sigma. Si vive en la red, Suricata.

---

Escribir reglas YARA desde reportes de amenazas

Anatomía de una regla YARA

rule APT_Malware_Example {
    meta:
        author = "MalwareIntel Research"
        date = "2026-06-05"
        description = "Detecta loader asociado a campaña X"
        reference = "https://malwareintel.es/reports/campaign-x"
        tlp = "white"
        mitre_attack = "T1059.001"

    strings:
        $pdb = "C:\\Users\\dev\\malware\\Release\\loader.pdb" ascii
        $mutex = "Global\\MutexCampaignX" wide ascii
        $api1 = "VirtualAllocEx" ascii
        $api2 = "WriteProcessMemory" ascii
        $api3 = "CreateRemoteThread" ascii
        $magic = { 4D 5A 90 00 03 00 00 00 }
        $xor_key = { 0x41 0x42 0x43 0x44 }

    condition:
        uint16(0) == 0x5A4D and
        filesize < 500KB and
        $pdb and
        ($mutex or (2 of ($api*) and $xor_key))
}

Proceso: del reporte a la regla

Paso 1: Extraer indicadores del reporte. Un reporte de amenazas típico contiene hashes, dominios, IPs, pero también strings internas del malware, rutas PDB, mutex, claves de cifrado. Estos últimos son los más valiosos para YARA porque son difíciles de cambiar para el atacante.

Paso 2: Clasificar por estabilidad. Usando la Pirámide del Dolor como guía:

• Hashes: cambian con cada compilación. Útiles para detección inmediata, vida corta.
• Strings/PDB paths: cambian con cada versión. Vida media.
• Combinaciones de APIs + estructura: cambian solo con rewrite del código. Vida larga.
• Patrones de cifrado/ofuscación: cambian raramente. Máximo valor.

Paso 3: Escribir la regla. Combina indicadores de diferentes niveles de estabilidad. La condición debe ser lo suficientemente específica para evitar falsos positivos pero lo suficientemente genérica para detectar variantes.

Paso 4: Testar contra muestras conocidas. Si tienes acceso a muestras del malware (MalwareBazaar, VirusTotal), verifica que la regla detecta las muestras conocidas. Después, ejecuta contra un corpus de software legítimo para medir falsos positivos.

Herramientas para generación de YARA

• yarGen: genera reglas YARA automáticamente a partir de muestras de malware. Extrae strings únicas comparando contra una base de strings de software legítimo.
• YARA-CI: validación automática de reglas YARA en CI/CD.
• vt-yara: escanea retroactivamente en VirusTotal con tus reglas YARA (requiere cuenta enterprise).

Errores comunes en YARA

1. Reglas demasiado genéricas: detectan la mitad de Windows. Ejemplo: buscar solo CreateRemoteThread sin más contexto.
2. Reglas demasiado específicas: detectan exactamente una muestra. Si el atacante recompila, la regla muere.
3. No incluir filesize: sin límite de tamaño, la regla puede tardar minutos en ficheros grandes.
4. Ignorar el encoding: strings en malware pueden estar en ASCII, wide (UTF-16), o ambos. Usa ascii wide cuando proceda.

---

Escribir reglas Sigma desde análisis de incidentes

Anatomía de una regla Sigma

title: Suspicious PowerShell Download Cradle
id: 3b6ab547-1122-4356-9a8d-example01
status: experimental
description: >
    Detecta ejecución de PowerShell con patrones de descarga
    asociados a campaña X (T1059.001 + T1105)
references:
    - https://malwareintel.es/reports/campaign-x
author: MalwareIntel Research
date: 2026/06/05
tags:
    - attack.execution
    - attack.t1059.001
    - attack.command_and_control
    - attack.t1105
logsource:
    category: process_creation
    product: windows
detection:
    selection_parent:
        ParentImage|endswith:
            - '\winword.exe'
            - '\excel.exe'
    selection_powershell:
        Image|endswith: '\powershell.exe'
        CommandLine|contains:
            - 'DownloadString'
            - 'DownloadFile'
            - 'Invoke-WebRequest'
            - 'IWR'
            - 'wget'
            - 'curl'
    filter_legitimate:
        CommandLine|contains:
            - 'windowsupdate.com'
            - 'microsoft.com'
    condition: selection_parent and selection_powershell
               and not filter_legitimate
falsepositives:
    - Legitimate Office macros that download updates
level: high

Proceso: del incidente a la regla

Paso 1: Reconstruir la cadena de ejecución. Desde los logs del incidente (Sysmon, Windows Event Logs, EDR telemetry), reconstruye qué procesos se ejecutaron, en qué orden, con qué argumentos.

Paso 2: Identificar el patrón anómalo. Lo que diferencia la actividad maliciosa de la legítima. No es que PowerShell se ejecute (eso es normal). Es que PowerShell se ejecute como hijo de Word con un argumento de descarga apuntando a un dominio desconocido.

Paso 3: Abstraer el patrón. Quita los valores específicos del incidente (IP exacta, nombre del fichero) y mantén la estructura. El patrón "Office spawns PowerShell with download" es la detección. La IP específica es solo un IOC de corta vida.

Paso 4: Escribir filtros de exclusión. Identifica los casos legítimos que generarían la misma telemetría. Documéntalos como falsepositives y excluye lo que puedas con filtros.

Fuentes de log para Sigma

Sigma es agnóstico del SIEM. Las reglas se convierten al formato de cada plataforma:

Fuente de log	Eventos clave	Herramienta de conversión
Sysmon	Process creation, network, file, registry	sigma-cli, pySigma
Windows Event Log	Logon, service install, scheduled task	sigma-cli
Linux auditd	Execve, file access, network	sigma-cli
AWS CloudTrail	API calls, console login	sigma-cli
Azure AD	Sign-in, conditional access	sigma-cli

pySigma es el conversor oficial actual. Soporta backends para Splunk, Elastic, Microsoft Sentinel, QRadar, Wazuh, y más.

El repositorio SigmaHQ

Antes de escribir una regla nueva, comprueba si ya existe en SigmaHQ. Más de 3.000 reglas mantenidas por la comunidad. Si existe, úsala. Si no cubre tu caso, extiéndela o crea una nueva y contribuye upstream.

---

Escribir reglas Suricata desde IOCs de red

Anatomía de una regla Suricata

alert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"MALWARE C2 Beacon Campaign-X POST";
    flow:established,to_server;
    http.method; content:"POST";
    http.uri; content:"/api/v2/check"; startswith;
    http.header; content:"User-Agent: Mozilla/5.0 CampaignX";
    http.request_body; content:|89 50 4e 47|; depth:4;
    threshold:type limit, track by_src, count 1, seconds 300;
    reference:url,malwareintel.es/reports/campaign-x;
    classtype:trojan-activity;
    sid:2026060501; rev:1;
    metadata: mitre_attack T1071.001, affected_product Windows;
)

Tipos de reglas de red desde CTI

IP blocklist (nivel básico):

drop ip [185.220.101.0/24,91.92.109.0/24] any -> $HOME_NET any (
    msg:"BLOCKLIST Known C2 Infrastructure";
    sid:2026060502; rev:1;
)

DNS query a dominio malicioso:

alert dns $HOME_NET any -> any any (
    msg:"MALWARE DNS Query to C2 Domain campaign-x.evil";
    dns.query; content:"campaign-x.evil"; nocase;
    reference:url,malwareintel.es/ioc/domain/campaign-x.evil;
    classtype:trojan-activity;
    sid:2026060503; rev:1;
)

JA3 fingerprint (TLS client fingerprint):

alert tls $HOME_NET any -> $EXTERNAL_NET any (
    msg:"MALWARE TLS JA3 Campaign-X Loader";
    ja3.hash; content:"e7d705a3286e19ea42f587b344ee6865";
    classtype:trojan-activity;
    sid:2026060504; rev:1;
)

Proceso: del IOC de red a la regla

IPs y dominios son la traducción más directa. Una IP de C2 reportada en un feed se convierte en una regla alert o drop en minutos. Problema: las IPs rotan rápido. Automatiza la actualización.

URLs y User-Agents requieren más contexto. No basta con bloquear la URL exacta; necesitas entender el patrón. Si el C2 usa /api/v2/check con un User-Agent específico, la regla debe capturar esa combinación.

JA3/JA3S fingerprints son indicadores de nivel medio en la Pirámide del Dolor. El fingerprint TLS del malware cambia solo cuando el desarrollador modifica las librerías de cifrado o la configuración TLS. Son más estables que IPs.

Patrones de protocolo (exfiltración DNS, beaconing HTTP, tunneling ICMP) son detectores comportamentales. Son los más difíciles de escribir pero los más resistentes a cambios del atacante.

Precauciones con Suricata

1. Performance: cada regla añade latencia. Reglas mal escritas (sin depth, sin fast_pattern) pueden degradar el rendimiento en redes de alto tráfico.
2. Falsos positivos en red: bloquear un rango IP sin verificar puede cortar servicios legítimos. Usa alert antes de drop.
3. Cifrado: más del 90% del tráfico web es HTTPS. Suricata ve metadatos TLS (SNI, JA3, certificado) pero no el contenido. Las reglas HTTP solo funcionan si tienes TLS interception o el malware usa HTTP plano.

---

Automatización de la generación de reglas

Pipeline de IOC a regla

Feed CTI ──► MISP ──► n8n ──► Generador de reglas ──► QA ──► Deploy
                                    │
                                    ├── YARA (hashes + strings)
                                    ├── Sigma (comportamientos)
                                    └── Suricata (IPs + dominios + patrones red)

Qué se puede automatizar

Tipo de regla	Automatizable	Requiere analista
YARA por hash exacto	Totalmente	No
YARA por strings/comportamiento	Parcialmente (yarGen)	Validación
Sigma por IOC atómico	Totalmente	No
Sigma comportamental	No	Diseño completo
Suricata por IP/dominio	Totalmente	No
Suricata por patrón protocolo	No	Diseño completo

La regla general: la generación automática funciona para IOCs atómicos (hash, IP, dominio). Para detecciones comportamentales, el analista diseña la lógica.

Herramientas de generación

• IOC2YARA: convierte listas de hashes en reglas YARA de detección.
• sigma-cli: convierte reglas Sigma entre formatos de SIEM.
• Sigma Rule Generator (varias implementaciones): genera reglas Sigma desde IOCs estructurados.
• Suricata-Update: gestiona y actualiza conjuntos de reglas Suricata.
• MISP a Suricata: MISP exporta nativamente en formato Suricata.

---

Quality assurance: antes de desplegar

Una regla mal escrita es peor que no tener regla. Genera ruido que consume tiempo del SOC o bloquea tráfico legítimo.

Checklist de calidad

Para toda regla:

• Metadata completa (autor, fecha, referencia, MITRE ATT&CK).
• Testada contra muestras conocidas (true positives).
• Testada contra tráfico/ficheros legítimos (false positive rate).
• Nivel de severidad justificado.
• Documentación de falsos positivos conocidos.

Específico YARA:

• filesize limitado.
• Condición no trivial (no solo una string genérica).
• Encoding correcto (ascii, wide, base64).

Específico Sigma:

• Conversión exitosa al SIEM destino.
• Filtros de exclusión para casos legítimos.
• Log source correctamente definido.

Específico Suricata:

• fast_pattern definido (rendimiento).
• flow especificado (dirección del tráfico).
• Threshold configurado (evitar flood de alertas).

Versionado de reglas

Trata las reglas como código:

• Repositorio Git dedicado.
• Cada regla en un fichero individual.
• CI/CD que valida sintaxis automáticamente.
• Changelog con razón de cada cambio.
• Tags por campaña/actor/TLP.

---

Feedback loop: de la detección a nueva inteligencia

El ciclo no termina cuando la regla se despliega. Las detecciones generan nueva inteligencia.

Detección (SIEM/EDR/IDS)
    │
    ▼
Alerta al SOC
    │
    ▼
Investigación (¿verdadero positivo?)
    │
    ├── Sí ──► Nuevos IOCs ──► Nuevas reglas
    │          Contexto adicional ──► Actualizar reporte
    │          TTPs observados ──► Reglas comportamentales
    │
    └── No ──► Ajustar regla (reducir FP)
              Documentar el falso positivo

Este feedback loop es lo que diferencia un programa CTI reactivo (consume feeds, genera reglas, fin) de uno maduro (la detección alimenta inteligencia que mejora la detección).

Métricas del feedback loop:

• Hit rate: porcentaje de reglas que generaron al menos una detección real en 90 días.
• False positive rate: alertas descartadas / total alertas por regla.
• Time to detection: desde la publicación del IOC hasta la primera detección real.
• Coverage gap: técnicas ATT&CK sin regla de detección.

---

Recursos

• YARA Documentation (referencia oficial).
• SigmaHQ (repositorio de reglas Sigma).
• Suricata Rules Documentation (referencia oficial).
• yarGen (generador de reglas YARA).
• pySigma (conversor de reglas Sigma).
• Florian Roth - How to Write Simple but Sound Yara Rules (guía práctica).
• MalwareIntel (IOCs con contexto para generar reglas).