Reglas Sigma y YARA explicadas.

Dos reglas pueden describir el mismo ataque desde extremos opuestos. Una dice: «cuando un host Windows registra un proceso de PowerShell que sale a internet y descarga código, lanza una alerta». La otra dice: «cuando un fichero en disco contiene este patrón de bytes exacto, márcalo como malware». La primera es una regla Sigma: razona sobre eventos de tus logs. La segunda es una regla YARA: razona sobre bytes de tus ficheros. Aprende ambas y podrás expresar detecciones que viajan entre herramientas en lugar de pudrirse dentro de la consola de un único fabricante.

Esta es la idea central de la detección como código, y es el hilo que cose todo este artículo. Empecemos por ahí y luego recorramos cada lenguaje con reglas reales y ejecutables que podrás leer línea a línea.

¿Qué es la detección como código y por qué molestarse?

Durante años, la lógica de detección vivió donde nadie podía verla: tecleada a mano en la barra de búsqueda de un SIEM, guardada como regla de correlación en una interfaz gráfica o, peor aún, en la cabeza de un analista. Ese enfoque tiene tres problemas crónicos. No es portable: una búsqueda de Splunk no se ejecuta en Elastic. No es revisable: no hay diff, ni pull request, ni historial de quién cambió qué y por qué. Y no es comprobable: te enteras de que una regla estaba rota cuando no salta durante un incidente.

La detección como código trata las detecciones igual que los ingenieros tratan el software. Las reglas son ficheros de texto plano, almacenados en Git, revisados por un segundo par de ojos, versionados, etiquetados con la técnica que cubren y validados en CI antes de llegar a producción. Obtienes un changelog para tus defensas. Cuando una detección falla, puedes hacer bisect. Cuando cambias de plataforma, migras las reglas en vez de reescribir tu programa desde cero. Sigma y YARA son los dos formatos más adoptados para hacer exactamente esto: uno para logs, otro para ficheros.

Sigma: una regla de detección genérica para logs y SIEM

Sigma es un formato abierto y neutral respecto al fabricante para describir detecciones sobre datos de logs. Creado por Florian Roth y Thomas Patzke y mantenido por el proyecto SigmaHQ, se suele describir como «el YAML que significa lo mismo en todas partes». Escribes la lógica una vez y un conversor la traduce al lenguaje de consulta del SIEM que realmente uses: Splunk SPL, KQL y EQL de Elastic, KQL de Microsoft Sentinel, AQL de QRadar y muchos más. Piensa en Sigma como la interlingua del stack del SOC: los analistas leen una gramática y cada plataforma habla por debajo su propio dialecto.

Cómo se estructura una regla Sigma

Toda regla Sigma es un documento YAML con un puñado de claves portantes:

• title / id / description: metadatos para humanos. El id es un UUID estable para que el tooling pueda seguir una regla a través de renombrados.
• logsource: dónde buscar. Una category (como process_creation), un product (como windows) o un service (como sshd). Esto es lo que permite mapear una misma regla sobre muchos esquemas de log distintos.
• detection: qué buscar. Uno o varios bloques de «selección» con nombre, con coincidencias campo/valor, usando modificadores como |contains, |endswith o |contains|all.
• condition: cómo se combinan las selecciones, con lógica booleana del tipo selection and not filter.
• falsepositives / level / tags: pistas de triaje y, sobre todo, etiquetas de técnica de MITRE ATT&CK para que la regla encaje en un mapa de cobertura.

Una regla Sigma completa, comentada

Aquí tienes una regla completa y válida que detecta un clásico download cradle de PowerShell, el tipo de one-liner que adoran los droppers de malware:

title: PowerShell Web Download via Net.WebClient   # se muestra en la alerta
id: e6c54d94-498c-4b93-a2d1-1a3e7f9c02aa           # UUID estable para el seguimiento
status: test                                        # experimental | test | stable
description: Detects PowerShell using Net.WebClient to pull a remote payload
references:
  - https://attack.mitre.org/techniques/T1059/001/
author: Breachfolio
date: 2026/07/15
logsource:                     # DÓNDE buscar, independiente del SIEM
  category: process_creation   # p. ej. Sysmon Event ID 1
  product: windows
detection:                     # QUÉ buscar
  selection_img:               # el propio binario de PowerShell
    - Image|endswith: '\powershell.exe'
    - OriginalFileName: 'PowerShell.EXE'
  selection_cli:               # Y ambas cadenas en la línea de comandos
    CommandLine|contains|all:
      - 'Net.WebClient'
      - 'DownloadString'
  condition: selection_img and selection_cli   # cómo se combinan los bloques
falsepositives:
  - Legitimate admin or software-deployment scripts
level: high                    # informational | low | medium | high | critical
tags:
  - attack.execution
  - attack.t1059.001

Léela de arriba abajo y es casi prosa: en Windows, en eventos de creación de proceso, busca PowerShell donde la línea de comandos contenga a la vez Net.WebClient y DownloadString. Fíjate en lo que la regla no dice: nunca menciona Splunk, Elastic ni un mapeo de campos concreto. Esa abstracción es justo el propósito de todo esto.

