Módulo 11: Threat Hunting proactivo

Aviso ético y legal: este módulo enseña threat hunting con fines exclusivamente educativos y defensivos. Practica las consultas y reglas Sigma/YARA únicamente en tu propio laboratorio, en telemetría de una organización donde tengas mandato explícito, o en plataformas legales de práctica (rangos de ciberdefensa, CTF, Detection Lab). Cazar amenazas contra sistemas o cuentas de terceros sin autorización constituye delito en España conforme a los artículos 197 y 264 del Código Penal. Los indicadores, hashes, IP y dominios de ejemplo son ficticios o pertenecen a rangos reservados para documentación (RFC 5737) salvo que se indique lo contrario.

Qué aprenderás

• Qué es el threat hunting y en qué se diferencia de la detección reactiva, incluida la premisa de assume breach que lo sustenta.
• El ciclo de hunting basado en hipótesis: formular, recopilar datos, analizar y responder/documentar.
• Los tres tipos de hunting —guiado por inteligencia/IOC, por TTP/ATT&CK y por anomalía (data-driven)— y cuándo usar cada uno.
• Cómo aplicar la Pyramid of Pain de David Bianco para decidir qué cazar y por qué cazar TTP es lo que de verdad incomoda al adversario.
• A escribir reglas Sigma válidas (YAML: logsource, detection con selection/condition) y convertirlas a consultas de SIEM reales con sigma-cli/pySigma.
• A escribir reglas YARA para cazar en ficheros y en memoria (meta/strings/condition).
• Cómo cazar a escala con osquery (SQL sobre el endpoint) y Velociraptor (VQL y hunts distribuidos), y qué aporta un EDR.
• El Hunting Maturity Model (HMM0-HMM4) de Sqrrl/David Bianco.
• Cómo convertir un hallazgo de hunt puntual en una detección automatizada permanente.

1. Qué es el threat hunting (y qué no es)

El threat hunting es la búsqueda proactiva, humana e iterativa de actividad maliciosa, partiendo de una hipótesis concreta, en lugar de esperar a que una regla dispare una alerta. La diferencia con la monitorización reactiva es de dirección causal: en detección reactiva el sistema te avisa a ti («esta regla ha matcheado»); en hunting formulas tú la pregunta primero («¿existe un patrón X que ninguna regla actual detectaría?») y vas a buscar la respuesta en los datos.

Esto tiene una consecuencia práctica: el hunting está diseñado para encontrar lo que las detecciones automatizadas no encuentran. Si una regla Sigma o una firma de EDR ya cubre un comportamiento, ese comportamiento deja de ser objeto de hunting y pasa a ser trabajo de triaje de SOC. El hunter busca en el hueco: técnicas nuevas, evasión de controles existentes, actividad de bajo volumen perdida en el ruido, o adversarios que ya llevan tiempo dentro sin haber disparado ninguna alerta.

1.1 La premisa de assume breach

El hunting parte de una premisa incómoda: asume que ya has sido comprometido, o que lo serás, y que algunos controles ya han fallado o fallarán silenciosamente. En lugar de «¿cómo evito que entren?», el hunter pregunta «dado que probablemente alguien ya está dentro, ¿qué evidencia dejaría su actividad y dónde debo buscarla?». Esta mentalidad no sustituye a la prevención ni a la detección automatizada, las complementa como red de seguridad activa para lo que se cuela por sus huecos, y es también el fundamento conceptual de Zero Trust: si no confías por defecto en nada dentro del perímetro, cazar anomalías internas deja de ser opcional.

2. El ciclo de hunting basado en hipótesis

El hunting sin estructura degenera en «pescar» sin rumbo por los logs, consumiendo tiempo de analista sin resultados repetibles ni defendibles. El modelo estándar de la industria —formalizado por Sqrrl (fundada por antiguos analistas de la NSA, adquirida después por AWS) y adoptado en GCIH/GCFA— estructura el hunting en cuatro fases que se repiten en bucle.

2.1 Fase 1 — Formular una hipótesis

