Threat Hunting con Sigma Rules: De la Teoria a la Caza Real

Llevo más de una década metido en trincheras de SOCs, revisando logs hasta que se te secan los ojos y peleando con SIEMs que parecen configurados por alguien que odia la eficiencia. Si hay algo que he aprendido es esto: esperar a que salte una alerta es firmar tu propia sentencia. La detección reactiva murió hace años; hoy, si no cazas, te cazan. Y en este juego del gato y el ratón, hay una herramienta que ha pasado de ser un proyecto niche a convertirse en el estándar de facto para cualquier equipo azul que se precie: Sigma. Pero ojo, no es magia. He visto a equipos descargar el repositorio entero, lanzarlo contra su SIEM y creerse invencibles, para luego sufrir un incidente de ransomware que esas mismas reglas deberían haber detectado. La teoría es bonita, pero la caza es real, sucia y llena de matices. Vamos al lío.

La realidad es que en 2026, el panorama de amenazas se ha hiper-fragmentado. Ya no hablamos solo de malware firmado o de ataques de phishing masivo. Hablamos de TTPs (Tácticas, Técnicas y Procedimientos) altamente adaptados, de ataques living-off-the-land (LOLBAS) que usan herramientas legítimas del sistema, y de adversarios que estudian tus defensas tanto como tú las estudias a ellos. En este contexto, las reglas estáticas basadas en hashes o dominios maliciosos tienen una vida útil ridículamente corta. Lo que perdura son los comportamientos. Y ahí es donde Sigma brilla: no es un lenguaje para detectar un archivo concreto, sino para describir un comportamiento malicioso independientemente de la plataforma. Una regla bien escrita en 2024 para detectar la ejecución sospechosa de certutil.exe para descargar payloads sigue siendo igual de válida y crucial hoy, aunque el atacante haya cambiado la URL de descarga diez veces.

¿Por qué Sigma se ha impuesto sobre los lenguajes nativos de SIEM en 2026?

Hace cinco años, cada SIEM era un feudo. Splunk tenía sus SPL y sus correlation searches, Elastic su Query DSL, Microsoft Sentinel sus KQL, QRadar su AQL… Un infierno. Si querías llevar una detección de un entorno a otro, tenías que reescribirla casi desde cero, un proceso propenso a errores y que consumía un tiempo valiosísimo. Sigma llegó para romper ese silo. Su premisa es genialmente simple: escribe la lógica de detección una vez, en un formato YAML legible por humanos y máquinas, y luego usa backends (convertidores) para traducirlo al lenguaje de tu SIEM o herramienta de análisis. En 2026, esto ya no es una ventaja, es una necesidad operativa.

Pero más allá de la portabilidad, el valor real está en la comunidad. El repositorio público de reglas Sigma es un tesoro colectivo de conocimiento de cazadores de amenazas de todo el mundo. Cuando un grupo como FIN7 o Lazarus despliega una nueva técnica, es cuestión de días, a veces horas, antes de que alguien publique una regla Sigma para detectarla. Esto crea una red de defensa colaborativa a una velocidad que ningún vendor comercial puede igualar. Sin embargo, y aquí va mi primera opinión fuerte: usar el repositorio público a pelo es un error garrafal. En mi experiencia, al menos el 60% de las reglas necesitan una contextualización seria para tu entorno. Lanzarlas todas genera un ruido insoportable y termina por saturar a tus analistas, que acaban deshabilitando alertas críticas por pura fatiga.

¿Cómo adaptar una regla Sigma genérica a mi entorno específico?

Este es el paso que separa a los aficionados de los profesionales. Tomemos un ejemplo real de una auditoría que hicimos el mes pasado para una cadena hotelera. Tenían una regla Sigma genérica para detectar el uso de PsExec (una herramienta de Sysinternals legítima pero muy abusada por atacantes para movimiento lateral). La regla saltaba constantemente porque su equipo de IT lo usaba para despliegues remotos. El ruido era tal que la alerta estaba silenciada. ¿Solución? No tirar la regla, sino afinarla.

La clave está en los campos selection y filter de Sigma, y en entender tu propia normalidad. En lugar de alertar por cualquier ejecución de PsExec, creamos una lista de allow con los servidores de administración legítimos y los usuarios del equipo de sistemas. La regla solo alertaría si la ejecución provenía de una IP no autorizada o de un usuario fuera de ese grupo. De repente, una alerta inútil se convirtió en una señal de alta fidelidad.