Convertir Sigma a tu SIEM con sigma-cli y pySigma

El motor que convierte ese YAML en una consulta real es pySigma, que normalmente se maneja a través de la herramienta de línea de comandos sigma-cli. Instálala y lista los backends disponibles:

$ pipx install sigma-cli
$ sigma list targets          # splunk, elasticsearch, kusto (Sentinel/KQL), qradar, ...
$ sigma list pipelines        # sysmon, windows-audit, crowdstrike, ...

Un «pipeline» le indica al conversor cómo los campos abstractos (como Image) se mapean sobre el esquema concreto de tus logs (como un evento EventCode=1 de Sysmon). Para emitir Splunk SPL de la regla anterior usando el pipeline de Sysmon:

$ sigma convert -t splunk -p sysmon powershell_webclient.yml

La salida es una búsqueda nativa de Splunk; el texto exacto depende del pipeline, pero tiene este aspecto:

EventCode=1 (Image="*\\powershell.exe" OR OriginalFileName="PowerShell.EXE")
  CommandLine="*Net.WebClient*" CommandLine="*DownloadString*"

Cambia -t splunk por -t elasticsearch y obtienes una consulta de Elastic en su lugar; pon -t kusto y obtienes KQL para Microsoft Sentinel o Defender. Una regla de origen, muchos destinos. Así es como una comunidad de miles de personas puede compartir detecciones pese a ejecutar plataformas completamente distintas.

YARA: coincidencia de patrones en ficheros, memoria y malware

YARA responde a una pregunta distinta. No mira eventos; mira contenido: los bytes en bruto de ficheros, memoria de procesos o buffers de red. Creado por Victor Alvarez y mantenido por VirusTotal, YARA es el estándar de facto para describir familias de malware y a menudo se le llama «la navaja suiza de coincidencia de patrones para investigadores de malware». Donde Sigma expresa un comportamiento en tus logs, una regla YARA expresa una firma: las huellas que hacen que un fragmento de código sea reconociblemente él mismo. Esas huellas son una especie de indicador de compromiso, codificado para que un escáner pueda actuar sobre él.

Cómo se estructura una regla YARA

Una regla YARA tiene tres secciones dentro de un bloque rule:

• meta: metadatos de formato libre: autor, descripción, fecha, enlaces de referencia, hashes de muestras. No influye en la coincidencia; está ahí para las personas y el tooling de triaje.
• strings: los patrones a buscar. Pueden ser texto ("System.Net.WebClient"), secuencias de bytes en hexadecimal ({ 4D 5A }) o expresiones regulares (/[a-f0-9]{32}/), cada uno con modificadores como nocase, ascii y wide.
• condition: la lógica booleana que decide una coincidencia: cuántas cadenas, en qué combinación, en qué offset, bajo qué tamaño de fichero. Aquí reside la verdadera expresividad de YARA.

Una regla YARA completa

Aquí tienes una regla que marca un pequeño ejecutable de Windows que lleva incrustado un stub descargador de PowerShell:

rule Win_Downloader_PowerShell_Stub
{
    meta:
        description = "Windows PE bundling a PowerShell download cradle"
        author      = "Breachfolio"
        date        = "2026-07-15"
        reference   = "https://attack.mitre.org/techniques/T1059/001/"
        hash        = "d41d8cd98f00b204e9800998ecf8427e"

    strings:
        $mz        = { 4D 5A }                          // bytes mágicos PE "MZ"
        $ps_enc    = "powershell -nop -w hidden -enc" ascii wide nocase
        $webclient = "System.Net.WebClient" ascii wide
        $download  = "DownloadString" ascii wide

    condition:
        // debe empezar por MZ, ser pequeño y contener las cadenas del descargador
        $mz at 0 and filesize < 500KB and $ps_enc and $webclient and $download
}

El modificador ascii wide le dice a YARA que coincida tanto con la codificación en texto plano como con la UTF-16 de una cadena, algo esencial en Windows, donde el mismo texto aparece de las dos formas. La condición $mz at 0 ancla la firma «MZ» al primerísimo byte para que la regla solo salte con ficheros PE reales, y filesize < 500KB evita malgastar ciclos en ficheros grandes e irrelevantes. Detalles pequeños como estos son la diferencia entre una regla precisa y una máquina de falsos positivos.

Probar una regla YARA desde la línea de comandos

La CLI de yara es deliciosamente directa. Apúntala a una regla y a un objetivo:

$ yara -r -s downloader.yar /samples/            # -r recursivo, -s muestra las cadenas coincidentes
Win_Downloader_PowerShell_Stub /samples/dropper.exe
0x0:$mz: 4D 5A
0x3f10:$ps_enc: powershell -nop -w hidden -enc
0x41a8:$webclient: System.Net.WebClient

El mismo binario funciona contra un volcado de memoria o, con una integración de escáner, contra memoria de procesos en vivo, y por eso YARA aparece constantemente en el forense digital y el DFIR, donde los investigadores rastrean imágenes de RAM y disco en busca de código malicioso conocido que nunca tocó un log.

