YARA para Ransomware: Reglas de Detección por Familia y Comportamiento

El reto de detectar ransomware con YARA

El ransomware moderno es un objetivo complejo para la detección basada en patrones. Las familias evolucionan rápido, cambian de infraestructura entre campañas y adoptan técnicas de ofuscación avanzadas. LockBit 3.0 introdujo un builder que permite a cada afiliado generar binarios con configuraciones únicas. BlackCat/ALPHV compiló su payload en Rust, un lenguaje que produce binarios con estructura radicalmente distinta a los ejecutables C/C++ tradicionales. Cada nueva variante desafía las firmas estáticas.

Pero YARA sigue siendo una herramienta fundamental en la detección de ransomware por tres razones:

1. Velocidad de despliegue. Una regla YARA se escribe, se prueba y se despliega en minutos. No requiere actualizar un motor antivirus ni esperar al vendor.
2. Complementariedad. YARA detecta el artefacto (el binario en disco o en memoria). Sigma detecta el comportamiento (los eventos en logs). Juntas cubren el ciclo completo.
3. Hunting retroactivo. Con Retrohunt en VirusTotal o escaneos sobre repositorios de malware, una regla YARA encuentra variantes pasadas que nadie clasificó correctamente.

Este artículo presenta seis reglas YARA completas, organizadas en dos bloques: reglas específicas por familia (LockBit 3.0, BlackCat/ALPHV) y reglas genéricas por comportamiento (notas de rescate, shadow copies, cifrado, configuraciones). Cada regla incluye explicación línea a línea y consejos de hunting.

Regla 1: LockBit 3.0 (strings específicos)

LockBit 3.0 (también conocido como LockBit Black) es la iteración más reciente del ransomware que dominó el panorama de amenazas entre 2022 y 2024. Su builder filtrado permitió que múltiples actores generaran variantes, pero ciertos strings persisten en la mayoría de builds.

rule Ransomware_LockBit3_Strings {
    meta:
        description = "Detecta LockBit 3.0/Black por strings de nota de rescate y mutex"
        author = "MalwareIntel Research"
        date = "2026-06-05"
        reference = "https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-075a"
        tlp = "TLP:WHITE"
        severity = "critical"
        mitre_attack = "T1486"
        family = "LockBit 3.0"

    strings:
        // Fragmentos de la nota de rescate (persistentes entre builds)
        $ransom_note1 = "your data are stolen and encrypted" ascii wide nocase
        $ransom_note2 = "the data will be published on TOR" ascii wide nocase
        $ransom_note3 = "lockbitapt" ascii wide nocase

        // URLs del leak site (variantes .onion)
        $onion1 = "lockbit" ascii wide
        $onion2 = ".onion" ascii wide

        // Nombres de fichero de la nota
        $note_file1 = "Restore-My-Files.txt" ascii wide nocase
        $note_file2 = ".README.txt" ascii wide

        // Mutex y strings internos
        $mutex1 = "Global\\{" ascii wide
        $internal1 = "LockBit_Internal" ascii wide
        $internal2 = "lockbit3" ascii nocase

        // Comando de eliminacion de shadow copies
        $shadow_cmd = "vssadmin delete shadows /all /quiet" ascii wide nocase

        // Extension de cifrado (configurable pero patron comun)
        $ext_pattern = /\.[a-zA-Z0-9]{8,9}/ ascii

    condition:
        uint16(0) == 0x5A4D and
        filesize < 5MB and
        (
            (2 of ($ransom_note*)) or
            (1 of ($internal*) and $shadow_cmd) or
            ($onion1 and $onion2 and 1 of ($note_file*)) or
            (3 of them)
        )
}

Explicacion y ajuste

La regla combina cuatro vías de detección para maximizar cobertura sin disparar falsos positivos:

• Nota de rescate. Dos fragmentos de tres son suficientes. Los textos de la nota son estables entre builds porque los afiliados rara vez los modifican por completo.
• Strings internos + shadow copies. La combinación de un string interno de LockBit con el comando vssadmin es un indicador fuerte. El comando solo no bastaría (es legítimo en scripts de backup).
• Leak site + nota. La referencia a .onion combinada con el nombre del fichero de la nota ancla la detección a la infraestructura del grupo.
• Umbral genérico. Tres de cualquier string como red de seguridad para variantes que modifican parcialmente los patrones.