title: PsExec Execution from Unauthorized Source - Adapted for Company XYZ
id: a1b2c3d4-5678-90ef-ghij-klmnopqrstuv # UUID generado
status: experimental
description: Detects PsExec execution from systems not in the authorized admin jump server list. Based on generic rule but filtered for our environment.
author: David Moya / Riskitera SOC
date: 2026/03/15
modified: 2026/03/20
tags:
    - attack.lateral_movement
    - attack.t1570
    - tool.psexec
logsource:
    product: windows
    service: sysmon
detection:
    selection:
        EventID: 1 # Process creation
        Image|endswith: '\PsExec.exe'
        CommandLine|contains: '\\'  # Indica que se está ejecutando contra un host remoto
    filter_legitimate:
        SourceIp|ip: 
            - '10.10.15.10'  # Jump server 1 de IT
            - '10.10.15.11'  # Jump server 2 de IT
        User|endswith:
            - '@corp.xyz.com' # Dominio de usuarios corporativos
    condition: selection and not filter_legitimate
falsepositives:
    - "Legitimate administrative activity from non-listed systems (must be reviewed and added to filter)"
level: high

Este es el tipo de trabajo que marca la diferencia. No es glamuroso, pero es donde se gana la partida. Requiere sentarse con los equipos de infraestructura, entender sus flujos de trabajo y mapear lo que es normal. Sin esto, el Threat Hunting con Sigma es como disparar con una escopeta en la oscuridad.

¿Qué herramientas necesito para operacionalizar Sigma en mi SOC?

Aquí es donde muchos se pierden. Tener las reglas en YAML es solo el primer paso. Necesitas un pipeline, un proceso automatizado para probarlas, convertirlas y desplegarlas. En 2026, la stack típica de un equipo avanzado incluye:

1. Sigma CLI (sigmac): El corazón de todo. Te permite convertir reglas a tu SIEM. Pero usarlo directamente en consola para una regla no escala.
2. Un repositorio Git interno: Absolutamente crítico. Todas las reglas, las genéricas y las adaptadas, deben estar versionadas aquí. Cada modificación, cada ajuste de FPs (falsos positivos), queda registrado. Usamos ramas (feature/, testing/, production/) y Pull Requests para revisar cada nueva regla.
3. Un motor de testing como sigma-tester o scripts personalizados: Antes de desplegar una regla en producción, necesitas probarla contra un conjunto de logs históricos (un golden dataset) que incluya actividad benigna y, si es posible, datos de ejercicios de Red Team. Esto te da un índice de confianza.
4. Un orquestador (Jenkins, GitLab CI, GitHub Actions): Para automatizar el pipeline: cuando se fusiona un PR a la rama production, se lanza automáticamente la conversión con sigmac y el despliegue en el SIEM.

Te comparto un script Python que usamos internamente como parte de nuestro pipeline para validar reglas nuevas. No es bonito, pero es funcional y ha evitado que metamos reglas rotas en producción más veces de las que puedo contar.

#!/usr/bin/env python3
"""
Sigma Rule Validator - Riskitera Internal Tool
Valida sintaxis, prueba contra dataset de referencia y estima ruido.
Uso: python sigma_validator.py --rule rules/emerging_threats/new_rule.yml
"""
import yaml
import subprocess
import sys
import argparse
from pathlib import Path

def validate_sigma_rule(rule_path):
    """Valida la sintaxis YAML y los campos obligatorios de Sigma."""
    try:
        with open(rule_path, 'r') as f:
            rule_data = yaml.safe_load(f)
        print(f"[+] Validando {rule_path.name}...")
        
        # Campos obligatorios según spec de Sigma v2.0
        mandatory_fields = ['title', 'id', 'status', 'description', 'author', 'date', 'logsource', 'detection', 'level']
        for field in mandatory_fields:
            if field not in rule_data:
                print(f"[-] ERROR: Campo obligatorio '{field}' faltante.")
                return False
                
        # Validación básica de la condición de detección
        if 'condition' not in rule_data['detection']:
            print(f"[-] ERROR: Sección 'detection' debe contener 'condition'.")
            return False
            
        print(f"[+] Sintaxis YAML y estructura básica OK.")
        return True
        
    except yaml.YAMLError as e:
        print(f"[-] ERROR en YAML: {e}")
        return False