Cuándo usar cada una

La línea divisoria es sencilla: Sigma es para lo que ocurrió; YARA es para lo que algo es. Si tu evidencia es un evento (un proceso que se lanzó, un usuario que se autenticó, una consulta DNS que se resolvió), tira de Sigma. Si tu evidencia es un artefacto (un fichero, una región de memoria, un documento), tira de YARA. La mayoría de los programas de detección maduros usan ambas, porque los ataques dejan las dos clases de rastro.

Los primos: KQL, SPL, EQL y reglas de Suricata

Sigma y YARA no viven solas. Una vez convertida, una regla Sigma se convierte en lenguaje de consulta nativo: SPL en Splunk, KQL en Microsoft Sentinel y Elastic, o EQL (Event Query Language) en Elastic para detecciones basadas en secuencias que encadenan eventos en orden. Estos son los lenguajes de «tiempo de ejecución» a los que Sigma compila; seguirás leyéndolos y afinándolos a mano, pero Sigma conserva la fuente de verdad portable.

En el lado de la red, el equivalente de YARA son las reglas de Suricata (y Snort), que hacen coincidencia de patrones sobre paquetes y flujos en vez de ficheros. Una firma de Suricata se lee un poco como una regla YARA cruzada con una ACL de cortafuegos:

alert http any any -> any any (msg:"Suspicious PowerShell UA";
  http.user_agent; content:"WindowsPowerShell"; sid:1000001; rev:1;)

Si quieres ver cómo se comparan cara a cara los motores de detección de red, nuestro análisis Snort vs Suricata cubre ese terreno. El modelo mental que conviene retener: Sigma vigila los logs, YARA vigila los ficheros, Suricata vigila el cable, y los programas maduros conectan los tres al mismo pipeline de alertas.

Dónde encontrar reglas de detección

Rara vez partes de un fichero en blanco. Repositorios abiertos, enormes y bien curados ya cubren el terreno común, y leerlos es la forma más rápida de aprender los modismos:

• SigmaHQ/sigma: el repositorio canónico de reglas Sigma, con miles de reglas mantenidas por la comunidad y mapeadas a MITRE ATT&CK.
• Neo23x0/signature-base: la base de firmas YARA (y Sigma) de Florian Roth, muy usada, el conjunto de reglas que hay detrás de los escáneres THOR/LOKI.
• Yara-Rules/rules: una gran colección comunitaria de reglas YARA organizada por familia de malware y categoría.
• elastic/detection-rules: el conjunto abierto de reglas de detección de Elastic Security, incluida lógica EQL y KQL que puedes estudiar junto a Sigma.
• YARAify (abuse.ch): un servicio gratuito para escanear ficheros contra un gran pool público de reglas YARA y para cazar con las tuyas propias.

Para las referencias oficiales, ten a mano la documentación de YARA y la especificación de Sigma: ambas son la verdad de referencia cuando un modificador o una condición no se comporta como esperas.

Escribir y probar reglas sin ahogarte en falsos positivos

Una regla que nunca salta es inútil; una regla que salta con todo es peor, porque enseña a tus analistas a ignorarla. La disciplina que separa a los buenos ingenieros de detección de los malos es probar contra la realidad. Unos pocos hábitos cargan con casi todo el peso:

• Prueba con muestras tanto benignas como maliciosas. Ejecuta YARA contra una carpeta de binarios limpios y legítimos (yara -r rule.yar /clean_corpus/) y confirma cero coincidencias antes de fiarte de una coincidencia en una muestra real. Para Sigma, valida la consulta convertida contra logs históricos y cuenta lo ruidosa que es durante una semana normal.
• Ancla y restringe. En YARA, usa límites de filesize, anclas de offset como $mz at 0 y exige varias cadenas juntas en vez de una sola común. En Sigma, añade selecciones filter y condiciones and not para recortar el software legítimo conocido.
• Rellena falsepositives con honestidad. Ese campo no es decoración: es la nota que tu yo futuro leerá a las 3 de la madrugada decidiendo si una alerta importa.
• Haz lint y valida en CI. sigma check valida la sintaxis de la regla, y yara -w (desactiva los avisos) más un paso de compilación cazan reglas rotas antes de que se publiquen. Conecta ambos a un check de pull request para que una regla mala nunca se fusione.
• Etiqueta contra un marco. Mapear cada regla a una técnica de MITRE ATT&CK convierte un montón de detecciones en un mapa de cobertura, para que veas ante qué estás ciego.

Haz estas cosas y la detección dejará de ser folclore. Tus reglas se convierten en artefactos que puedes revisar, migrar y en los que confiar, que es la promesa entera de la detección como código. Sigma te da ojos portables sobre tus logs; YARA te da huellas precisas para tus ficheros. Aprende a escribir y probar ambas y podrás describir casi cualquier amenaza en una forma que sobrevive a la herramienta que hoy te toque usar.

Preguntas frecuentes