Tip de hunting: Usa esta regla en Retrohunt de VirusTotal para identificar builds del builder filtrado que no fueron clasificados como LockBit. Filtra resultados por first_submission_date para encontrar variantes recientes.

Regla 2: BlackCat/ALPHV (patrones Rust)

BlackCat/ALPHV fue el primer ransomware de alto perfil escrito en Rust. Esto le da ventajas: compilación cruzada para Windows/Linux/ESXi, menos detecciones por AV y estructura binaria distinta. Pero también deja patrones detectables en los binarios Rust.

rule Ransomware_BlackCat_ALPHV_Rust {
    meta:
        description = "Detecta BlackCat/ALPHV ransomware por patrones Rust y strings de campaña"
        author = "MalwareIntel Research"
        date = "2026-06-05"
        reference = "https://www.ic3.gov/Media/News/2022/220420.pdf"
        tlp = "TLP:WHITE"
        severity = "critical"
        mitre_attack = "T1486, T1490"
        family = "BlackCat/ALPHV"

    strings:
        // Patrones de runtime Rust en el binario
        $rust_panic1 = "panicked at" ascii
        $rust_panic2 = "rust_begin_unwind" ascii
        $rust_core = "/rustc/" ascii
        $rust_alloc = "alloc::raw_vec::RawVec" ascii

        // Strings especificos de BlackCat
        $bc_note = "RECOVER-" ascii wide
        $bc_ext = ".uhwuvzu" ascii  // extension comun, varia por victima
        $bc_access_token = "--access-token" ascii
        $bc_config = "\"config\":" ascii
        $bc_pub_key = "\"pub_key\":" ascii

        // Algoritmos de cifrado referenciados
        $crypto1 = "AES" ascii wide
        $crypto2 = "ChaCha20" ascii wide
        $crypto3 = "RSA" ascii wide

        // Comandos de propagacion y evasion
        $cmd_esxi1 = "esxcli" ascii
        $cmd_esxi2 = "vm process kill" ascii wide
        $cmd_bcdedit = "bcdedit /set" ascii wide nocase
        $cmd_wmic = "wmic shadowcopy delete" ascii wide nocase

        // Estructura JSON de configuracion embebida (patron hex)
        $json_cfg = { 7B 22 63 6F 6E 66 69 67 22 3A }  // {"config":

    condition:
        (
            // Binario PE de Windows
            (uint16(0) == 0x5A4D and filesize < 10MB) or
            // Binario ELF de Linux
            (uint32(0) == 0x464C457F and filesize < 10MB)
        ) and
        (
            // Via 1: Patrones Rust + strings BlackCat
            (2 of ($rust_*) and 2 of ($bc_*)) or
            // Via 2: Config JSON + crypto + comandos
            ($json_cfg and 1 of ($crypto*) and 1 of ($cmd_*)) or
            // Via 3: Access token CLI (especifico de ALPHV)
            ($bc_access_token and 1 of ($rust_*) and 1 of ($crypto*))
        )
}

Explicacion y ajuste

BlackCat utiliza --access-token como parámetro obligatorio en línea de comandos para descifrar su configuración embebida. Este string, combinado con patrones del runtime Rust, es un indicador de alta fidelidad.

La regla también cubre variantes Linux/ESXi verificando el magic number ELF. Los comandos esxcli y vm process kill son exclusivos de las variantes que atacan hipervisores VMware.

Tip de hunting: Busca binarios ELF con strings Rust y referencias a esxcli en tu repositorio de samples. Las variantes ESXi de BlackCat a menudo pasan desapercibidas porque muchos motores AV no escanean binarios ELF con la misma profundidad que PE.

Regla 3: Deteccion generica de notas de rescate

Las notas de rescate son el artefacto más visible del ransomware. Aunque cada familia tiene su propio texto, existen patrones comunes que permiten detectar notas de rescate genéricas, incluyendo familias nuevas o desconocidas.

