Threat Hunting: cómo buscar amenazas antes de que te encuentren

Los sistemas de detección automática — SIEM, EDR, IDS — son extraordinariamente buenos detectando lo que ya se conoce. Firmas de malware conocido, reglas de correlación basadas en patrones históricos, anomalías estadísticas. Eso cubre el 80% de las amenazas.

El 20% restante son atacantes que saben cómo evadir esos sistemas: usan binarios legítimos del sistema operativo (living off the land), operan lentamente para no disparar anomalías estadísticas, personalizan su malware para no coincidir con firmas conocidas.

Esos atacantes solo los detectas si los buscas activamente. Eso es threat hunting.

¿Qué es el threat hunting?

El threat hunting (caza de amenazas) es la búsqueda proactiva e iterativa de indicadores de compromiso o comportamientos maliciosos en un entorno, usando telemetría existente, sin depender de alertas automáticas.

La diferencia clave con el monitoreo tradicional:

Monitoreo reactivo

El sistema genera una alerta → el analista investiga. Solo detectas lo que el sistema sabe buscar. Si el atacante evade las reglas, no hay alerta. Eres reactivo por diseño.

Threat Hunting

El analista formula una hipótesis → busca evidencia en la telemetría → confirma o descarta. Buscas lo que los sistemas no saben buscar todavía. Eres proactivo por diseño.

💡 El tiempo de permanencia (dwell time)

El tiempo promedio que un atacante permanece en una red antes de ser detectado es de 21 días (IBM X-Force 2024). El threat hunting apunta a reducir ese número encontrando actores antes de que completen su objetivo.

El proceso de threat hunting

Paso 1: Formular una hipótesis

Una hunt empieza con una pregunta: "¿Hay algún proceso en mis endpoints que esté usando PowerShell de forma inusual para exfiltrar datos?" o "¿Hay comunicaciones de mis servidores a dominios generados algorítmicamente (DGA)?"

Las hipótesis provienen de:

MITRE ATT&CK: cada técnica es una hipótesis potencial. "¿Tengo evidencia de T1055 (Process Injection) en mi entorno?"
Threat Intelligence: reportes de grupos APT que atacan tu industria. Si Lazarus Group usa LSASS dumping, huntas para eso.
Incidentes pasados: ¿cómo entraron la última vez? ¿Ese vector sigue expuesto?
Intuición del experto: patrones que el analista percibe como anómalos en el comportamiento del entorno.

Paso 2: Recopilar y analizar la telemetría

El threat hunter trabaja con datos brutos, no con alertas. Las fuentes típicas:

Telemetría de EDR: procesos, conexiones de red, archivos creados/modificados, carga de módulos, acceso a registros de Windows
Logs de autenticación: intentos de login, escalada de privilegios, creación de usuarios
Tráfico de red (VPC Flow Logs, PCAP): conexiones inusuales, volumen de datos, protocolos no estándar
Logs de aplicación: errores inusuales, accesos a datos fuera de horario, queries anómalas

Paso 3: Analizar patrones

Técnicas comunes de análisis:

Stack counting: agrupar por frecuencia. Los outliers (valores que aparecen una sola vez) son sospechosos.
Baseline comparison: comparar el comportamiento actual contra el histórico normal. Una app que nunca hacía conexiones externas y ahora hace 100 al día es un indicador.
Clustering: agrupar comportamientos similares y buscar el que no encaja.
Graph analysis: mapear relaciones entre entidades (quién llamó a quién, qué proceso lanzó cuál).

Paso 4: Convertir hallazgos en detecciones

Si la hunt encuentra algo — o confirma que el comportamiento es legítimo — el resultado se convierte en mejora del sistema de detección. El hallazgo malicioso se convierte en una nueva regla de SIEM. El falso positivo reduce el ruido futuro.

⚠️ Sin datos, no hay hunt

El threat hunting requiere telemetría rica. Si tu EDR no guarda logs de procesos de los últimos 30 días, si tus VPC Flow Logs están desactivados, si no tienes logs de autenticación centralizados — no puedes huntear. La inversión en visibilidad es la pre-condición del threat hunting.

MITRE ATT&CK como guía de hunting

MITRE ATT&CK es el framework perfecto para estructurar las hipótesis de hunting. Cada técnica tiene:

Descripción de cómo funciona
Procedimientos específicos usados por grupos conocidos
Fuentes de datos recomendadas para detectarla
Mitigaciones

Una forma de priorizar: tomar las técnicas más usadas en tu industria (según los reportes de Mandiant, CrowdStrike, SentinelOne) y sistematizar hunts para cada una. Si un grupo APT relevante usa T1003.001 (LSASS Memory), hunteas eso en tu entorno.

-- Ejemplo: hunt para LSASS credential dumping en telemetría de EDR
-- Procesos que acceden a lsass.exe con permisos de lectura de memoria

SELECT 
  timestamp,
  hostname,
  source_process,
  source_process_pid,
  target_process,
  access_rights,
  user_name
FROM process_access_events
WHERE 
  target_process ILIKE '%lsass.exe%'
  AND access_rights IN ('0x1010', '0x1410', '0x1038')  -- PROCESS_VM_READ
  AND source_process NOT IN (
    'svchost.exe', 'wininit.exe', 'csrss.exe',  -- procesos legítimos conocidos
    'MsMpEng.exe', 'CrowdStrike.exe'
  )
  AND timestamp >= NOW() - INTERVAL '7 days'
ORDER BY timestamp DESC;

Herramientas para threat hunting

CrowdStrike Falcon Overwatch / Insight: la plataforma donde más he trabajado. Telemetría de endpoint increíblemente rica, Query Language (FQL) potente para hunts.
SentinelOne Singularity: Deep Visibility para hunting sobre telemetría raw.
Elastic SIEM + Kibana: excelente para hunts sobre logs de red y aplicación.
MITRE ATT&CK Navigator: para planificar la cobertura de técnicas.
MISP: plataforma de threat intelligence para contextualizar los hallazgos.

✅ Cómo empezar si eres un solo analista

No necesitas un equipo dedicado para empezar. Elige una técnica de MITRE ATT&CK relevante para tu entorno, busca los datos que necesitas para detectarla, y dedica 2 horas a la semana a esa hunt. Itera. Cada hunt que no encuentra nada confirma que esa técnica no está activa — o mejora tu visibilidad para la próxima vez. La consistencia supera la perfección.

¿Estás empezando con threat hunting? Escríbeme — tengo experiencia directa desde operaciones de SOC.