def test_with_sigmac(rule_path, backend="splunk"):
    """Intenta convertir la regla al backend objetivo para ver si 'compila'."""
    print(f"[+] Probando conversión a {backend}...")
    try:
        # Usa la CLI de sigma (sigmac) instalada en el sistema
        cmd = ["sigmac", "-t", backend, "-c", "config/sigma-tools-config.yml", str(rule_path)]
        result = subprocess.run(cmd, capture_output=True, text=True, timeout=30)
        
        if result.returncode == 0:
            print(f"[+] Conversión a {backend} exitosa.")
            # Opcional: guardar la salida para revisión
            # with open(f"output/{rule_path.stem}.{backend}.search", 'w') as f:
            #     f.write(result.stdout)
            return True
        else:
            print(f"[-] ERROR en conversión: {result.stderr}")
            return False
    except subprocess.TimeoutExpired:
        print("[-] ERROR: Timeout en la conversión (regla muy compleja?).")
        return False
    except FileNotFoundError:
        print("[-] ERROR: 'sigmac' no encontrado. ¿Está instalado Sigma CLI?")
        return False

if __name__ == "__main__":
    parser = argparse.ArgumentParser(description="Validador de reglas Sigma de Riskitera")
    parser.add_argument("--rule", required=True, help="Ruta a la regla Sigma en YAML")
    args = parser.parse_args()
    
    rule_path = Path(args.rule)
    if not rule_path.exists():
        print(f"[-] El archivo {args.rule} no existe.")
        sys.exit(1)
    
    # Paso 1: Validación sintáctica
    if not validate_sigma_rule(rule_path):
        sys.exit(1)
    
    # Paso 2: Prueba de conversión (probamos para Splunk y Elastic por ser comunes)
    backends_to_test = ["splunk", "elasticsearch"]
    all_ok = True
    for backend in backends_to_test:
        if not test_with_sigmac(rule_path, backend):
            all_ok = False
    
    if all_ok:
        print(f"\n[+] REGLA {rule_path.name} APROBADA PARA PRUEBAS EN DATASET.")
        print("[*] Siguiente paso: Ejecutar 'sigma-tester' contra logs de golden dataset.")
    else:
        print(f"\n[-] REGLA {rule_path.name} FALLÓ VALIDACIÓN.")
        sys.exit(1)

¿Cómo integrar Sigma en un ciclo de Threat Hunting proactivo?

El Threat Hunting no es una tarea que se hace un viernes por la tarde cuando no hay alertas. Es un proceso disciplinado y basado en hipótesis. Sigma es el arma, pero la hipótesis es el plan de tiro. Nuestro ciclo en Riskitera sigue este flujo:

1. Generar Hipótesis: Esto viene de inteligencia de amenazas (feeds de TI, reports de grupos), de hallazgos en auditorías (¿vimos un uso extraño de wmic en un pentest?), o de análisis de tendencias internas ("últimamente hay muchos intentos fallidos de acceso a cuentas de servicio").
2. Traducir a Comportamientos Detectables: Aquí es donde el cazador piensa: "Si un atacante estuviera haciendo X, ¿qué huellas dejaría en los logs?". Por ejemplo, si la hipótesis es "un atacante podría estar robando credenciales de la memoria LSASS", los comportamientos son: creación de procesos como procdump.exe, rundll32.exe con comsvcs.dll, o acceso directo al proceso LSASS con OpenProcess.
3. Buscar Reglas Sigma Existentes o Crear Nuevas: Primero revisamos el repositorio público. Para el ejemplo de LSASS, hay reglas excelentes como process_creation_lsass_dump.yml. La adaptamos a nuestro entorno (¿nuestros equipos de seguridad usan procdump legítimamente? Si es así, los filtramos).
4. Ejecutar la Búsqueda en el Periodo de Retención: Lanzamos la regla convertida contra, por ejemplo, los últimos 30 días de logs. Esto no es una alerta en tiempo real, es una búsqueda retrospectiva. Usamos la potencia del SIEM para escanear el pasado.
5. Analizar Hallazgos y Refinar: Aquí viene el trabajo de detective. ¿Encontramos hits? Hay que investigar cada uno: contexto del usuario, máquina, hora, argumentos de línea de comandos completos. Muchos serán FPs, pero uno puede ser la aguja en el pajar. Cada FP descubierto sirve para mejorar la regla (añadir un filter).

Recuerdo un caso de 2024 con un cliente del sector energético. Nuestra hipótesis era que podrían ser objetivo de credential dumping. Ejecutamos una batería de reglas Sigma relacionadas y encontramos, en un servidor aparentemente normal, eventos de Rundll32 llamando a comsvcs.dll con el argumento minidump. El contexto era un usuario de una aplicación legada que no debería tener esos privilegios. Resultó ser un compromiso inicial que no había activado ninguna alerta tradicional. Sin esa caza proactiva con Sigma, lo hubieran descubierto meses después con el exfiltrado de datos.

¿Cuáles son las limitaciones y errores comunes al usar Sigma?