rule Ransomware_Generic_RansomNote {
    meta:
        description = "Detecta notas de rescate genéricas por patrones de texto comunes"
        author = "MalwareIntel Research"
        date = "2026-06-05"
        tlp = "TLP:WHITE"
        severity = "high"
        mitre_attack = "T1486"

    strings:
        // Frases de presion comunes en notas de rescate
        $pressure1 = "your files have been encrypted" ascii wide nocase
        $pressure2 = "your data has been stolen" ascii wide nocase
        $pressure3 = "all your files are encrypted" ascii wide nocase
        $pressure4 = "your network has been compromised" ascii wide nocase
        $pressure5 = "your important files" ascii wide nocase

        // Instrucciones de pago
        $payment1 = "bitcoin" ascii wide nocase
        $payment2 = "monero" ascii wide nocase
        $payment3 = "BTC" ascii wide
        $payment4 = "XMR" ascii wide
        $payment5 = "cryptocurrency" ascii wide nocase
        $payment6 = "crypto wallet" ascii wide nocase

        // Instrucciones de contacto
        $contact1 = ".onion" ascii wide
        $contact2 = "tor browser" ascii wide nocase
        $contact3 = "tox" ascii wide nocase
        $contact4 = "protonmail" ascii wide nocase
        $contact5 = "tutanota" ascii wide nocase

        // Amenazas de publicacion
        $threat1 = "publish" ascii wide nocase
        $threat2 = "leak" ascii wide nocase
        $threat3 = "auction" ascii wide nocase
        $threat4 = "exposed" ascii wide nocase

        // Plazos y urgencia
        $deadline1 = "deadline" ascii wide nocase
        $deadline2 = "hours" ascii wide nocase
        $deadline3 = "days to" ascii wide nocase

    condition:
        filesize < 100KB and
        not uint16(0) == 0x5A4D and  // No es un PE (es un fichero de texto)
        (
            (1 of ($pressure*) and 1 of ($payment*) and 1 of ($contact*)) or
            (2 of ($pressure*) and 1 of ($payment*)) or
            (1 of ($pressure*) and 1 of ($threat*) and 1 of ($deadline*))
        )
}

Explicacion y ajuste

Esta regla se enfoca en ficheros de texto (no PE) de menos de 100KB. Los tres caminos de detección cubren los elementos estructurales de cualquier nota de rescate:

• Presión + pago + contacto. La tríada clásica: "tus ficheros están cifrados, paga en Bitcoin, contacta vía Tor".
• Doble presión + pago. Para notas que omiten instrucciones de contacto iniciales.
• Presión + amenaza + plazo. Para notas de doble extorsión que enfatizan la publicación de datos.

Tip de hunting: Ejecuta esta regla contra directorios de red compartidos y escritorios de usuario. Las notas de rescate se depositan en cada directorio cifrado. Un match temprano (antes de que el cifrado se complete) puede activar la respuesta antes de que el daño sea total.

Regla 4: Eliminacion de Volume Shadow Copies (API calls)

La eliminación de las Volume Shadow Copies es una técnica casi universal en ransomware (MITRE ATT&CK T1490: Inhibit System Recovery). Los atacantes la ejecutan para impedir la restauración de ficheros cifrados.

