YARA Rules Avanzadas: Patrones que los Antivirus No Detectan

Llevo más de una década peleándome con muestras de malware en el laboratorio y, te lo digo sin tapujos, la dependencia ciega de los antivirus de firma tradicionales es el talón de Aquiles de la mayoría de los equipos blue team en España. En 2026, con la explosión de malware polimórfico, ofuscadores de código cada vez más sofisticados y ataques fileless que ni tocan disco, confiar en que tu EDR o tu antivirus de turno lo van a pillar todo es un error de principiante. Ahí es donde entra en juego YARA, pero no la YARA básica de "esta cadena de texto aquí". Me refiero a YARA avanzada, a la ingeniería inversa aplicada a la creación de reglas, a esos patrones estructurales y de comportamiento que el malware, por mucho que se ofusque, no puede esconder del todo. En mi experiencia, una regla YARA bien diseñada es como una mina terrestre enterrada en tu superficie de ataque: silenciosa, específica y letal para el adversario que pase por ahí.

La realidad es que los equipos de red team ya no usan payloads estándar. En un pentest que dirigí el mes pasado para una entidad financiera de primer nivel, el equipo atacante desplegó un dropper que, en memoria, reconstruía un ejecutable .NET completamente legítimo a partir de fragmentos ofuscados en registros del sistema. Los controles de firma no pitaron ni una vez. ¿La clave para detectarlo? Una regla YARA que no buscaba el payload final, sino los patrones de ofuscación en los fragmentos y la secuencia específica de llamadas a API de Windows para ensamblarlos. Ese es el cambio de mentalidad: dejar de cazar el "qué es" y empezar a cazar el "cómo se comporta".

¿Por qué las reglas YARA avanzadas son tu red de seguridad definitiva?

Los motores antivirus y muchos EDRs comerciales funcionan, en el fondo, con lógica similar a YARA: buscan patrones. El problema gordo es que sus patrones son genéricos, están masificados y se actualizan con un retraso que los atacantes explotan sin piedad. Una regla YARA que tú escribes para tu entorno es un detector de anomalías hiperespecífico. Mientras el antivirus busca "MALWARE_GENERICO.Z", tú estás buscando "la herramienta de administración interna que solo usa el departamento de contabilidad, pero ejecutándose desde la carpeta Temp con un argumento de línea de comandos que nunca se usa". La diferencia es abismal. Sinceramente, la mayoría de empresas españolas con las que trabajo tienen una superficie de ataque muy particular: software legacy personalizado, aplicaciones ERP hechas a medida (como SAP customizado o soluciones de gestión propietarias), y procesos de negocio muy específicos. Un atacante que quiera moverse sin ser visto va a tener que mimetizarse con ese entorno, y ahí es donde tus reglas personalizadas brillan.

¿Cómo piensa un analista de malware para escribir reglas efectivas?

El error clásico es abrir un hex editor, ver una cadena como "C:\Windows\System32\cmd.exe" y meterla en una regla. Cualquier malware medianamente decente en 2026 ofuscará esa cadena, la codificará en base64, la dividirá en variables o la obtendrá dinámicamente en tiempo de ejecución. Tu regla se vuelve inútil. La clave está en pensar en capas y en invariantes. Un invariante es algo que el malware no puede cambiar sin dejar de funcionar. Por ejemplo, la secuencia de bytes de una llamada a una API crítica, la estructura de un encabezado PE (Portable Executable) aunque esté empaquetado, o la lógica de un algoritmo de descifrado en memoria.

Te pongo un ejemplo técnico real de un ransomware que analicé a finales de 2025, una variante de LockBit que usaba un ofuscador custom. El string CryptEncrypt de la API de Windows no aparecía en claro. Sin embargo, para funcionar, el código tenía que resolver la dirección de esa función en la DLL advapi32.dll. El ofuscador generaba un hash de la cadena de función (usando un algoritmo ROR13 simple) y lo comparaba con valores precalculados. Mi regla no buscaba la cadena, buscaba el patrón de resolución de API por hash, una técnica común en muchos injectors.