Toda cacería empieza con una afirmación concreta y comprobable, no con una pregunta vaga: «voy a mirar los logs a ver qué encuentro» no es una hipótesis, es procrastinación con aspecto de trabajo. Una buena hipótesis es específica (menciona una técnica o comportamiento concreto), cazable (existen datos reales que podrían confirmarla o refutarla) y fundamentada (nace de threat intelligence, de un informe de red team, de gaps en ATT&CK Navigator, o de la intuición de un analista experimentado, pero no de la nada). Ejemplo: «un adversario está usando PowerShell con comandos codificados en Base64 (-EncodedCommand) para evadir la inspección de línea de comandos, en algún host en los últimos 30 días».

2.2 Fase 2 — Recopilar y organizar los datos

Identifica qué fuentes de telemetría pueden confirmar o refutar la hipótesis (EDR, Sysmon, Windows Event Log, DNS, proxy, NetFlow) y extrae el subconjunto relevante. Aquí es crítico verificar primero la cobertura de datos: si la hipótesis requiere PowerShell Script Block Logging y esa auditoría no está habilitada, ninguna consulta va a producir resultados —y descubrir ese hueco de visibilidad es en sí mismo un resultado valioso y documentable del hunt—.

2.3 Fase 3 — Analizar

Aplica técnicas analíticas: búsqueda de patrones conocidos, análisis de frecuencia (¿qué proceso padre-hijo aparece solo una vez en 10.000 endpoints?), stacking de valores para detectar outliers, línea temporal para correlacionar eventos dispersos. El objetivo es llegar a una de tres conclusiones: la hipótesis se confirma (se activa respuesta a incidentes), se refuta (queda descartada para este periodo) o queda indeterminada por falta de datos (se documenta el gap para remediarlo).

2.4 Fase 4 — Responder y documentar

Si se confirma actividad maliciosa, se escala a respuesta a incidentes. Pero aunque se refute, el ciclo no ha terminado: hay que documentar qué se buscó, con qué consulta, sobre qué rango temporal y con qué resultado, y decidir si merece convertirse en una detección automatizada permanente para no repetir manualmente la misma caza cada mes. Este paso, desarrollado en la sección 10, es el criterio real de éxito del hunting: no cuántos hunts hiciste, sino cuánta detección permanente generaron.

3. Tipos de threat hunting

No todos los hunts parten del mismo punto. La industria distingue tres enfoques que en la práctica se combinan dentro de un mismo programa maduro.

Tipo de hunt	Punto de partida	Ejemplo
Guiado por inteligencia (IOC-driven)	Un IOC o reporte de threat intelligence concreto: hash, IP, dominio, TTP de un actor identificado en un informe de CTI o CERT sectorial	Un feed de INCIBE-CERT publica IOC de una campaña de ransomware activa; el hunter busca retrospectivamente esos hashes e IP en los últimos 90 días de logs, aunque ninguna alerta haya saltado.
Guiado por TTP / MITRE ATT&CK	Una técnica concreta del framework, priorizada por gaps de cobertura visibles en ATT&CK Navigator o por relevancia sectorial	El hunter selecciona T1055 (Process Injection) porque el Navigator muestra cero detección activa, y diseña una caza de inyección de proceso vía CreateRemoteThread en procesos no habituales.
Guiado por anomalía / data-driven	Análisis estadístico sobre grandes volúmenes de telemetría para encontrar outliers sin hipótesis previa sobre la técnica exacta	El stacking de procesos padre-hijo de 30 días revela que wmiprvse.exe generó un hijo cmd.exe con red saliente en un único host de 4.000, patrón que no aparece en el resto del parque.

El hunting por inteligencia es el más rápido de arrancar (el IOC ya viene dado) pero también el más frágil: caduca en cuanto el adversario cambia infraestructura. El guiado por TTP es más costoso de diseñar pero mucho más resistente en el tiempo. El de anomalía es el más exigente (requiere datos limpios y herramientas de análisis estadístico) pero el único capaz de encontrar técnicas para las que aún no existe ni IOC ni descripción de TTP conocida.

4. La Pirámide del Dolor aplicada al hunting: cazar TTP