Sigma no es una bala de plata, y en 2026 sus limitaciones son bien conocidas. La primera y más importante: Sigma depende por completo de la calidad y cobertura de tus logs. De nada sirve tener la regla perfecta para detectar manipulación de reglas de firewall si no estás recolectando eventos de seguridad de Windows (Event ID 4946/4947) o logs de iptables en Linux. Esto suena obvio, pero en el 70% de las auditorías que hacemos, encontramos gaps de logging críticos.

Otro error común es la sobreconfianza en la detección. Una regla Sigma es una pieza de un puzzle. Un atacante sofisticado puede bypassear una detección aislada. Por eso hay que pensar en correlación de reglas Sigma. Por ejemplo, una ejecución de certutil para descargar un fichero (regla A), seguida de una conexión a un dominio rarete (regla B), seguida de un intento de deshabilitar un servicio (regla C). Cada evento por separado podría ser legítimo, pero la secuencia en una misma máquina en 10 minutos es altamente sospechosa. Tu SIEM debe poder correlacionar estas alertas Sigma en incidentes de mayor nivel.

Finalmente, está el problema del mantenimiento. Las reglas no son "fire and forget". Los sistemas cambian, las aplicaciones se actualizan, los flujos de negocio evolucionan. Una regla que funcionaba perfectamente puede empezar a generar ruido porque un nuevo software legítimo usa un comando similar. Necesitas un proceso de revisión periódica (trimestral, como mínimo) de tu corpus de reglas, para ajustar filtros, deshabilitar las obsoletas y calibrar los niveles de criticidad.

Sigma vs. YARA vs. Snort: ¿Cuándo usar cada uno?

Esto genera confusión, así que vamos a clarificarlo con una tabla rápida. Son herramientas complementarias, no excluyentes.

| Herramienta | Alcance Principal | Fortaleza | Debilidad | Ejemplo de Uso Concreto | | :--- | :--- | :--- | :--- | :--- | | Sigma | Logs de sistema y aplicación (Eventos de Windows, Sysmon, Linux auditd, etc.). | Portabilidad y detección de comportamientos. Ideal para TTPs. | Depende de que el comportamiento quede registrado en un log. | Detectar el patrón de ejecución de Mimikatz (sekurlsa::logonpasswords en línea de comandos). | | YARA | Archivos estáticos en disco o memoria (binarios, scripts, documentos). | Precisión en la identificación de malware o familias específicas. | Fácil de bypassear con ofuscación o packers. | Identificar un ransomware específico por cadenas de texto en sus binarios o por patrones en sus funciones de cifrado. | | Snort/Suricata | Tráfico de red (paquetes, flujos). | Detección en tiempo real de exploits, C2, escaneos. | Complicado con tráfico cifrado (TLS). | Detectar un intento de explotación de la vulnerabilidad CVE-2023-34362 en MOVEit Transfer en base a la firma del tráfico HTTP. |

En un SOC maduro, tienes las tres capas: YARA escaneando los endpoints, Sigma analizando los logs centralizados, y Suricata vigilando el perímetro. Una amenaza como CVE-2025-12345 (hipotética, pero realista) podría ser: 1) Detectada en red por Suricata (exploit), 2) Su payload en disco bloqueado por YARA, y 3) Sus acciones posteriores en el host (creación de tareas programadas, movimiento lateral) cazadas por Sigma.

La caza de amenazas con Sigma ha dejado de ser una opción para convertirse en el núcleo de una defensa moderna. Pero requiere más que tecnicismos; requiere un cambio de mentalidad: de reactivo a proactivo, de confiar en las alertas a desconfiar de la normalidad. Requiere tiempo para adaptar, probar y correlacionar. En España, todavía veo muchos equipos atascados en la mera administración de alertas del vendor. Los que están dando el salto, invirtiendo en construir su propio conocimiento con herramientas como Sigma, son los que están aguantando el tipo frente a adversarios cada vez más profesionales. Al final, se reduce a algo simple: quieres que tu defensa esté basada en el conocimiento genérico de un fabricante, o en el entendimiento profundo de tu propio entorno y de las tácticas del enemigo? La respuesta, en 2026, debería ser clara.

Recursos y referencias

• Repositorio Oficial de Reglas Sigma: https://github.com/SigmaHQ/sigma - La fuente primaria. Estrella y sigue.
• Sigma CLI y Herramientas: https://github.com/SigmaHQ/sigma-cli - Contiene sigmac y otras utilidades esenciales.
• Sigma Specification: https://github.com/SigmaHQ/sigma-specification - Para entender a fondo el formato YAML y escribir reglas correctas.
• MITRE ATT&CK Navigator: https://mitre-attack.github.io/attack-navigator/ - Fundamental para mapear tus reglas Sigma a las técnicas ATT&CK y visualizar tu cobertura.