Reglas Sigma y YARA con IA: del borrador a la detección probada

Escribir reglas de detección es sobre todo un trabajo de traducción: entra la descripción de un ataque o un montón de cadenas extraídas y sale una regla precisa. Un modelo de lenguaje hace bien esa traducción, siempre que no se niegue a hablar del comportamiento del atacante que intentas detectar. Esta guía muestra cómo usar Odin v1 para redactar reglas Sigma y YARA, ajustarlas, convertirlas en consultas de SIEM y probarlas antes de llevarlas a producción.

Dónde ayuda un modelo y dónde no

Odin v1 acelera las partes lentas pero no difíciles: convertir un párrafo de un informe de amenazas en una primera regla Sigma, elegir cadenas candidatas de un volcado largo de strings, sugerir filtros para alertas ruidosas y explicar por qué una regla saltó o no saltó.

No sustituye a las pruebas. Un modelo nunca ha visto tu entorno ni tu pipeline de logs. Trata cada regla generada como un borrador: valida la sintaxis con herramientas reales, ejecútala contra datos benignos y después contra una muestra maliciosa conocida en un laboratorio.

Reglas Sigma a partir de la descripción de un ataque

Empieza con una descripción breve y concreta del comportamiento. Una entrada vaga ("detecta PowerShell malicioso") produce reglas vagas. Un buen prompt indica la fuente de logs, el comportamiento y el ruido que ya conoces:

Escribe una regla Sigma para logs de creación de procesos de Windows (Sysmon Event ID 1 o Security 4688 con auditoría de línea de comandos). Detecta powershell.exe o pwsh.exe iniciados con -EncodedCommand o cualquiera de sus formas cortas (-e, -ec, -en, -enc). Haz coincidir con Image y OriginalFileName para detectar binarios renombrados. Nuestro cliente de SCCM (C:\Windows\CCM\CcmExec.exe) lanza comandos codificados de forma legítima, así que fíltralo. Incluye etiquetas de ATT&CK, falsos positivos y un nivel.

Cuenta con una regla YAML completa y notas sobre las contrapartidas: -e con espacios alrededor evita que coincida con -ExecutionPolicy, PowerShell acepta cualquier prefijo de parámetro que no sea ambiguo y un filtro basado en el proceso padre puede ser aprovechado por un atacante que controle ese proceso. Tras la revisión, la regla queda así:

title: PowerShell Started With an Encoded Commandid: 3f6b2a9e-5c1d-4e8a-9b27-0d4c8e1f7a63status: experimentaldescription: Detects powershell.exe or pwsh.exe launched with the -EncodedCommand parameter or one of its short forms, often used to hide script content.references:    - https://attack.mitre.org/techniques/T1059/001/author: InterOdin teamdate: 2026-10-20tags:    - attack.execution    - attack.t1059.001    - attack.t1027logsource:    category: process_creation    product: windowsdetection:    selection_img:        - Image|endswith:              - '\powershell.exe'              - '\pwsh.exe'        - OriginalFileName:              - 'PowerShell.EXE'              - 'pwsh.dll'    selection_cli:        CommandLine|contains:            - ' -e '            - ' -ec '            - ' -en '            - ' -enc '            - ' -enco'    filter_main_sccm:        ParentImage: 'C:\Windows\CCM\CcmExec.exe'    condition: all of selection_* and not 1 of filter_main_*falsepositives:    - Configuration management agents and admin scripts that pass encoded commandslevel: medium

El mismo enfoque funciona con los binarios living-off-the-land (LOLBins). Describe un patrón de abuso por regla, por ejemplo "certutil.exe con urlcache o verifyctl descargando un archivo por HTTP":

title: Certutil Used to Download a Remote Fileid: 8c41d0e7-2b6f-4a59-a3d8-61e9f2b07c14status: experimentaldescription: Detects certutil.exe called with urlcache or verifyctl and a URL on the command line, a common living-off-the-land download technique.references:    - https://attack.mitre.org/techniques/T1105/author: InterOdin teamdate: 2026-10-20tags:    - attack.command-and-control    - attack.t1105logsource:    category: process_creation    product: windowsdetection:    selection_img:        - Image|endswith: '\certutil.exe'        - OriginalFileName: 'CertUtil.exe'    selection_flags:        CommandLine|contains:            - 'urlcache'            - 'verifyctl'    selection_url:        CommandLine|contains:            - 'http://'            - 'https://'    condition: all of selection_*falsepositives:    - Rare administrative use to fetch certificates or revocation listslevel: high

