YARA Avanzado: Módulos PE, Math, Hash y Técnicas de Hunting Profesional

De strings a estructura: por que los modulos cambian todo

Las reglas YARA basadas en strings son el punto de partida. Funcionan, detectan familias conocidas, cubren el 80% de los casos. Pero cuando el adversario ofusca strings, empaqueta el binario o genera builds polimorficos, las reglas de texto plano fallan. Los modulos de YARA permiten analizar la estructura del archivo: sus imports, secciones, entropia, metadatos .NET, firmas de compilador. Son propiedades que el atacante no puede cambiar sin recompilar desde cero.

Un analista que domina los modulos PE, Math y Hash pasa de "detecto esta muestra" a "detecto esta tecnica de compilacion", que es exactamente la diferencia entre IOC matching y threat hunting real.

Modulo PE: anatomia de un ejecutable Windows

El modulo pe es el mas rico de YARA. Expone toda la estructura del formato Portable Executable: cabeceras, secciones, imports, exports, recursos, timestamps, certificados y la rich signature del compilador.

Para usarlo, declara import "pe" al inicio de la regla.

Imports: que APIs llama el binario

Los imports revelan las capacidades del ejecutable. Un programa que importa VirtualAllocEx, WriteProcessMemory y CreateRemoteThread tiene capacidad de inyeccion de procesos. Un programa que importa CryptEncrypt y FindFirstFileW podria ser ransomware.

import "pe"

rule Suspicious_Process_Injection_Imports
{
    meta:
        author      = "MalwareIntel Research"
        description = "Detecta ejecutables con combinacion de imports tipica de process injection"
        mitre       = "T1055.001, T1055.012"
        date        = "2026-06-05"
        severity    = "high"

    condition:
        pe.imports("kernel32.dll", "VirtualAllocEx") and
        pe.imports("kernel32.dll", "WriteProcessMemory") and
        pe.imports("kernel32.dll", "CreateRemoteThread") and
        pe.number_of_sections >= 3 and
        pe.number_of_sections <= 8
}

La funcion pe.imports() acepta el nombre de la DLL y la funcion. Es case-insensitive para la DLL pero sensible para el nombre de la funcion. Puedes combinar multiples imports en la condicion con operadores logicos.

Algunas combinaciones de imports que merecen atencion:

Combinacion	Tecnica probable	MITRE
VirtualAllocEx + WriteProcessMemory + CreateRemoteThread	Classic DLL injection	T1055.001
NtMapViewOfSection + NtUnmapViewOfSection	Section-based injection	T1055.012
SetWindowsHookEx + GetAsyncKeyState	Keylogger	T1056.001
CryptEncrypt + FindFirstFileW + MoveFileW	Ransomware	T1486
InternetOpenA + InternetConnectA + HttpSendRequestA	HTTP C2	T1071.001
RegSetValueExA + RegCreateKeyExA (Run keys)	Persistence via registry	T1547.001

Secciones: nombres, tamanos y permisos

Las secciones de un PE revelan packing, inyeccion de codigo y anomalias de compilador. Un ejecutable normal compilado con Visual Studio tiene secciones .text, .rdata, .data, .rsrc. Un binario empaquetado con UPX tiene secciones UPX0, UPX1, UPX2.

import "pe"

rule PE_Suspicious_Section_Names
{
    meta:
        author      = "MalwareIntel Research"
        description = "Detecta secciones PE con nombres asociados a packers conocidos"
        date        = "2026-06-05"

    condition:
        pe.number_of_sections > 0 and
        for any section in pe.sections : (
            section.name == "UPX0" or
            section.name == "UPX1" or
            section.name == ".ndata" or
            section.name == ".themida" or
            section.name == ".vmp0" or
            section.name == ".vmp1" or
            section.name == ".enigma" or
            section.name == ".aspack"
        )
}

Tambien puedes verificar los permisos de las secciones. Una seccion con permisos de lectura, escritura y ejecucion (RWX) es sospechosa: el codigo legitimo raramente necesita las tres a la vez.