rule Ransomware_ShadowCopy_Deletion_API {
    meta:
        description = "Detecta binarios que llaman a APIs de eliminación de shadow copies"
        author = "MalwareIntel Research"
        date = "2026-06-05"
        tlp = "TLP:WHITE"
        severity = "high"
        mitre_attack = "T1490"

    strings:
        // Comandos de eliminacion via shell
        $cmd_vss1 = "vssadmin delete shadows" ascii wide nocase
        $cmd_vss2 = "vssadmin.exe delete shadows" ascii wide nocase
        $cmd_wmic1 = "wmic shadowcopy delete" ascii wide nocase
        $cmd_wmic2 = "Win32_ShadowCopy" ascii wide
        $cmd_ps1 = "Get-WmiObject Win32_ShadowCopy" ascii wide nocase
        $cmd_ps2 = "Remove-WmiObject" ascii wide nocase

        // PowerShell alternativo
        $ps_shadow1 = "Get-CimInstance" ascii wide
        $ps_shadow2 = "Win32_ShadowCopy" ascii wide
        $ps_shadow3 = "Remove-CimInstance" ascii wide

        // Deshabilitar recovery de Windows
        $recovery1 = "bcdedit" ascii wide nocase
        $recovery2 = "recoveryenabled" ascii wide nocase
        $recovery3 = "bootstatuspolicy" ascii wide nocase
        $recovery4 = "ignoreallfailures" ascii wide nocase

        // API imports directos (COM interface para VSS)
        $api_vss1 = "IVssBackupComponents" ascii wide
        $api_vss2 = "IVssAsync" ascii wide
        $api_vss3 = "CreateVssBackupComponents" ascii wide
        $api_vss4 = "vssapi.dll" ascii wide nocase

        // Catalog de backup
        $catalog1 = "wbadmin delete catalog" ascii wide nocase
        $catalog2 = "delete systemstatebackup" ascii wide nocase

    condition:
        uint16(0) == 0x5A4D and
        filesize < 10MB and
        (
            (1 of ($cmd_vss*) and 1 of ($recovery*)) or
            (1 of ($cmd_wmic*) and 1 of ($recovery*)) or
            ($ps_shadow1 and $ps_shadow2 and $ps_shadow3) or
            (2 of ($api_vss*)) or
            (1 of ($cmd_vss*) and 1 of ($catalog*)) or
            (1 of ($cmd_vss*) and 1 of ($api_vss*))
        )
}

Explicacion y ajuste

La regla cubre cuatro vectores de eliminación de shadow copies:

• Comandos de shell. vssadmin y wmic son los métodos más comunes. La combinación con bcdedit (deshabilitar recovery) reduce falsos positivos porque las herramientas de backup legítimas rara vez desactivan el recovery del sistema.
• PowerShell/CIM. Variantes modernas usan CIM en lugar de WMI. La regla exige los tres strings juntos.
• API COM directa. Ransomware sofisticado (como Conti) llama a la API VSS directamente sin invocar comandos externos. Dos imports de la interfaz VSS son suficientes para alertar.
• Backup catalog. Algunos ransomware también eliminan el catálogo de Windows Backup.

Tip de hunting: Combina esta regla con un filtro temporal. Si un binario nuevo en tu red matchea esta regla y no es una herramienta de backup conocida, es prioritario para análisis.

Regla 5: Comportamiento de cifrado de ficheros (entropia + extensión)

Esta regla utiliza el módulo math de YARA para calcular la entropía de secciones del binario y combinarla con patrones de cifrado. Un binario con alta entropía en sus secciones de datos y referencias a APIs criptográficas tiene alta probabilidad de ser ransomware.

import "pe"
import "math"

rule Ransomware_Encryption_Behavior {
    meta:
        description = "Detecta binarios con comportamiento de cifrado masivo de ficheros"
        author = "MalwareIntel Research"
        date = "2026-06-05"
        tlp = "TLP:WHITE"
        severity = "high"
        mitre_attack = "T1486"

    strings:
        // Windows CryptoAPI
        $crypto_api1 = "CryptEncrypt" ascii wide
        $crypto_api2 = "CryptGenKey" ascii wide
        $crypto_api3 = "CryptImportKey" ascii wide
        $crypto_api4 = "CryptAcquireContext" ascii wide
        $crypto_api5 = "CryptDeriveKey" ascii wide

        // CNG (Cryptography Next Generation)
        $cng1 = "BCryptEncrypt" ascii wide
        $cng2 = "BCryptGenerateSymmetricKey" ascii wide
        $cng3 = "BCryptImportKeyPair" ascii wide
        $cng4 = "BCryptOpenAlgorithmProvider" ascii wide

        // OpenSSL (usado en variantes Linux)
        $ossl1 = "EVP_EncryptInit" ascii
        $ossl2 = "EVP_EncryptUpdate" ascii
        $ossl3 = "EVP_CIPHER_CTX_new" ascii
        $ossl4 = "RSA_public_encrypt" ascii

        // Algoritmos referenciados en strings
        $algo1 = "AES-256" ascii wide nocase
        $algo2 = "ChaCha20" ascii wide
        $algo3 = "RSA-2048" ascii wide nocase
        $algo4 = "RSA-4096" ascii wide nocase
        $algo5 = "Salsa20" ascii wide
        $algo6 = "curve25519" ascii wide nocase

        // Operaciones de fichero masivas
        $file_op1 = "FindFirstFileW" ascii
        $file_op2 = "FindNextFileW" ascii
        $file_op3 = "MoveFileExW" ascii
        $file_op4 = "SetFileAttributesW" ascii
        $file_op5 = "WriteFile" ascii
        $file_op6 = "CreateFileW" ascii

        // Exclusiones de extension (no cifrar ciertos ficheros)
        $exclude1 = ".exe" ascii wide
        $exclude2 = ".dll" ascii wide
        $exclude3 = ".sys" ascii wide
        $exclude4 = "Windows" ascii wide
        $exclude5 = "Program Files" ascii wide

    condition:
        uint16(0) == 0x5A4D and
        filesize < 10MB and
        (
            // CryptoAPI + enumeracion de ficheros + exclusiones
            (2 of ($crypto_api*) and 2 of ($file_op*) and 2 of ($exclude*)) or
            // CNG + enumeracion de ficheros
            (2 of ($cng*) and 2 of ($file_op*) and 1 of ($algo*)) or
            // OpenSSL (variantes Linux portadas a Windows)
            (2 of ($ossl*) and 2 of ($file_op*)) or
            // Algoritmo especifico + operaciones masivas + exclusiones
            (1 of ($algo*) and 3 of ($file_op*) and 2 of ($exclude*))
        ) and
        // Entropia alta en al menos una seccion (indica cifrado o packing)
        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.0
        )
}