La Pyramid of Pain, formalizada por David Bianco en 2013, ordena los indicadores según cuánto le cuesta al adversario cambiarlos cuando los detectas. De la base (barato) a la cúspide (carísimo): hashes, direcciones IP, dominios, artefactos de red/host, herramientas del atacante y, arriba del todo, TTP (Tácticas, Técnicas y Procedimientos).

La implicación para diseñar un programa de hunting es directa: cazar hashes e IP es trabajo legítimo pero de bajo coste de evasión para el adversario —cambiar un hash no le exige ni pensar—. Diseñar hunts que buscan el patrón de comportamiento (por ejemplo, «un proceso de Office generando un hijo intérprete de comandos con red saliente en los primeros 60 segundos», sin importar qué malware concreto lo provoque) obliga al adversario a rediseñar por completo su cadena de ataque, no solo recompilar un binario. Bianco lo resume así: detectar y responder a los TTP impacta al adversario donde más le duele, porque le obliga a aprender comportamientos nuevos, un proceso lento y caro. Cuantos más hunts diseñes contra TTP en lugar de IOC sueltos, más caro haces el ataque para cualquier adversario, no solo para el que ya conoces.

5. Reglas Sigma: detección portable basada en TTP

Sigma es un formato abierto y agnóstico de plataforma para escribir reglas de detección de logs en YAML, mantenido por el proyecto SigmaHQ. Su valor central es la portabilidad: escribes la lógica una sola vez, versionable en Git, y la conviertes a la sintaxis de tu SIEM (Splunk SPL, Sentinel KQL, Elastic EQL…) mediante el conversor pySigma y su CLI sigma-cli. Esto convierte cada regla en un artefacto que puedes compartir, aportar a la comunidad o migrar sin reescribir cuando cambies de SIEM.

5.1 Estructura de una regla Sigma

Una regla Sigma se compone, como mínimo, de title, id (UUID único), status, description, logsource (qué producto/categoría de log describe) y el bloque detection, con una o más secciones selection y una condition que las combina. Se completa habitualmente con falsepositives, level y tags (referencias a MITRE ATT&CK). El siguiente ejemplo caza un IOA clásico: PowerShell con comando codificado en Base64 (T1027, T1059.001), técnica de ofuscación habitual para evadir la inspección de línea de comandos en claro.

title: PowerShell con comando codificado en Base64 (EncodedCommand)
id: 8f5c1e2a-3b4d-4e6f-9a1c-2d7e8f9b0c1d
status: experimental
description: >
    Detecta la ejecución de powershell.exe con el parámetro -EncodedCommand
    (o su forma abreviada -enc/-e), usado habitualmente para ofuscar
    comandos maliciosos y evadir la inspección de línea de comandos en claro.
references:
    - https://attack.mitre.org/techniques/T1059/001/
    - https://attack.mitre.org/techniques/T1027/
author: Módulo 11 - Threat Hunting Proactivo, cursosdeciberseguridad.com
date: 2026-07-01
logsource:
    category: process_creation
    product: windows
detection:
    selection_proc:
        Image|endswith:
            - 'powershell.exe'
            - 'pwsh.exe'
    selection_flag:
        CommandLine|contains:
            - '-EncodedCommand'
            - '-enc '
            - '-e '
            - ' -en '
    filter_main_legit_signed:
        CommandLine|contains: 'ConfigureRemotingForAnsible'
    condition: selection_proc and selection_flag and not filter_main_legit_signed
falsepositives:
    - Scripts de administración legítimos que codifican comandos por longitud
      o caracteres especiales (poco frecuente pero posible).
    - Herramientas de gestión de configuración (Ansible, DSC) que codifican
      comandos de forma rutinaria; ajustar el filtro a tu entorno.
level: high
tags:
    - attack.defense-evasion
    - attack.execution
    - attack.t1059.001
    - attack.t1027

5.2 La regla campo a campo

