YARA:

escribiendo tus primeras reglas para detectar malware

Blue Team / Forense  |  unfantasmaenelsistema.com

Un analista abre una muestra sospechosa, la estudia, y saca en claro un puñado de detalles concretos: una cadena de texto rara incrustada en el binario, una clave de mutex, un fragmento de shellcode, el nombre de un panel de control. YARA es la herramienta que convierte esos detalles en una regla reutilizable, capaz de reconocer esa misma familia de malware —o sus variantes— en miles de ficheros, en memoria o en el tráfico guardado de una investigación.

Creada por Víctor Álvarez (VirusTotal), YARA se ha convertido en el lenguaje común para describir y compartir patrones de código malicioso. La usan equipos de respuesta a incidentes, plataformas de sandboxing, antivirus y proyectos como Loki o THOR. Este artículo es una introducción práctica a escribir tus primeras reglas con un enfoque defensivo: identificar y clasificar amenazas conocidas en un entorno de laboratorio, no crear ni ocultar código dañino.

1. Qué es YARA y para qué sirve

YARA es un motor de reconocimiento de patrones orientado a ficheros. Se le describe a menudo como «el navaja suiza para clasificar malware»: tú escribes reglas —descripciones textuales de lo que caracteriza a una muestra— y el motor las evalúa contra ficheros, procesos en memoria o volcados. Si una regla encaja, YARA lo reporta junto con el nombre de la regla y, opcionalmente, sus metadatos.

Su fuerza está en el punto medio que ocupa. Un hash MD5 o SHA-256 solo detecta un fichero exacto: cambia un byte y ya no sirve. Una firma de red o de comportamiento es potente pero cara de construir. YARA permite capturar lo que no cambia entre variantes de una misma familia: cadenas de configuración, rutinas de descifrado, mensajes de error del propio malware, artefactos del empaquetador. Una buena regla sobrevive a recompilaciones y a cambios menores del atacante.

2. Anatomía de una regla

Una regla YARA tiene siempre la misma estructura: la palabra clave rule, un identificador, y entre llaves hasta tres secciones. Solo condition es obligatoria.

rule Ejemplo_Downloader_Lab
{
    meta:
        author      = "analista.lab"
        description = "Detecta el downloader de practica de la serie (muestra de laboratorio)"
        date        = "2026-08-27"
        reference   = "informe interno LAB-014"
        hash        = "e3b0c44298fc1c149afbf4c8996fb924..."
        tlp         = "AMBER"
 
    strings:
        $ua   = "Mozilla/4.0 (compatible; LabDL)" ascii
        $cfg  = "cfg_server=" ascii wide
        $mtx  = "Global\\lab_dl_mutex_01" ascii
        $xor  = { 8A 04 0A 34 5A 88 04 0A 42 3B D1 7C F4 }
 
    condition:
        uint16(0) == 0x5A4D and filesize < 500KB
        and 3 of ($ua, $cfg, $mtx, $xor)
}

2.1 La sección meta

meta guarda información descriptiva que no afecta a la detección pero es imprescindible para operar: autor, descripción, fecha, referencia al informe de origen, hash de la muestra de partida y nivel TLP para compartir. Cuando una regla salta a las tres de la mañana, estos campos son lo que permite al analista de guardia entender qué ha encontrado y cómo de fiable es.

2.2 La sección strings

Aquí se declaran los patrones. Cada uno lleva un identificador que empieza por $. Hay tres tipos:

• Cadenas de texto: entre comillas dobles. Admiten modificadores como ascii, wide (UTF-16, habitual en binarios Windows), nocase (ignora mayúsculas), fullword (solo si no está pegada a otros caracteres alfanuméricos) y xor (busca la cadena aplicada con cualquier clave XOR de un byte, útil para configuraciones ofuscadas de forma trivial)
• Cadenas hexadecimales: entre llaves, en bytes. Permiten comodines (?? ), rangos de saltos ([4-6] = de 4 a 6 bytes cualesquiera) y alternativas (( 45 | 46 )). Sirven para capturar fragmentos de código, cabeceras o estructuras
• Expresiones regulares: entre barras, /patron/. Muy expresivas pero más lentas; conviene anclarlas y evitar cuantificadores abiertos

2.3 La sección condition

condition es una expresión booleana que decide si la regla encaja. Puede referirse a los strings (por nombre, o en conjunto), al tamaño del fichero, a offsets concretos y a los módulos. Ejemplos habituales:

3. Módulos: reglas más precisas

YARA se amplía con módulos que exponen datos estructurados del fichero. Los más usados en detección de malware:

• pe: da acceso a la cabecera PE. Permite condiciones como pe.number_of_sections == 3, pe.imphash() (hash de la tabla de importaciones, muy útil para agrupar variantes), pe.sections[0].name == «.text», timestamp de compilación, recursos, firma Authenticode o exports concretos
• hash: calcula MD5/SHA-1/SHA-256 de un rango del fichero dentro de la condición, por ejemplo hash.sha256(0, filesize) == «…» o el hash de una sección concreta
• math: entropía y otras métricas; math.entropy(0, filesize) > 7.0 señala ficheros muy probablemente cifrados o empaquetados
• elf, dotnet, magic: equivalentes para binarios Linux, ensamblados .NET e identificación de tipo por libmagic

import "pe"
import "math"
 
rule Packed_PE_Lab_Heuristic
{
    meta:
        description = "Heuristica: PE con seccion de alta entropia (lab)"
    condition:
        uint16(0) == 0x5A4D
        and pe.number_of_sections >= 1
        and for any i in (0..pe.number_of_sections - 1):
            ( math.entropy(pe.sections[i].raw_data_offset,
                           pe.sections[i].raw_data_size) > 7.2 )
}

4. Ejecutar reglas con la CLI

El binario yara evalúa uno o varios ficheros de reglas contra ficheros, carpetas o procesos. Órdenes básicas, siempre sobre muestras de un laboratorio aislado:

# Una regla contra una carpeta de muestras, de forma recursiva
yara -r reglas/downloader.yar  /lab/muestras/
 
# Varias reglas, mostrando los strings que han encajado
yara -s -r reglas/  /lab/muestras/sospechoso.bin
 
# Mostrar tambien los metadatos de la regla que salta
yara -m -r reglas/  /lab/muestras/
 
# Escanear la memoria de un proceso por PID (en la VM de analisis)
yara reglas/implant_memoria.yar  1337
 
# Comprobar que un fichero de reglas compila sin errores
yara -w -f reglas/nueva.yar  /dev/null

En Python, la librería yara-python permite compilar reglas una vez y reutilizarlas: rules = yara.compile(filepath=’reglas.yar’) y luego rules.match(‘/lab/muestra.bin’). Es la base de la mayoría de integraciones.

5. Integración con otras herramientas

6. Buenas prácticas para no ahogarte en falsos positivos

• Prueba contra un goodware set: antes de desplegar una regla, evalúala contra una colección de software legítimo (un Windows limpio, instaladores comunes, tus propias herramientas). Cero coincidencias es el objetivo
• Ancla con la cabecera y el tamaño: empezar por uint16(0) == 0x5A4D and filesize < N evita que la regla se dispare con logs, documentos o volcados que casualmente contienen tus bytes
• Prefiere condiciones ‘x of’ a cadenas de ‘or’: exigir 3 de 5 strings específicas es mucho más robusto que cualquiera de ellas por separado
• Una familia por regla, un propósito claro: no metas cinco familias en una regla gigante. Nombres descriptivos y consistentes (Familia_Tipo_Variante)
• Versiona y revisa: guarda las reglas en un repositorio, revisa las que más saltan y ajústalas o retíralas. Una regla con 10.000 hits al día no está detectando, está molestando
• Cuidado con las expresiones regulares: son lentas y fáciles de escribir mal. Úsalas solo cuando una cadena hexadecimal con comodines no baste
• Documenta la muestra de origen en meta: sin ella, dentro de seis meses nadie sabrá si la regla sigue siendo válida

Conclusión

YARA no detecta malware por arte de magia: detecta exactamente lo que tú le describes. El valor de una regla depende por completo de la calidad del análisis previo y de la disciplina al escribir la condición. Strings genéricas y ‘or’ encadenados producen ruido; artefactos específicos combinados con un ancla de cabecera y un límite de tamaño producen detección fiable.

Empieza en pequeño: coge una muestra de laboratorio, identifica tres o cuatro cadenas que solo aparezcan en ella, escribe la regla, pruébala contra software legítimo hasta que dé cero falsos positivos, y solo entonces incorpórala a tu escáner. Repetir ese ciclo unas cuantas veces es la forma más rápida de aprender a pensar como un analista de detección.

unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)