Explicacion y ajuste

La condición final de entropía es clave. Un binario legítimo que usa CryptoAPI (navegador, cliente SSH) tendrá entropía normal en sus secciones. Un ransomware que embebe una clave pública RSA o configuración cifrada mostrará entropía superior a 7.0 en al menos una sección.

Los tres caminos de detección cubren las APIs de cifrado más utilizadas:

• CryptoAPI (la más común en ransomware Windows legacy).
• CNG (adoptada por ransomware moderno como Hive y Royal).
• OpenSSL (ransomware multiplataforma y variantes portadas).

Las exclusiones de extensión (.exe, .dll, .sys) y directorios (Windows, Program Files) son un indicador de ransomware porque buscan no romper el sistema operativo para poder mostrar la nota de rescate.

Tip de hunting: Si la regla matchea un binario con entropía alta en la sección .rdata o .data, es probable que contenga configuración cifrada. Extrae esa sección para análisis adicional.

Regla 6: Extraccion de configuraciones embebidas de ransomware

Muchas familias de ransomware embeben su configuración (clave pública, lista de extensiones a cifrar, URLs de C2, nota de rescate) en el binario, cifrada o codificada en Base64/XOR. Esta regla detecta patrones de configuración embebida comunes.

rule Ransomware_Embedded_Config {
    meta:
        description = "Detecta patrones de configuración embebida en ransomware"
        author = "MalwareIntel Research"
        date = "2026-06-05"
        tlp = "TLP:WHITE"
        severity = "high"
        mitre_attack = "T1027, T1486"

    strings:
        // Estructura JSON de configuracion (comun en BlackCat, REvil, BlackBasta)
        $cfg_json1 = "\"public_key\"" ascii wide
        $cfg_json2 = "\"extension\"" ascii wide
        $cfg_json3 = "\"note\"" ascii wide
        $cfg_json4 = "\"white_list\"" ascii wide
        $cfg_json5 = "\"kill_services\"" ascii wide
        $cfg_json6 = "\"kill_processes\"" ascii wide
        $cfg_json7 = "\"encrypt_mode\"" ascii wide

        // Listas de servicios a detener (comun en configuraciones)
        $svc1 = "vss" ascii wide nocase
        $svc2 = "sql" ascii wide nocase
        $svc3 = "svc$" ascii wide
        $svc4 = "backup" ascii wide nocase
        $svc5 = "exchange" ascii wide nocase
        $svc6 = "oracle" ascii wide nocase
        $svc7 = "mysql" ascii wide nocase
        $svc8 = "apache" ascii wide nocase

        // Listas de procesos a terminar
        $proc1 = "sqlservr.exe" ascii wide nocase
        $proc2 = "outlook.exe" ascii wide nocase
        $proc3 = "excel.exe" ascii wide nocase
        $proc4 = "winword.exe" ascii wide nocase
        $proc5 = "msaccess.exe" ascii wide nocase
        $proc6 = "notepad.exe" ascii wide nocase
        $proc7 = "vmwp.exe" ascii wide nocase

        // Listas de extensiones objetivo
        $ext_list1 = ".docx" ascii wide
        $ext_list2 = ".xlsx" ascii wide
        $ext_list3 = ".pptx" ascii wide
        $ext_list4 = ".pdf" ascii wide
        $ext_list5 = ".sql" ascii wide
        $ext_list6 = ".mdf" ascii wide
        $ext_list7 = ".vmdk" ascii wide
        $ext_list8 = ".vhdx" ascii wide

        // Clave publica embebida (patrones Base64 de RSA)
        $pubkey_b64 = /MIIB[A-Za-z0-9+\/]{80,}/ ascii
        $pubkey_pem = "-----BEGIN PUBLIC KEY-----" ascii wide
        $pubkey_rsa = "-----BEGIN RSA PUBLIC KEY-----" ascii wide

    condition:
        uint16(0) == 0x5A4D and
        filesize < 10MB and
        (
            // Config JSON con campos clave
            (3 of ($cfg_json*)) or
            // Lista de servicios + procesos + extensiones (configuracion inline)
            (3 of ($svc*) and 3 of ($proc*) and 3 of ($ext_list*)) or
            // Clave publica + lista de procesos/servicios a detener
            (1 of ($pubkey*) and (2 of ($svc*) or 2 of ($proc*))) or
            // Config JSON + clave publica
            (2 of ($cfg_json*) and 1 of ($pubkey*))
        )
}