• id: UUID v4 único que identifica la regla en cualquier repositorio o herramienta que la consuma; nunca se reutiliza.
• logsource: category: process_creation + product: windows le dice a pySigma que busque creación de procesos de Windows (Sysmon Event ID 1 o Security 4688 según backend); el conversor mapea los campos automáticamente.
• selection_proc: el campo Image termina en powershell.exe o pwsh.exe. El modificador |endswith es sintaxis nativa de Sigma para «coincide con el final de la cadena».
• selection_flag: la línea de comandos contiene alguna variante del parámetro de codificación. Se listan varias formas porque PowerShell acepta el parámetro abreviado de distintas maneras, y un adversario suele usar la más corta para dificultar el reconocimiento visual.
• filter_main_legit_signed: sección de tipo filtro que se resta con and not; excluye un falso positivo conocido (scripts de aprovisionamiento de Ansible que codifican comandos de forma rutinaria).
• condition: selection_proc and selection_flag and not filter_main_legit_signed. Sigma evalúa cada sección como bloque booleano y esta línea define cómo se combinan.
• level: severidad (informational/low/medium/high/critical); aquí high porque, filtrado el falso positivo conocido, la probabilidad de verdadero positivo es alta.
• tags: el mapeo attack.txxxx permite agregar cobertura de detección por técnica en el ATT&CK Navigator, cerrando el círculo con la sección 4.

5.3 Conversión a consulta real con sigma-cli

# Instalación
pip install sigma-cli
pip install pysigma-backend-splunk

# Listar backends y pipelines disponibles
sigma list targets
sigma list pipelines

# Convertir la regla anterior a SPL de Splunk, usando el pipeline de Sysmon
sigma convert -t splunk -p sysmon powershell_encodedcommand.yml

# Convertir a KQL de Microsoft Sentinel
pip install pysigma-backend-microsoft365defender
sigma convert -t microsoft365defender powershell_encodedcommand.yml

# Validar la sintaxis sin convertir (útil en un pipeline de CI de reglas)
sigma check powershell_encodedcommand.yml

sigma check se integra en CI/CD para validar que cada regla nueva cumple el esquema oficial antes de fusionarla a un repositorio compartido, evitando que una regla mal formada llegue a producción.

6. YARA: cazar en ficheros y en memoria

YARA (creada por Victor Álvarez en VirusTotal) es el estándar de facto para identificar patrones en ficheros binarios y volcados de memoria. Donde Sigma detecta comportamiento en logs, YARA detecta patrones en contenido: cadenas de texto, secuencias de bytes u opcodes, combinables con condiciones booleanas. Se estructura en tres bloques: meta (metadatos, sin efecto en el matching), strings (patrones con identificador $nombre) y condition (expresión booleana que decide cuándo dispara). El siguiente ejemplo caza indicadores genéricos de un stager/loader que descarga un segundo binario mediante PowerShell, combinando cadenas de texto con una condición de tamaño para reducir falsos positivos.

rule Sospechoso_PowerShell_Downloader_Stager
{
    meta:
        author = "Modulo 11 - Threat Hunting Proactivo, cursosdeciberseguridad.com"
        description = "Detecta indicadores genericos de un stager que invoca PowerShell para descargar y ejecutar un segundo binario en memoria"
        date = "2026-07-01"
        reference = "https://attack.mitre.org/techniques/T1059/001/"
        threat_level = "media"
        tlp = "clear"

    strings:
        $ps1 = "powershell" nocase
        $ps2 = "-nop -w hidden -c" nocase
        $ps3 = "IEX(New-Object Net.WebClient).DownloadString" nocase
        $ps4 = "System.Reflection.Assembly]::Load" nocase
        $net1 = "DownloadFile" nocase
        $net2 = "http://" ascii
        $net3 = "https://" ascii
        $enc1 = "-EncodedCommand" nocase
        $enc2 = "FromBase64String" nocase

    condition:
        uint16(0) == 0x5A4D
        and filesize < 5MB
        and $ps1
        and (2 of ($ps2, $ps3, $ps4))
        and (1 of ($net1, $net2, $net3))
        and (1 of ($enc1, $enc2))
}

6.1 La regla YARA campo a campo