rule Ransomware_API_Hashing_ROR13 {
    meta:
        description = "Detecta resolucion de API mediante hashing ROR13, comun en loaders y ransomware"
        author = "David Moya - Riskitera"
        date = "2026-01-15"
        reference = "Internal analysis of LockBit variant"

    strings:
        $ror13_init = { 8B [2-4] 83 [0-2] 0D [0-4] C1 [0-2] 0D [0-4] } // Patron ASM tipico para ROR
        $kernel32_hash = 0x0A3F3B7A // Hash ROR13 de "LoadLibraryA" (ejemplo)
        $advapi32_hash = 0x0F4A7B2C // Hash ROR13 de "CryptEncrypt" (ejemplo)
        $get_proc_addr = { FF 15 ?? ?? ?? ?? } // CALL a una direccion de memoria, tipico post-resolucion

    condition:
        uint16(0) == 0x5A4D and // Es un archivo PE
        filesize < 2MB and // Filtro de tamaño
        ( $ror13_init and 2 of ($advapi32_hash, $kernel32_hash) ) or
        ( $ror13_init and $get_proc_addr in (filesize-500..filesize) ) // Busca cerca del final del .text
}

Este es el tipo de pensamiento que marca la diferencia. No estás cazando el malware, estás cazando la técnica.

yara-rules-avanzadas-patrones-que-los-antivirus-no-detectan diagram 1

¿Qué patrones de ofuscación modernos puedes detectar con YARA?

Para 2026, la ofuscación ha evolucionado mucho, pero se basa en principios clásicos. Te voy a desglosar tres técnicas comunes donde YARA, con un poco de ingenio, gana siempre.

1. Ofuscación de strings y llamadas a API: Como vimos, el hashing es común. Pero también lo es la construcción dinámica de strings en la pila (stack), el uso de XOR con una clave byte a byte, o la codificación con algoritmos simples como Base64 o ROT13. Una regla avanzada puede detectar el bucle de descifrado en sí, no el string descifrado. Busca patrones de instrucciones como XOR [REG], CL, ADD BYTE [REG], 0x61, o llamadas a funciones como CryptDecrypt en un bucle.

2. Empaquetamiento y cifrado de la sección .text: Los packers clásicos como UPX son triviales, pero los custom son otro mundo. Una regla útil no intenta ver el código cifrado, sino identificar el stub del unpacker: la pequeña rutina de código que descifra el resto en memoria. Suele estar al principio de la sección .text y tiene patrones reconocibles: ajustes de permisos de memoria (VirtualProtect), asignación de memoria nueva (VirtualAlloc), y un bucle de copia o descifrado. Aquí, combinar YARA con herramientas como pefile en Python para analizar las características PE anómalas (por ejemplo, una sección .text con tamaño raw muy pequeño pero tamaño virtual enorme) es letal.

3. Inyección de código en procesos legítimos (Process Hollowing): Esta es una de mis favoritas para detectar. El malware crea un proceso en estado suspendido (ej. svchost.exe), vacía su memoria y escribe su código malicioso. La regla no se aplica al archivo en disco, ¡sino al volcado de memoria del proceso vivo! Con un framework como Velociraptor o incluso volcados de procdump, puedes escanear la memoria de los procesos. Buscas la incongruencia: un proceso svchost.exe cuya imagen base en memoria no coincide con el svchost.exe legítimo de C:\Windows\System32, o que tiene regiones de memoria ejecutables con nombres de sección extraños.

#!/bin/bash
# Ejemplo de script para volcar y escanear procesos sospechosos con YARA
# Uso interno en investigaciones de incidentes

PROCESS_NAME="svchost.exe"
YARA_RULES="/rules/process_hollowing.yar"
OUTPUT_DIR="/investigations/$(date +%Y%m%d_%H%M%S)/"

mkdir -p $OUTPUT_DIR

# 1. Encontrar PIDs del proceso con argumentos sospechosos o paths raros
pids=$(ps aux | grep "$PROCESS_NAME" | grep -v grep | grep -E "(/tmp|/var/tmp|AppData)" | awk '{print $2}')