import "pe"

rule PE_Section_RWX
{
    meta:
        description = "Seccion PE con permisos Read-Write-Execute (sospechoso)"

    condition:
        for any section in pe.sections : (
            (section.characteristics & 0xE0000000) == 0xE0000000
        )
}

El valor 0xE0000000 combina los flags IMAGE_SCN_MEM_READ (0x40000000), IMAGE_SCN_MEM_WRITE (0x80000000) e IMAGE_SCN_MEM_EXECUTE (0x20000000).

Rich signature e imphash

La rich signature es un bloque de datos que Visual Studio inserta en la cabecera PE antes del PE header. Contiene informacion sobre las versiones del compilador y linker usadas. Dos muestras compiladas con el mismo proyecto de Visual Studio comparten la misma rich signature, lo que permite agrupar builds de la misma campana.

import "pe"

rule Rich_Signature_Known_Campaign
{
    meta:
        description = "Rich signature hash asociado a campana conocida"
        campaign    = "OpSolarNight"

    condition:
        pe.rich_signature.toolid(259, 30729) and
        pe.rich_signature.toolid(261, 30729)
}

El imphash (import hash) es un hash MD5 de la tabla de imports ordenada. Es util para agrupar variantes que importan las mismas funciones en el mismo orden, incluso si el codigo cambia:

import "pe"

rule Known_Imphash_Cobalt_Strike_Beacon
{
    meta:
        description = "Imphash conocido de Cobalt Strike beacon default"

    condition:
        pe.imphash() == "17b461a082950fc6332228572138b80c"
}

Timestamps y anomalias de compilacion

El campo pe.timestamp contiene la fecha de compilacion declarada. Los atacantes a menudo falsifican este valor (timestomping). Detectar timestamps anomalos es una tecnica de hunting efectiva:

import "pe"

rule PE_Future_Timestamp
{
    meta:
        description = "PE con timestamp de compilacion en el futuro"
        mitre       = "T1070.006"

    condition:
        pe.timestamp > 1780000000  // Aproximadamente 2026-06
}

Un timestamp de 0 o un valor en los anos 70 (antes de que existiera el formato PE) tambien es sospechoso.

Recursos embebidos

El modulo PE permite inspeccionar los recursos embebidos, que el malware usa frecuentemente para almacenar configuraciones cifradas, payloads secundarios o datos exfiltrados:

import "pe"

rule PE_Large_Resource_Suspicious
{
    meta:
        description = "PE con un recurso embebido inusualmente grande (posible payload)"

    condition:
        for any resource in pe.resources : (
            resource.length > 500000  // > 500KB en un recurso individual
        )
}

Modulo Math: entropia como detector universal

El modulo math proporciona funciones matematicas, siendo entropy() la mas relevante para deteccion de malware. La entropia de Shannon mide la aleatoriedad de los datos en una escala de 0.0 a 8.0:

Rango de entropia	Contenido tipico
0.0 - 1.0	Datos repetitivos (nulls, padding)
1.0 - 4.0	Texto plano, codigo fuente, XML
4.0 - 6.0	Codigo compilado normal, DLLs
6.0 - 7.0	Datos comprimidos ligeros, multimedia
7.0 - 7.5	Datos comprimidos (ZIP, gzip), packed
7.5 - 8.0	Cifrado fuerte (AES, ChaCha20), random

Entropia global del archivo

import "math"

rule High_Entropy_Binary
{
    meta:
        description = "Binario con entropia global superior a 7.0 (probable packing o cifrado)"

    condition:
        math.entropy(0, filesize) > 7.0
}

Esta regla es demasiado amplia por si sola (detectaria archivos ZIP, imagenes comprimidas, etc.). Se vuelve util al combinarla con el modulo PE:

import "pe"
import "math"