• meta: bloque informativo (autor, fecha, referencia ATT&CK, nivel de amenaza, TLP); no influye en si la regla dispara, pero es indispensable para la trazabilidad en un repositorio con decenas de reglas.
• strings: cada línea define un patrón con su identificador. nocase hace la búsqueda insensible a mayúsculas (un atacante puede variarlas para evadir un match literal); ascii restringe a esa codificación (YARA también admite wide para UTF-16, habitual en binarios de Windows).
• uint16(0) == 0x5A4D: lee un entero de 16 bits en el offset 0; 0x5A4D son los bytes MZ de la cabecera de un ejecutable PE de Windows. Asegura que la regla solo evalúa binarios reales, no cualquier texto que contenga las cadenas por casualidad.
• filesize < 5MB: descarta binarios legítimos grandes donde las cadenas podrían aparecer de forma incidental; los stagers reales suelen ser pequeños porque su única función es descargar la carga útil real.
• 2 of ($ps2, $ps3, $ps4): exige al menos 2 de 3 cadenas del grupo, ni todas (un atacante cambia una y evade la regla) ni solo una (demasiado laxo). Este patrón «N de M» es la técnica estándar para calibrar sensibilidad en YARA.
• condition completa: combina cabecera PE válida, tamaño acotado, cadena base de PowerShell, al menos 2 patrones de descarga/ejecución reflectiva, 1 indicador de red y 1 de codificación. Esta combinación reduce drásticamente el ruido frente a usar cualquier cadena de forma aislada.

6.2 YARA sobre memoria: la diferencia operativa

YARA no distingue conceptualmente entre escanear un fichero en disco o un volcado de memoria: aplica los mismos patrones sobre el flujo de bytes que se le entregue. La diferencia está en la herramienta que alimenta ese flujo.

# Escanear un directorio completo de ficheros sospechosos, de forma recursiva
yara64.exe -r reglas_hunting.yar C:EvidenciaCASO2026-014triage

# Escanear la memoria de un proceso en ejecución por PID (Windows, requiere privilegios)
yara64.exe reglas_hunting.yar 4821

# Escanear un volcado de memoria completo (--fast reduce el tiempo en ficheros grandes)
yara64.exe --fast -r reglas_hunting.yar D:evidenciamem_host01.raw

# Cazar en memoria con Volatility 3 usando el plugin de escaneo YARA
vol3 -f mem_host01.raw yarascan.YaraScan --yara-file reglas_hunting.yar

# Velociraptor: aplicar reglas YARA contra memoria de procesos en múltiples endpoints
# (artifact nativo Windows.Detection.Yara.Process, ejecutado como hunt distribuido)

El escaneo en memoria es especialmente valioso frente a malware fileless o inyectado en un proceso legítimo (T1055), que nunca deja un binario completo en disco pero sí existe como bytes reconocibles en el espacio de direcciones del proceso mientras se ejecuta.

7. Hunting a escala: osquery, Velociraptor y EDR

Una hipótesis rara vez se comprueba en un solo endpoint: la pregunta real casi siempre es «¿existe este patrón en alguno de nuestros 3.000 hosts?», lo que exige herramientas de consulta distribuida.

7.1 osquery: el endpoint como base de datos SQL

osquery (originado en Facebook, hoy en la OSQuery Foundation) expone el estado del sistema operativo —procesos, conexiones de red, registro, extensiones de navegador, tareas programadas— como tablas SQL, lo que permite formular hipótesis directamente como una SELECT.

-- Procesos que escuchan en red pero cuyo binario ya no existe en disco
-- (indicador clásico de proceso que se ha borrado a si mismo tras ejecutarse)
SELECT p.pid, p.name, p.path, p.cmdline, pos.local_address, pos.local_port
FROM processes p
JOIN process_open_sockets pos ON p.pid = pos.pid
WHERE p.on_disk = 0
  AND pos.local_port > 0;

-- Procesos hijos de powershell.exe con linea de comandos que contiene
-- codificacion Base64, cruzado con el proceso padre real
SELECT p.pid, p.name, p.path, p.cmdline, p.parent, pp.name AS parent_name
FROM processes p
LEFT JOIN processes pp ON p.parent = pp.pid
WHERE p.name = 'powershell.exe'
  AND (p.cmdline LIKE '%-EncodedCommand%' OR p.cmdline LIKE '%-enc %')
  AND pp.name NOT IN ('explorer.exe', 'cmd.exe', 'powershell.exe');

-- Ejecucion distribuida contra la flota completa via osquery fleet manager (Fleet/Kolide)
-- se lanza la misma consulta como "live query" o "scheduled query" a miles de endpoints