for pid in $pids; do
    echo "[*] Volcando proceso $pid a $OUTPUT_DIR/$pid.dmp"
    # Usamos procdump de Sysinternals (previamente instalado)
    procdump64 -ma $pid $OUTPUT_DIR/$pid.dmp > /dev/null 2>&1

    if [ -f "$OUTPUT_DIR/$pid.dmp" ]; then
        echo "[*] Aplicando reglas YARA..."
        yara $YARA_RULES $OUTPUT_DIR/$pid.dmp >> $OUTPUT_DIR/findings.log 2>&1
    fi
done

echo "[+] Análisis completado. Revisar $OUTPUT_DIR/findings.log"

Este script es rudimentario, pero en un entorno con un agente EDR que permita scripting (como osquery o Wazuh), puedes automatizar este escaneo en memoria periódicamente. Ojo con el rendimiento, claro.

¿Cómo integrar YARA avanzada en tu arquitectura de seguridad operativa?

Tener reglas brillantes en una carpeta de tu portátil no sirve de nada. La potencia está en la integración. En Riskitera, para nuestros clientes de SOC gestionado, desplegamos un pipeline de detección basado en YARA en varios puntos:

En el endpoint (pre-execución): Integrado con herramientas como Elastic Endpoint 8.x o Wazuh 4.7, que permiten cargar reglas YARA y escanear archivos en tiempo de escritura. Es tu primera línea de defensa.
En el correo (post-gateway): Soluciones como ClamAV pueden ser aumentadas con reglas YARA. Escaneamos todos los adjuntos salientes del gateway de correo con un conjunto de reglas centradas en documentos ofuscados (Office, PDF) y scripts (VBS, JS, PowerShell). En 2026, el 70% de los incidentes que gestionamos aún empiezan por phishing.
En el sandbox/entorno de análisis dinámico: Herramientas como Cuckoo Sandbox 3.0 o CAPE 2.5 usan YARA para clasificar automáticamente el comportamiento del malware capturado. Aquí las reglas son más amplias, buscando comportamientos post-ejecución: intentos de conexión a dominios C2, mutación de registros, creación de servicios.
En el data lake de logs: Usamos Sigma (la versión 2.0, que es un estándar ya maduro) para generar reglas de detección en los SIEM a partir de indicadores de comportamiento, pero a veces un log contiene un fragmento de script o un payload. Ahí, motores como yara-python escanean los logs almacenados en Elasticsearch o Snowflake en busca de esos patrones profundos.

La integración más potente que hemos implementado es con Velociraptor. Velociraptor no es solo un tool de respuesta a incidentes; es una plataforma de orquestación. Con él, puedes lanzar colecciones de artefactos que, en tiempo real, ejecutan YARA contra la memoria de procesos, contra archivos en rutas específicas, o incluso contra el registro de Windows. La belleza está en que la regla YARA se ejecuta en el endpoint, y solo se envían los resultados positivos al servidor. Es escalable y discreta.

¿Qué herramientas y técnicas de debugging son esenciales para crear reglas?

Para escribir reglas que detecten lo que otros pasan por alto, necesitas ensuciarte las manos. No hay atajos.

IDA Pro 8.3 o Ghidra 10.4: Imprescindibles. No basta con ver strings. Tienes que seguir el flujo de ejecución, entender cómo se resuelven las APIs, identificar los bucles de descifrado. Ghidra, al ser open-source, es perfecta para automatizar análisis con scripts Python.
Process Monitor (ProcMon) y Process Hacker 2: Ver el comportamiento en tiempo real. ¿Qué archivos toca el proceso? ¿Qué claves de registro modifica? ¿A qué DLLs extrañas llama? Un patrón de acceso a amsi.dll (la interfaz de Antimalware Scan Interface) seguido de una serie de escrituras en memoria, por ejemplo, es un indicio enorme de intento de evasión de AMSI en PowerShell.
x64dbg: Para el análisis dinámico, ver el código ejecutándose instrucción a instrucción, poner breakpoints en las llamadas a API críticas y volcar memoria en el momento exacto del descifrado. Es la forma de obtener los "invariantes" de los que hablaba.
YARA con módulos: Mucha gente no usa los módulos de YARA. El módulo pe es oro puro. Te permite escribir condiciones basadas en características estructurales del PE: número de secciones, entropía de una sección, imports sospechosas (VirtualAlloc + CreateRemoteThread es la firma clásica de un injector), exports, recursos embebidos.