rule Packed_PE_High_Entropy
{
    meta:
        author      = "MalwareIntel Research"
        description = "Ejecutable PE con entropia global alta, indicativo de packing"
        mitre       = "T1027.002"
        date        = "2026-06-05"
        severity    = "medium"

    condition:
        uint16(0) == 0x5A4D and
        filesize < 5MB and
        math.entropy(0, filesize) > 7.0 and
        pe.number_of_sections < 5
}

Entropia por seccion

El verdadero poder esta en calcular la entropia de secciones individuales. Un ejecutable puede tener entropia global normal (6.0) pero una seccion .rsrc con entropia 7.8, lo que indica un payload cifrado embebido en los recursos:

import "pe"
import "math"

rule PE_Section_High_Entropy
{
    meta:
        description = "PE con al menos una seccion con entropia > 7.2"
        mitre       = "T1027.002"

    condition:
        pe.number_of_sections > 0 and
        for any section in pe.sections : (
            math.entropy(section.raw_data_offset, section.raw_data_size) > 7.2
        )
}

Deteccion de secciones con entropia anomala combinada

Una tecnica avanzada es buscar la diferencia entre el tamano virtual y el tamano raw de una seccion. Un packer tipico crea una seccion con tamano virtual grande pero tamano raw pequeno (el codigo se descomprime en memoria):

import "pe"
import "math"

rule Packer_Section_Size_Anomaly
{
    meta:
        description = "Seccion PE con tamano virtual >> tamano raw y entropia alta"

    condition:
        for any section in pe.sections : (
            section.virtual_size > section.raw_data_size * 3 and
            section.raw_data_size > 0 and
            math.entropy(section.raw_data_offset, section.raw_data_size) > 6.8
        )
}

Funcion math.in_range()

La funcion math.in_range() cuenta cuantos bytes en un rango caen dentro de un intervalo de valores. Es util para detectar shellcode (que tiene distribucion de bytes diferente al codigo compilado normal) o para verificar si una seccion contiene mayoritariamente bytes nulos:

import "math"

rule Possible_Shellcode_Nop_Sled
{
    meta:
        description = "Bloque grande de NOPs (0x90) seguido de codigo"

    condition:
        math.in_range(
            math.count(0x90, 0, 4096),
            200, 4096
        )
}

Modulo Hash: fingerprinting granular

El modulo hash permite calcular hashes de regiones arbitrarias del archivo, no solo del archivo completo. Esto permite:

• Comparar secciones individuales entre muestras
• Detectar overlay data (datos anadidos al final del PE)
• Verificar integridad de recursos embebidos

import "pe"
import "hash"

rule Known_Malicious_Code_Section
{
    meta:
        description = "Hash MD5 conocido de la seccion .text de una familia especifica"

    condition:
        for any section in pe.sections : (
            section.name == ".text" and
            hash.md5(section.raw_data_offset, section.raw_data_size) == "a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6"
        )
}

El modulo soporta hash.md5(), hash.sha1(), hash.sha256() y hash.crc32(). Cada funcion acepta un offset y un tamano como parametros.

Deteccion de overlay data

El overlay es contenido anadido al final del PE, mas alla de la ultima seccion. El malware lo usa para almacenar configuraciones, payloads cifrados o datos de staging:

import "pe"
import "math"

rule PE_Overlay_High_Entropy
{
    meta:
        description = "PE con datos overlay de alta entropia (posible payload cifrado)"

    condition:
        pe.overlay.offset > 0 and
        pe.overlay.size > 10000 and
        math.entropy(pe.overlay.offset, pe.overlay.size) > 7.0
}

Modulo Dotnet: metadata de ensamblados .NET

El modulo dotnet expone metadatos de ensamblados .NET: nombre del assembly, version, GUID del modulo, streams y recursos .NET. Es esencial para detectar familias escritas en C# como RedLine, AsyncRAT, QuasarRAT y Agent Tesla.

import "dotnet"