La ventaja de osquery es doble: el lenguaje (SQL) ya lo conoce cualquier analista, y las scheduled queries permiten convertir directamente un hallazgo de hunt en monitorización continua, conectando con el feedback loop de la sección 10.

7.2 Velociraptor: VQL y hunts distribuidos

Velociraptor (Rapid7, open source) va un paso más allá: además de consultar el estado actual, recolecta artefactos forenses completos, ejecuta YARA contra memoria en toda la flota, y lanza un hunt —una consulta VQL (sintaxis inspirada en SQL, extendida con funciones forenses) programada contra un conjunto de endpoints, cuyos resultados se recolectan de forma centralizada según van respondiendo los clientes—.

# VQL: listar procesos con conexiones de red salientes hacia puertos no habituales,
# ejecutado como hunt contra todos los endpoints con la etiqueta "produccion"
SELECT Pid, Name, CommandLine, Exe,
       Connections.raddr AS RemoteAddr, Connections.rport AS RemotePort
FROM Artifact.Windows.Network.ProcessConnections()
WHERE RemotePort not in (80, 443, 53, 3389)

# Aplicar un set de reglas YARA contra la memoria de todos los procesos powershell.exe
# en ejecucion, en toda la flota, como hunt distribuido
SELECT * FROM Artifact.Windows.Detection.Yara.Process(
    processRegex="powershell.exe",
    yaraRule="rule Hunt { strings: $a = "DownloadString" nocase condition: $a }"
)

# Lanzar el hunt desde la CLI del servidor contra un artifact concreto
velociraptor --config server.config.yaml artifacts collect 
    Windows.Detection.Yara.Process --args processRegex=powershell.exe

La diferencia clave frente a osquery: un hunt de Velociraptor no requiere que el endpoint esté conectado en el momento de lanzar la consulta —el cliente la recoge en su siguiente check-in—, lo que lo hace robusto en flotas grandes con conectividad intermitente.

7.3 Capacidades nativas de EDR para hunting

La mayoría de EDR comerciales (CrowdStrike Falcon, Microsoft Defender for Endpoint con Advanced Hunting en KQL, SentinelOne DeepVisibility) incorporan su propia interfaz de hunting sobre telemetría ya recolectada de forma nativa, sin agentes adicionales. Su ventaja es la profundidad (llamadas a API de kernel, inyección de proceso, red por proceso individual) y la integración con respuesta (aislar, matar el proceso, sin cambiar de herramienta). Su límite es que solo cubren lo que el agente decide instrumentar y retener, mientras que osquery/Velociraptor, al ser abiertos, permiten definir exactamente qué artefacto adicional capturar cuando el EDR no lo cubre.

8. El Hunting Maturity Model (HMM) de Sqrrl/David Bianco

El HMM evalúa la madurez del programa de hunting de una organización en cinco niveles, según dos ejes: la cantidad y calidad de datos disponibles y el nivel de procedimiento/automatización aplicado sobre ellos.

Nivel	Nombre	Características
HMM0	Inicial	Depende casi exclusivamente de alertas automatizadas (SIEM/EDR/IDS). No hay hunting proactivo real.
HMM1	Mínimo	Incorpora feeds de threat intelligence e IOC externos para búsquedas retrospectivas puntuales. Mayoritariamente reactivo.
HMM2	Procedimental	Sigue procedimientos de hunting documentados por terceros (playbooks, hunts basados en informes ATT&CK) de forma regular, aunque aún no diseña los suyos propios.
HMM3	Innovador	Diseña sus propios procedimientos de análisis (stacking, agrupación, visualización a medida) y crea hunts originales, no solo reproduce los de terceros.
HMM4	Líder / Automatizado	La mayoría de procedimientos de análisis exitosos que antes requerían un humano se han automatizado en detecciones permanentes; el hunter queda libre para hipótesis genuinamente nuevas.

Un matiz que Bianco subraya: la disponibilidad de datos de calidad es, en la práctica, el factor limitante dominante. Una organización puede tener analistas brillantes con conocimiento de sobra para HMM3, pero si la cobertura de logs es pobre (sin Sysmon, sin auditoría avanzada, retención de 7 días), el techo real de madurez alcanzable queda mucho más bajo. Subir de nivel exige invertir en visibilidad de datos antes o en paralelo al procedimiento analítico.