Explicacion y ajuste

Las configuraciones de ransomware siguen patrones predecibles. La regla captura cuatro escenarios:

• Config JSON. Familias como BlackCat, REvil y BlackBasta usan estructuras JSON con campos estandarizados. Tres campos de configuración juntos son un indicador fuerte.
• Listas de servicios/procesos/extensiones. Incluso sin estructura JSON, la presencia simultánea de listas de servicios de base de datos, procesos de Office y extensiones de documentos indica configuración de ransomware.
• Clave pública + kill list. La clave RSA embebida se usa para cifrar la clave simétrica por víctima. Combinada con listas de procesos a terminar, el patrón es casi exclusivo de ransomware.

Tip de hunting: Si esta regla matchea, extrae los strings con strings -a o yara -s para obtener la configuración en claro. Los campos como kill_services y white_list revelan los objetivos y exclusiones del operador.

Reglas Sigma complementarias

YARA detecta el artefacto. Sigma detecta el comportamiento en tiempo de ejecución. Estas reglas Sigma complementan las seis reglas YARA anteriores para cubrir la cadena completa de detección.

Sigma: Eliminacion de shadow copies via proceso

title: Shadow Copy Deletion via vssadmin or WMIC
id: e6b2c9a1-4d3f-4e5a-b8c7-d9f0e1a2b3c4
status: stable
logsource:
    category: process_creation
    product: windows
detection:
    selection_vss:
        CommandLine|contains|all:
            - 'vssadmin'
            - 'delete'
            - 'shadows'
    selection_wmic:
        CommandLine|contains|all:
            - 'wmic'
            - 'shadowcopy'
            - 'delete'
    condition: selection_vss or selection_wmic
level: critical
tags:
    - attack.impact
    - attack.t1490

Sigma: Enumeracion masiva de ficheros seguida de cifrado

title: Mass File Enumeration Followed by Modification
id: f7c3d0b2-5e4a-4f6b-c9d8-e0a1b2c3d4e5
status: experimental
logsource:
    category: file_event
    product: windows
detection:
    selection:
        EventType: 'FileRenamed'
        TargetFilename|re: '\.[a-z0-9]{5,10}$'
    timeframe: 1m
    condition: selection | count() > 50
level: critical
tags:
    - attack.impact
    - attack.t1486

Sigma: Detencion masiva de servicios