rule Dotnet_Suspicious_Assembly
{
    meta:
        description = "Ensamblado .NET con nombre de assembly sospechoso"

    condition:
        dotnet.assembly.name == "Client" or
        dotnet.assembly.name == "Stub" or
        dotnet.assembly.name == "Payload" or
        dotnet.assembly.name == "Bot" or
        dotnet.assembly.name == "Loader"
}

Puedes inspeccionar los streams .NET para detectar ofuscadores conocidos:

import "dotnet"

rule Dotnet_ConfuserEx_Obfuscated
{
    meta:
        description = "Ensamblado .NET ofuscado con ConfuserEx"

    condition:
        for any stream in dotnet.streams : (
            stream.name == "#Koi"
        )
}

El stream #Koi es especifico de ConfuserEx. Otros ofuscadores tienen sus propios marcadores: #Babel (Babel Obfuscator), SmartAssembly en recursos, etc.

GUID del modulo como fingerprint

El GUID del modulo .NET (dotnet.module_name y el typelib_id) es unico por build. Si tienes un GUID de una muestra confirmada, puedes buscar otras compilaciones del mismo proyecto:

import "dotnet"

rule Dotnet_Known_GUID_AsyncRAT
{
    meta:
        description = "GUID de modulo asociado a builds conocidos de AsyncRAT"

    condition:
        dotnet.typelib("b7052d73-fd80-4f50-8a70-7c38a3e10003")
}

Modulo Console: logging y debugging de reglas

El modulo console no detecta malware directamente. Sirve para depurar reglas complejas imprimiendo valores intermedios durante el escaneo:

import "pe"
import "math"
import "console"

rule Debug_Entropy_Check
{
    meta:
        description = "Regla de depuracion: imprime entropia por seccion"

    condition:
        pe.number_of_sections > 0 and
        for any section in pe.sections : (
            console.log("Section: ", section.name) and
            console.log("  Entropy: ", math.entropy(section.raw_data_offset, section.raw_data_size)) and
            console.log("  Raw size: ", section.raw_data_size) and
            math.entropy(section.raw_data_offset, section.raw_data_size) > 7.0
        )
}

El modulo console acepta console.log() con strings y valores numericos. Cada llamada a console.log() siempre devuelve true, por lo que puedes encadenarla con and sin afectar la logica de la condicion.

Es especialmente util cuando una regla deberia matchear pero no lo hace. Imprimiendo los valores intermedios, puedes identificar que condicion falla.

Condiciones avanzadas

Expresiones for

Las expresiones for permiten iterar sobre conjuntos de strings o elementos de modulos. Son fundamentales para escribir condiciones flexibles:

rule For_Expression_Examples
{
    strings:
        $s1 = "CreateProcess"
        $s2 = "VirtualAlloc"
        $s3 = "WriteProcessMemory"
        $s4 = "NtUnmapViewOfSection"
        $s5 = "SetThreadContext"

    condition:
        // Al menos 3 de las 5 strings
        3 of ($s*)

        // Equivalente con for:
        // for 3 of ($s*) : ( $ )

        // Al menos 2 strings en los primeros 1024 bytes
        // for 2 of ($s*) : ( @ < 1024 )
}

Dependencias entre reglas y reglas privadas

Una regla puede referenciar el resultado de otra regla en su condicion. Esto permite construir detecciones en capas:

import "pe"
import "math"

private rule Is_PE_File
{
    condition:
        uint16(0) == 0x5A4D and
        uint32(uint32(0x3C)) == 0x00004550
}

private rule Has_High_Entropy_Section
{
    condition:
        Is_PE_File and
        for any section in pe.sections : (
            math.entropy(section.raw_data_offset, section.raw_data_size) > 7.2
        )
}

rule Packed_Executable_With_Injection_Capability
{
    meta:
        author      = "MalwareIntel Research"
        description = "PE empaquetado con imports de inyeccion de procesos"
        mitre       = "T1027.002, T1055"
        severity    = "high"

    condition:
        Has_High_Entropy_Section and
        pe.imports("kernel32.dll", "VirtualAllocEx") and
        pe.imports("kernel32.dll", "WriteProcessMemory")
}