9. Laboratorio: formular una hipótesis y cazarla

Objetivo: practicar el ciclo completo de la sección 2, de principio a fin, con una hipótesis concreta y una consulta real.

1. Formula la hipótesis: «existe en mi entorno de laboratorio actividad de PowerShell ofuscado (Base64) en los últimos 30 días, que no ha disparado ninguna alerta existente».
2. Verifica cobertura de datos: confirma que tienes Sysmon desplegado (Event ID 1) o, en su defecto, auditoría de creación de procesos con línea de comandos habilitada (Event ID 4688 + Include command line in process creation events vía GPO). Sin esto, la hipótesis es incazable: documenta el gap.
3. Recopila y analiza con Sigma: toma la regla del apartado 5.1, conviértela con sigma-cli al backend de tu SIEM de laboratorio y ejecútala contra los últimos 30 días.
4. Verificación cruzada con osquery: ejecuta la segunda consulta del apartado 7.1 para confirmar los mismos hallazgos con una herramienta distinta; no depender de una sola fuente es buena práctica de hunting.
5. Decodifica cualquier hallazgo: si aparece un comando codificado real, decodifícalo para inspeccionar la intención ([System.Text.Encoding]::Unicode.GetString([System.Convert]::FromBase64String("cadena")) en consola aislada, nunca ejecutando el comando decodificado).
6. Documenta el resultado: confirma, refuta o marca como indeterminado, con la consulta exacta, el rango temporal y el resultado.
7. Cierra el ciclo: si el hunt no tenía ya una regla Sigma equivalente activa, esta es la señal de convertirlo en una (sección 10).

10. Convertir un hallazgo de hunt en detección permanente

Este es el paso que determina si un programa de hunting genera valor acumulativo o repite trabajo manual cada mes. El feedback loop maduro sigue esta secuencia: (1) se ejecuta un hunt manual; (2) si confirma un patrón útil —verdadero positivo real o patrón que merece vigilancia continua aunque esta vez fuera benigno—, se traduce la lógica a una regla Sigma formal completa; (3) se valida (sigma check), se convierte al backend de producción (sigma convert) y se despliega como detección activa; (4) se mide su tasa de falsos positivos durante un periodo de calibración y se ajusta; (5) estable, queda como status: stable, versionada en el repositorio del equipo, con su tag ATT&CK actualizando la cobertura visible en el Navigator.

Este ciclo es lo que separa HMM2/HMM3 (hunts manuales repetidos por procedimiento) de HMM4 (los hallazgos exitosos migran a automatización, liberando al analista para la siguiente hipótesis nueva). Un programa que nunca completa este paso repite el mismo trabajo manual indefinidamente sin acumular capacidad de detección real.

11. Errores comunes

• Cazar sin hipótesis. Abrir el SIEM a «ver qué se encuentra» sin una afirmación concreta que confirmar o refutar es exploración sin rumbo, no hunting.
• No verificar la cobertura de datos antes de cazar. Descubrir a mitad de análisis que la fuente necesaria nunca se recolectó es un desperdicio evitable; la verificación va en la fase 2, no como sorpresa en la fase 3.
• No documentar los hunts que no encuentran nada. Un hunt que refuta la hipótesis sigue siendo valioso: demuestra que esa superficie está limpia y evita que otro analista repita el trabajo sin saberlo meses después.
• No convertir hallazgos recurrentes en detección permanente. Repetir manualmente el mismo hunt cada mes sin invertir en automatizarlo es quedarse permanentemente en HMM2.
• Cazar solo en la base de la Pirámide del Dolor. Hunts centrados exclusivamente en IOC dan sensación de actividad pero poca resiliencia; prioriza TTP siempre que sea viable.
• Reglas Sigma o YARA sin calibrar. Desplegar una regla de un repositorio público sin adaptarla al propio entorno genera fatiga de alertas y descrédito del programa de detección.

12. Ejercicio

En tu entorno de laboratorio (Detection Lab, una VM de Windows con Sysmon, o el SIEM/EDR del curso):