title: Mass Service Stop Indicating Ransomware Pre-Encryption
id: a8d4e1c3-6f5b-4a7c-d0e9-f1b2c3d4e5f6
status: experimental
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        CommandLine|contains:
            - 'net stop'
            - 'sc stop'
            - 'taskkill /f'
        CommandLine|contains:
            - 'sql'
            - 'exchange'
            - 'backup'
            - 'vss'
    timeframe: 5m
    condition: selection | count() > 3
level: high
tags:
    - attack.impact
    - attack.t1489

Estas reglas Sigma se despliegan en SIEM (Splunk, Elastic, Microsoft Sentinel) y complementan las reglas YARA que corren en EDR o durante incident response.

Workflow de hunting con YARA para ransomware

Un flujo práctico para integrar estas reglas en operaciones:

Fase 1: Deteccion proactiva

1. Desplegar en EDR. Cargar las seis reglas en tu EDR/XDR (CrowdStrike, SentinelOne, Elastic). Configurar alertas en tiempo real para matcheos en disco y memoria.
2. Escaneo de red. Usar yara -r contra shares de red y servidores de ficheros. Priorizar las reglas genéricas (notas de rescate, shadow copies) porque detectan familias nuevas.
3. Monitoreo de email gateway. Escanear adjuntos con las reglas de cifrado y configuración embebida antes de que lleguen al buzón.

Fase 2: Hunting retroactivo

1. VirusTotal Retrohunt. Subir las reglas específicas (LockBit, BlackCat) para encontrar variantes no clasificadas en el corpus de VT.
2. MalwareBazaar. Descargar samples recientes tagueados como ransomware y validar las reglas contra ellos. Ajustar condiciones según la tasa de falsos negativos.
3. Sandbox histórico. Si usas ANY.RUN o CAPE, escanear los dumps de memoria de ejecuciones pasadas con las reglas de API calls.

Fase 3: Respuesta y ajuste

1. Triaje de alertas. Match en regla específica (LockBit, BlackCat) = prioridad crítica. Match en regla genérica = prioridad alta, requiere clasificación manual.
2. Extracción de config. Si la regla 6 matchea, extraer la configuración para obtener la clave pública, extensiones objetivo y servicios a detener. Esta información alimenta los indicadores de la campaña.
3. Feedback loop. Cada falso positivo o falso negativo se documenta. Ajustar las condiciones: subir el umbral de strings requeridos si hay FP, bajarlo si hay FN.

Recursos y referencias

Repositorios de reglas YARA para ransomware

Recurso	URL	Contenido
YARA-Rules Community	github.com/Yara-Rules/rules	Colección comunitaria, incluye ransomware
ReversingLabs YARA	github.com/reversinglabs/reversinglabs-yara-rules	Reglas por familia, actualizadas
Malpedia YARA	malpedia.caad.fkie.fraunhofer.de	Reglas asociadas a cada familia
Florian Roth (Neo23x0)	github.com/Neo23x0/signature-base	Reglas de detección amplia
bartblaze YARA	github.com/bartblaze/Yara-rules	Reglas de ransomware específicas

Herramientas de testing

Herramienta	Uso
yara CLI	Escaneo local de ficheros y directorios
yarGen	Generación automática de reglas a partir de samples
YARA-CI	Validación de sintaxis en CI/CD
yaraQA	Control de calidad de reglas (detección de errores comunes)
VirusTotal Retrohunt	Validación contra corpus global de malware

Referencias tecnicas

• CISA Advisory AA23-075A: LockBit 3.0 Ransomware
• FBI FLASH: BlackCat/ALPHV Ransomware Indicators of Compromise
• MITRE ATT&CK T1486: Data Encrypted for Impact
• MITRE ATT&CK T1490: Inhibit System Recovery
• Victor M. Alvarez: "YARA Documentation" (yara.readthedocs.io)
• Florian Roth: "How to Write Simple but Sound YARA Rules" (nextron-systems.com)

Las seis reglas de este artículo son un punto de partida. El ransomware evoluciona con cada campaña, y las reglas deben evolucionar con él. La combinación de reglas específicas por familia (para clasificación rápida) y genéricas por comportamiento (para detección de variantes nuevas) proporciona la cobertura más robusta. Integrar YARA con Sigma, como se muestra en la sección complementaria, cierra el gap entre la detección del artefacto y la detección del comportamiento en runtime.