Las reglas marcadas como private no generan alertas por si solas. Solo sirven como building blocks para otras reglas. Esto mantiene limpia la salida del scanner.

Include para organizar reglas

La directiva include permite dividir reglas en archivos modulares:

include "rules/common/pe_checks.yar"
include "rules/common/entropy_checks.yar"
include "rules/families/emotet.yar"
include "rules/families/lockbit.yar"

Esta estructura es la norma en repositorios profesionales como signature-base de Florian Roth o las reglas de ESET.

Optimizacion de rendimiento

Cuando escaneas miles de archivos o usas YARA en produccion (endpoint agents, pipelines de ingesta), el rendimiento importa. Estas son las practicas clave:

1. Condiciones PE antes que strings

El motor YARA evalua las condiciones de izquierda a derecha con short-circuit. Coloca las comprobaciones rapidas (magic bytes, filesize, modulos) antes que las busquedas de strings:

// MAL: busca strings primero, luego verifica que es PE
rule Slow_Rule
{
    strings:
        $s1 = { 48 8B 05 ?? ?? ?? ?? 48 85 C0 }
    condition:
        $s1 and uint16(0) == 0x5A4D
}

// BIEN: verifica PE primero, luego busca strings
rule Fast_Rule
{
    strings:
        $s1 = { 48 8B 05 ?? ?? ?? ?? 48 85 C0 }
    condition:
        uint16(0) == 0x5A4D and filesize < 10MB and $s1
}

2. Limitar filesize siempre

Sin limite de tamano, YARA procesara archivos de cualquier tamano, incluidos ISOs de 4GB o bases de datos. Anade siempre una restriccion de filesize razonable:

condition:
    filesize < 10MB and  // La mayoria de malware PE < 10MB
    ...

3. Strings hexadecimales con wildcards controlados

Los wildcards ?? en patrones hexadecimales son costosos. Cada ?? multiplica el espacio de busqueda. Limita su uso y combinalo con anclas conocidas:

// COSTOSO: muchos wildcards seguidos
$hex = { 48 ?? ?? ?? ?? ?? ?? ?? 48 85 C0 }

// MEJOR: menos wildcards, mas bytes fijos
$hex = { 48 8B 05 ?? ?? ?? ?? 48 85 C0 }

4. Evitar regex complejas

Las expresiones regulares de YARA son potentes pero lentas. Prefiere strings literales o hexadecimales cuando sea posible. Si necesitas regex, usa anclas (^, $) y limita la repeticion.

5. Module caching

Cuando una regla usa multiples condiciones del modulo PE, YARA parsea el PE una sola vez y cachea los resultados. Agrupar reglas que usan el mismo modulo en el mismo archivo mejora la eficiencia del cache.

Patrones de hunting profesional

Patron 1: Detectar binarios empaquetados (completo)

import "pe"
import "math"

rule HUNT_Packed_Binary_Comprehensive
{
    meta:
        author      = "MalwareIntel Research"
        description = "Deteccion integral de binarios empaquetados: entropia + nombres de seccion + anomalias de tamano"
        mitre       = "T1027.002"
        date        = "2026-06-05"
        severity    = "medium"
        hunt_type   = "packing_detection"

    condition:
        uint16(0) == 0x5A4D and
        filesize < 10MB and
        pe.number_of_sections > 0 and
        (
            // Criterio 1: entropia global alta
            math.entropy(0, filesize) > 7.0 or

            // Criterio 2: nombre de seccion de packer conocido
            for any section in pe.sections : (
                section.name == "UPX0" or
                section.name == "UPX1" or
                section.name == ".themida" or
                section.name == ".vmp0" or
                section.name == ".vmp1" or
                section.name == ".enigma" or
                section.name == ".aspack" or
                section.name == ".nsp0" or
                section.name == ".nsp1"
            ) or

            // Criterio 3: seccion con virtual_size >> raw_size y entropia alta
            for any section in pe.sections : (
                section.virtual_size > section.raw_data_size * 5 and
                section.raw_data_size > 0 and
                section.raw_data_size < 1000 and
                math.entropy(section.raw_data_offset, section.raw_data_size) > 6.5
            ) or

            // Criterio 4: seccion RWX con entropia alta
            for any section in pe.sections : (
                (section.characteristics & 0xE0000000) == 0xE0000000 and
                section.raw_data_size > 1000 and
                math.entropy(section.raw_data_offset, section.raw_data_size) > 6.8
            )
        )
}