1. Escribe tu propia hipótesis distinta a la del laboratorio guiado (por ejemplo: «uso de rundll32.exe para ejecutar código desde una DLL con extensión distinta a .dll», T1218.011) siguiendo los tres criterios de la sección 2.1: específica, cazable y fundamentada.
2. Escribe una regla Sigma completa para esa hipótesis, con logsource, detection (selection + condition), falsepositives, level y tags de ATT&CK correctos. Valídala con sigma check.
3. Conviértela con sigma-cli al backend de tu SIEM de laboratorio y ejecútala.
4. Escribe una regla YARA que complemente la caza a nivel de fichero/memoria para el mismo escenario.
5. Documenta el resultado (confirmado/refutado/indeterminado) y, si procede, describe los pasos para convertirlo en detección permanente según la sección 10.

Preguntas frecuentes

¿En qué se diferencia el threat hunting del trabajo diario de un analista SOC de nivel 1/2?

El analista SOC reacciona: recibe una alerta ya generada y decide si es verdadero o falso positivo. El hunter actúa antes de que exista ninguna alerta: formula una pregunta sobre un comportamiento que ninguna regla cubre y va a los datos crudos a buscar la respuesta. En equipos pequeños la misma persona hace ambas cosas en momentos distintos; en equipos grandes suelen ser roles separados, con el hunting reservado a analistas de nivel 3 o a un equipo dedicado.

¿Necesito un EDR comercial caro para empezar a hacer threat hunting en serio?

No. Puedes construir un programa funcional en HMM1-HMM2 con herramientas open source: Sysmon para telemetría de proceso, un SIEM gratuito o de bajo coste (Elastic Security, Wazuh), Sigma para portar reglas de la comunidad, osquery o Velociraptor para consulta distribuida, y YARA para análisis de ficheros/memoria. Lo que de verdad limita la madurez, como señala el HMM, no es el presupuesto de licencias sino la calidad y cobertura de los datos y la disciplina del procedimiento.

¿Una regla Sigma sustituye a una regla nativa de mi SIEM?

No exactamente: Sigma es un formato intermedio, no un motor de ejecución. Se convierte, vía pySigma/sigma-cli, a la sintaxis nativa de tu SIEM (SPL, KQL, EQL…) y es esa consulta convertida la que se despliega. La ventaja de mantener el original en Sigma es que se puede reconvertir a otro backend sin reescribirlo si cambias de SIEM, y se pueden consumir reglas ya publicadas por SigmaHQ sin depender de qué plataforma use quien las escribió.

¿Por qué la regla YARA comprueba la cabecera MZ (uint16(0) == 0x5A4D) en lugar de solo buscar las cadenas de texto?

Porque buscar solo cadenas como DownloadString o -EncodedCommand sin contexto generaría falsos positivos masivos: aparecen en scripts legítimos, documentación o cualquier fichero de texto que las mencione por motivos benignos. Anclar la regla a que el fichero sea realmente un PE (cabecera MZ) de tamaño acotado, combinado con el operador N of (...) que exige varias señales simultáneas, reduce el ruido sin perder capacidad de detección. Es el mismo principio de calibración que el filtro de la regla Sigma del apartado 5.1.

¿Qué debo cazar primero si empiezo un programa de hunting desde cero?

Empieza por el eje de datos, no por el de técnica: audita qué telemetría tienes realmente y con qué retención (en la práctica, evalúa tu propio nivel HMM antes de diseñar nada). Con esa base, prioriza hipótesis con el ATT&CK Navigator: identifica técnicas relevantes para tu sector sin cobertura de detección activa y empieza por ahí. Los primeros hunts de un programa nuevo suelen descubrir más gaps de visibilidad que compromisos reales, y ese es exactamente el resultado esperado en esta etapa.

«When you detect and respond to TTPs, you impact the adversary where it hurts the most, because you force them to do more work, to learn new behaviors… This is a very time-consuming and expensive process for the adversary, making it the most effective place to concentrate your detection and response capabilities.»

— David Bianco, «The Pyramid of Pain», 2013 (marco adoptado y extendido por Sqrrl como base del Hunting Maturity Model).