Genera tú un UUID nuevo para cada regla; no reutilices nunca un id de un ejemplo.

Reglas YARA a partir de cadenas extraídas

Para YARA, la entrada es el resultado de tu análisis estático: la salida de strings o FLOSS, metadatos PE, secuencias de bytes llamativas de un desensamblador. Odin v1 solo acepta texto, así que pégalo como texto. Su ventana de contexto de 1.000.000 tokens te permite incluir a la vez las cadenas de varios miembros de una familia, que es justo lo que quieres: una buena regla de familia se construye con cadenas que se comparten entre muestras y que son raras en el software limpio.

A continuación tienes los volcados de cadenas de FLOSS de cuatro muestras de la misma familia de loaders, recogidas en nuestro laboratorio de malware. Elige cadenas que aparezcan en al menos tres muestras y que sea poco probable encontrar en software benigno. Evita nombres de API, artefactos del compilador y cadenas de bibliotecas comunes. Escribe una regla YARA para archivos PE de menos de 2 MB y explica por qué has elegido cada cadena.

Cuenta con una regla, el motivo de cada cadena elegida y las cadenas descartadas (como kernel32.dll o un user agent de navegador estándar). Para la familia ficticia de nuestra guía de triage de malware, el resultado es este:

rule SyncHost_Loader_Strings{    meta:        description = "Fictional loader family used as an example on the InterOdin blog"        author = "InterOdin team"        date = "2026-10-20"        reference = "Synthetic strings, not a real malware family"
    strings:        $pdb   = "C:\\build\\synchost\\Release\\loader.pdb" ascii        $mutex = "Global\\SyncHostUpdateMtx" ascii wide        $ua    = "Mozilla/5.0 (Windows NT 10.0; Win64; x64) SyncHost/2.1" ascii        $task  = "OneDrive Sync Helper" ascii wide        $path  = "/a/upd.dat" ascii        $cfg   = { 53 48 43 46 47 01 00 ?? ?? 00 00 }
    condition:        uint16(0) == 0x5A4D and        filesize < 2MB and        ( $pdb or $cfg or 3 of ($mutex, $ua, $task, $path) )}

Una cadena de alta confianza (la ruta del PDB o la cabecera de configuración) basta por sí sola, mientras que las cadenas más débiles tienen que aparecer juntas. Pide al modelo que justifique cada cadena; si no puede, descártala.

Ajustar los falsos positivos

Una regla que salta 400 veces al día acaba desactivada. El ajuste es donde un modelo ahorra más tiempo: el trabajo consiste en leer muchas alertas ruidosas y detectar patrones. Exporta las alertas agregadas por imagen del proceso padre, usuario y línea de comandos, anonimiza los hostnames y nombres de usuario que no necesites, y pregunta:

Estas son las alertas de 7 días de la regla de PowerShell codificado, agrupadas por ParentImage y por el prefijo de CommandLine. ¿Qué grupos parecen software legítimo? Propón filtros Sigma lo más estrechos posible y dime qué tendría que controlar un atacante para aprovechar cada filtro.

Buenos hábitos de ajuste que conviene exigir en el prompt y en la revisión:

• Filtra por rutas completas más el proceso padre, no por una subcadena de la línea de comandos que un atacante pueda copiar.
• Usa la convención de Sigma de filter_main_* para los filtros que aplican en todas partes y filter_optional_* para los específicos de un entorno.
• Baja el level en lugar de añadir un filtro cuando no puedas hacer el filtro estrecho.
• Para YARA, escanea un conjunto grande de goodware (una instalación limpia de Windows, tu repositorio de software) y elimina cualquier cadena que coincida.

Convertir Sigma en una consulta de SIEM

Las reglas Sigma se convierten con sigma-cli, que usa backends y pipelines de procesamiento de pySigma para mapear los campos genéricos a tu esquema de logs:

pip install sigma-clisigma plugin install splunksigma plugin install sysmonsigma check rules/sigma convert -t splunk -p sysmon rules/powershell_encoded_command.yml

Para la regla de PowerShell codificado, la salida para Splunk es:

EventID=1 Image IN ("*\\powershell.exe", "*\\pwsh.exe") OR OriginalFileName IN ("PowerShell.EXE", "pwsh.dll") CommandLine IN ("* -e *", "* -ec *", "* -en *", "* -enc *", "* -enco*") NOT ParentImage="C:\\Windows\\CCM\\CcmExec.exe"

Para Elastic, instala el plugin elasticsearch y usa -t lucene -p ecs_windows. Es preferible usar la herramienta antes que pedir al modelo que convierta a mano: los backends gestionan el escapado y el mapeo de campos de forma consistente.

Probar contra logs benignos y muestras de laboratorio

Cada regla necesita dos pruebas antes de desplegarse.

Una prueba negativa. Ejecuta la regla sobre una línea base que sepas limpia, como una semana de logs de creación de procesos de las máquinas del laboratorio y de algunas estaciones de trabajo representativas. Herramientas como Chainsaw y Zircolite ejecutan reglas Sigma directamente sobre exportaciones EVTX, o puedes lanzar la consulta convertida en tu SIEM sobre una ventana de tiempo tranquila. Cualquier coincidencia es un falso positivo que hay que explicar o filtrar.

Una prueba positiva. Provoca el comportamiento en una VM de laboratorio aislada y confirma que la regla salta. Para la regla de PowerShell codificado basta con un comando inofensivo:

$cmd = [Convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes("Write-Output 'sigma test'"))powershell.exe -NoProfile -EncodedCommand $cmd

Para YARA, el equivalente es:

yara -s -r synchost.yar ./family_samples/   # should match every known family memberyara -r synchost.yar ./goodware/            # should print nothing

Mantén las muestras reales dentro de la VM de análisis, nunca en una estación de trabajo.

Automatizar el ciclo de borrador y comprobación

El script siguiente envía la descripción de un comportamiento a Odin v1, extrae el YAML, lo analiza con pySigma (que lanza un error si la regla no es válida) e imprime la consulta de Splunk. Instala las dependencias con pip install openai sigma-cli pysigma-backend-splunk pysigma-pipeline-sysmon.

import osimport reimport sys
from openai import OpenAIfrom sigma.backends.splunk import SplunkBackendfrom sigma.collection import SigmaCollectionfrom sigma.pipelines.sysmon import sysmon_pipeline
client = OpenAI(base_url="https://api.interodin.com/v1", api_key=os.environ["INTERODIN_API_KEY"])
SYSTEM = (    "You are a detection engineer. Write exactly one Sigma rule in YAML for the behavior "    "described. Use logsource category process_creation and product windows, use Sigma "    "modifiers, list realistic false positives, and return only the YAML.")

def draft_rule(description: str) -> str:    resp = client.chat.completions.create(        model="odin-v1",        messages=[{"role": "system", "content": SYSTEM}, {"role": "user", "content": description}],    )    text = resp.choices[0].message.content    fenced = re.search(r"`{3}(?:ya?ml)?\n(.*?)`{3}", text, re.DOTALL)    return fenced.group(1) if fenced else text

def to_splunk(rule_yaml: str) -> str:    rules = SigmaCollection.from_yaml(rule_yaml)    return SplunkBackend(sysmon_pipeline()).convert(rules)[0]

if __name__ == "__main__":    rule = draft_rule(sys.stdin.read())    print(rule)    print("--- Splunk ---")    print(to_splunk(rule))

Ejecútalo con python draft_sigma.py < behavior.txt. Si el análisis falla, pégale el error al modelo y pídele que lo corrija. Para un entorno de pruebas que ejecute reglas YARA contra carpetas de muestras y de goodware, consulta crear herramientas de seguridad con Claude Code sobre Odin. La guía del SDK de OpenAI explica cómo configurar el cliente.

Empieza ya

Crea una clave de API en la consola, sigue la guía de inicio rápido y apunta el script anterior a un comportamiento de tu último informe de amenazas. Mantén la manipulación de muestras dentro de tu laboratorio y tu trabajo dentro de la Política de Uso Aceptable.