Patron 2: Detectar timestomping

import "pe"

rule HUNT_Timestomping_Anomaly
{
    meta:
        author      = "MalwareIntel Research"
        description = "PE con timestamp de compilacion anomalo: futuro, epoch cero o demasiado antiguo"
        mitre       = "T1070.006"
        date        = "2026-06-05"
        severity    = "low"
        hunt_type   = "timestomping"

    condition:
        uint16(0) == 0x5A4D and
        (
            // Timestamp en el futuro (post junio 2026)
            pe.timestamp > 1780000000 or

            // Timestamp epoch cero (claramente falso)
            pe.timestamp == 0 or

            // Timestamp anterior a 1995 (antes de Windows 95, PE no existia en uso real)
            pe.timestamp < 788918400 or

            // Timestamp exacto en medianoche UTC (sospechoso, poco natural)
            pe.timestamp % 86400 == 0
        )
}

Patron 3: Detectar secciones anomalas

import "pe"
import "math"

rule HUNT_Anomalous_PE_Sections
{
    meta:
        author      = "MalwareIntel Research"
        description = "PE con secciones anomalas: nombres no estandar, permisos sospechosos, o entropia inusual"
        mitre       = "T1027"
        date        = "2026-06-05"
        severity    = "medium"
        hunt_type   = "section_anomaly"

    condition:
        uint16(0) == 0x5A4D and
        filesize < 15MB and
        pe.number_of_sections > 0 and
        (
            // Mas de 2 secciones con permisos RWX
            for 2 section in pe.sections : (
                (section.characteristics & 0xE0000000) == 0xE0000000
            ) or

            // Seccion .text con entropia > 7.0 (deberia ser codigo, no datos cifrados)
            for any section in pe.sections : (
                section.name == ".text" and
                section.raw_data_size > 0 and
                math.entropy(section.raw_data_offset, section.raw_data_size) > 7.0
            ) or

            // Seccion con nombre de un solo caracter (muchos packers custom)
            for any section in pe.sections : (
                section.name matches /^\..$/ or
                section.name matches /^[a-z]$/
            ) or

            // Seccion con raw_data_size de 0 pero virtual_size > 100KB
            for any section in pe.sections : (
                section.raw_data_size == 0 and
                section.virtual_size > 100000
            )
        )
}

Patron 4: Detectar binarios sin firma digital

Los ejecutables legitimos de software comercial casi siempre estan firmados digitalmente. Un ejecutable que pretende ser de Microsoft, Adobe o Google pero no tiene firma es sospechoso:

import "pe"

rule HUNT_Unsigned_Impersonating_Known_Vendor
{
    meta:
        author      = "MalwareIntel Research"
        description = "PE sin firma digital que contiene strings de vendedor conocido en version info"
        mitre       = "T1036.005"
        date        = "2026-06-05"
        severity    = "high"
        hunt_type   = "masquerading"

    strings:
        $vendor1 = "Microsoft Corporation" ascii wide
        $vendor2 = "Adobe Systems" ascii wide
        $vendor3 = "Google LLC" ascii wide
        $vendor4 = "Mozilla Corporation" ascii wide
        $vendor5 = "Apple Inc" ascii wide

    condition:
        uint16(0) == 0x5A4D and
        filesize < 50MB and
        pe.number_of_signatures == 0 and
        any of ($vendor*)
}