import "pe"

rule Suspicious_DotNET_Resource {
    meta:
        description = "Detecta assemblies .NET con recursos de alta entropía (posible payload cifrado/empaquetado)"
        author = "David Moya - Riskitera"

    condition:
        pe.is_dotnet() and // Solo archivos .NET
        for any i in (0..pe.number_of_resources - 1): (
            pe.resources[i].type == pe.RESOURCE_TYPE_RCDATA and // Recurso de datos crudos
            pe.resources[i].entropy > 7.0 // Entropía muy alta, indica datos no comprimidos sino cifrados
        )
}

Esta regla, simple pero efectiva, nos ha ayudado a pillar varios droppers que escondían el stage 2 en recursos de ensamblados .NET "inocuos".

¿Cuál es el futuro de la detección con YARA y hacia dónde vamos?

Para 2026, la frontera ya no está solo en el disco o en la memoria de usuario. Los atacantes se mueven hacia el kernel, usan drivers firmados legítimamente (como se vio en el incidente de BlackLotus UEFI bootkit que explotaba CVE-2023-24932), y aprovechan hardware como GPUs para ofuscar ejecución. YARA tiene que evolucionar, y lo está haciendo.

El proyecto YARA-X, un reescritura en Rust que está ganando tracción, promete mayor velocidad y un mejor manejo de concurrencia, esencial para escanear petabytes de datos en entornos cloud. Por otro lado, la integración con Machine Learning no es sustituir YARA, sino alimentarla. Un modelo ML puede identificar un archivo PE como "sospechoso" con un 85% de confianza. Ahí es donde tu regla YARA avanzada entra a diseccionar por qué es sospechoso, buscando las técnicas específicas que el modelo solo intuye.

La tendencia más fuerte que veo es la detección en tiempo de compilación. Con el auge de los lenguajes como Go y Rust para desarrollar malware (por su capacidad de generar binarios estáticos y su "rareza" en entornos Windows), estamos escribiendo reglas que buscan artefactos de estos compiladores: tablas de runtime específicas, estructuras de metadatos, o incluso cadenas de error características que el linker deja atrás. Un ransomware escrito en Go, por mucho que ofusque strings, no puede eliminar la firma de la runtime de Go sin romper el ejecutable.

Al final, se trata de un juego de gato y ratón infinito. Pero con YARA en tus manos, dejas de ser el gato que persigue al ratón a ciegas. Te conviertes en el arquitecto del laberinto, colocando detectores en los pasadizos por los que, inevitablemente, el ratón tendrá que pasar. La próxima vez que tu EDR no salte ante algo raro, no maldigas a la herramienta. Abre IDA, coge la muestra, y escribe la regla que debería haberla cazado. Esa es la diferencia entre un blue team reactivo y uno que realmente controla su terreno.

Recursos y referencias

The Official YARA Documentation: https://yara.readthedocs.io/ - La biblia. Especialmente la sección de módulos.
Awesome YARA Rules (GitHub): https://github.com/InQuest/awesome-yara - Una colección curada de repositorios con reglas de alta calidad para inspirarse y aprender.
Velociraptor Documentation - YARA Scanning: https://docs.velociraptor.app/ - Cómo integrar YARA de forma poderosa en respuesta a incidentes y monitoreo continuo.
"Writing YARA Rules - Beyond the Basics" (SANS DFIR Whitepaper, 2025): Un paper excelente que profundiza en el uso de módulos y técnicas de optimización para entornos de gran escala.