YARA-X: la reescritura en Rust

YARA-X es el proyecto de reescritura de YARA desde cero en Rust, liderado por Victor Manuel Alvarez (el creador original de YARA) dentro de VirusTotal/Google. No es un fork: es una reimplementacion completa que mantiene compatibilidad con las reglas existentes.

Mejoras clave

Rendimiento: YARA-X es consistentemente 2-3x mas rapido que YARA 4.x en benchmarks de escaneo masivo. La diferencia es mas notable con reglas que usan modulos PE y Math intensivamente.

Mensajes de error: YARA clasico devuelve errores cripticos. YARA-X genera mensajes detallados que indican la linea exacta, el problema y una sugerencia de correccion. Esto reduce drasticamente el tiempo de depuracion de reglas complejas.

Seguridad de memoria: Al estar escrito en Rust, YARA-X elimina categorias completas de bugs (buffer overflows, use-after-free) que han afectado a YARA en el pasado.

Compatibilidad: Las reglas que usan modulos estandar (pe, math, hash, dotnet, elf, macho) funcionan sin modificaciones. Algunas funciones poco documentadas o comportamientos no especificados pueden diferir, pero el 99% de las reglas migran sin cambios.

Modulos adicionales en YARA-X

YARA-X introduce modulos nuevos que no existen en YARA clasico:

• lnk: parsea archivos de acceso directo de Windows (.lnk), utiles para detectar phishing
• text: funciones de manipulacion de texto avanzadas
• Mejoras en el modulo pe: soporte mas robusto para PE malformados (que el malware usa intencionalmente)

Estado actual

A fecha de 2026, YARA-X es production-ready y se usa internamente en VirusTotal. La adopcion externa crece: herramientas como LOKI y Thor estan anadiendo soporte. La recomendacion para proyectos nuevos es empezar directamente con YARA-X. Para proyectos existentes, la migracion es transparente en la mayoria de casos.

Mapeo MITRE ATT&CK

Las reglas y patrones de este articulo cubren las siguientes tecnicas:

Tecnica	Nombre	Contexto en este articulo
T1027	Obfuscated Files or Information	Entropia alta, secciones anomalas
T1027.002	Software Packing	Deteccion de packers por seccion y entropia
T1055.001	DLL Injection	Imports de VirtualAllocEx + WriteProcessMemory
T1055.012	Process Hollowing	Imports de NtUnmapViewOfSection
T1070.006	Timestomp	Timestamps PE anomalos
T1036.005	Match Legitimate Name or Location	Binarios sin firma que impersonan vendors
T1486	Data Encrypted for Impact	Imports de CryptEncrypt + FindFirstFile
T1056.001	Keylogging	Imports de SetWindowsHookEx
T1547.001	Registry Run Keys	Imports de RegSetValueEx

Recursos y referencias

Documentacion oficial de modulos YARA:

• YARA Documentation: Modules: referencia completa de todos los modulos con ejemplos
• YARA-X GitHub: repositorio oficial de la reescritura en Rust
• PE Module Reference: documentacion detallada del modulo PE

Reglas YARA profesionales:

• signature-base (Florian Roth): reglas de deteccion de alta calidad que usan modulos PE y Math extensivamente
• YARA-Rules Community: repositorio comunitario organizado por categoria
• ReversingLabs YARA Rules: reglas orientadas a certificate abuse y packing

Herramientas:

• LOKI: scanner YARA para endpoints con soporte de modulos
• yarAnalyzer: analiza el rendimiento de tus reglas YARA e identifica cuellos de botella
• pe-tree: visualizador de estructura PE (util para entender que inspecciona el modulo PE)
• pestudio: analizador estatico de PE para Windows, complementa el analisis con YARA

Entropia y packing:

• Detecting packed executables (SANS): white papers sobre deteccion de packing por entropia
• PE format specification (Microsoft): especificacion oficial del formato PE