Que es Threat Hunting: Metodologia Completa para Equipos

Que es el Threat Hunting

TL;DR: El threat hunting es la búsqueda proactiva e iterativa de amenazas que han logrado evadir las defensas automáticas de una organización. A diferencia de la detección reactiva que depende de firmas conocidas, esta técnica parte de la premisa de que el adversario ya está infiltrado en el sistema. Se recomienda adoptar un enfoque basado en hipótesis para robustecer el SOC y anticiparse a ataques sofisticados.

El threat hunting (caza de amenazas) es la busqueda proactiva de actividad maliciosa dentro de una red o sistema que ha evadido los controles de seguridad existentes. A diferencia de la detección tradicional, que espera a que una alerta se dispare, el hunting parte de la premisa de que un adversario ya esta dentro y busca evidencia de su presencia.

Esta definición, acunada originalmente por el equipo de Sqrrl (adquirido por Amazon Web Services en 2018), enfatiza tres elementos clave: es proactivo, es iterativo y asume compromiso. No se trata de revisar alertas pendientes del SIEM, sino de formular preguntas que las reglas automatizadas no cubren.

Un threat hunter no espera a que suene la alarma. Plantea escenarios del tipo "si un adversario quisiera exfiltrar datos de esta red, como lo haria" y busca las huellas de esa actividad en los datos disponibles.

Detección Reactiva vs Hunting Proactivo

Para entender el valor del hunting, conviene compararlo con el modelo tradicional de detección:

Detección reactiva (modelo clasico)

El modelo clasico funciona así: un vendor pública una firma, el equipo la despliega en el SIEM o IDS, y cuando un evento coincide con la firma, se genera una alerta. El analista investiga la alerta y determina si es un verdadero positivo.

Este modelo tiene limitaciones conocidas. Solo detecta amenazas para las que existen firmas. Los adversarios sofisticados usan técnicas que no coinciden con firmas conocidas: living-off-the-land binaries (LOLBins), herramientas legitimas como PowerShell o WMI, y tacticas personalizadas que no aparecen en bases de datos de firmas.

Hunting proactivo

El hunting invierte el flujo. En lugar de esperar eventos que coincidan con reglas, el hunter formula una hipotesis sobre una amenaza potencial y busca evidencia en los datos telemetricos existentes. Si encuentra indicios, profundiza. Si no encuentra nada, ajusta la hipotesis o pasa a la siguiente.

La diferencia fundamental: la detección reactiva es alert-driven (dirigida por alertas), mientras que el hunting es hypothesis-driven (dirigido por hipotesis).

Tabla comparativa

Aspecto	Detección Reactiva	Threat Hunting
Inicio	Una alerta se dispara	El hunter formula una hipotesis
Enfoque	Amenazas conocidas	Amenazas desconocidas o no detectadas
Automatización	Alta (reglas, firmas)	Baja (análisis humano con herramientas)
Frecuencia	Continua (24/7)	Periodica (sprints, campanas)
Skill requerido	Analista N1/N2	Analista N2/N3 con experiencia ofensiva
Output	Alerta investigada	Hipotesis validada + nueva regla de detección

Ambos enfoques son complementarios. El hunting no reemplaza la detección automatizada: la mejora. Cada hunt exitoso deberia producir nuevas reglas de detección que se incorporan al SIEM o EDR.

El Ciclo del Threat Hunting

El threat hunting sigue un ciclo iterativo con cuatro fases principales. Este modelo, popularizado por Sqrrl y adoptado por SANS, proporciona estructura a una actividad que de otro modo seria ad hoc.

Fase 1: Formulacion de hipotesis

Todo hunt comienza con una hipotesis. Una buena hipotesis es específica, testeable y basada en inteligencia o conocimiento del entorno.

Ejemplos de hipotesis:

• "Un adversario esta usando DNS tunneling para exfiltrar datos de la red corporativa"
• "Hay procesos de PowerShell ejecutando scripts codificados en Base64 desde directorios temporales"
• "Existe movimiento lateral via WMI entre servidores del segmento de bases de datos"

Las hipotesis pueden originarse de varias fuentes:

Inteligencia de amenazas (intelligence-driven). Un nuevo informe de CTI describe una campana que usa una técnica específica. El hunter busca evidencia de esa técnica en su entorno. Por ejemplo, si CISA pública un advisory sobre APT29 usando envenenamiento de Active Directory, el hunter busca indicadores de esa técnica.

Framework ATT&CK (attack-driven). El hunter selecciona una técnica del framework MITRE ATT&CK que no tiene cobertura de detección y busca evidencia de su uso. Por ejemplo, T1053.005 (Scheduled Task) en sistemas donde no hay reglas especificas para detectar tareas programadas maliciosas.

Anomalias (anomaly-driven). El hunter identifica desviaciones del comportamiento normal: un servidor que empieza a comunicarse con IPs en paises inusuales, un usuario que accede a recursos fuera de su patron habitual, o un proceso que genera tráfico de red atipico.

Fase 2: Investigación

Con la hipotesis definida, el hunter recopila y analiza datos. Esto implica:

• Identificar las fuentes de datos relevantes (logs de endpoint, tráfico de red, logs de autenticación)
• Construir consultas de busqueda en el SIEM, EDR o herramientas de análisis
• Analizar los resultados buscando patrones que confirmen o refuten la hipotesis
• Pivotar sobre hallazgos intermedios para profundizar

La investigación requiere conocimiento profundo de dos áreas: el comportamiento normal del entorno (baseline) y las técnicas que usan los adversarios. Sin baseline, todo parece anomalo. Sin conocimiento ofensivo, las anomalias reales pasan desapercibidas.

Fase 3: Descubrimiento y respuesta

Si la investigación revela actividad maliciosa confirmada, el hunt transiciona a respuesta a incidentes. El hunter documenta los hallazgos, determina el alcance del compromiso y coordina con el equipo de respuesta.

Si no se encuentra actividad maliciosa, eso también es un resultado valido. Significa que la hipotesis ha sido testeada contra los datos disponibles y no hay evidencia de compromiso. Sin embargo, "no encontrar nada" no es lo mismo que "no hay nada". Las limitaciones en la visibilidad (gaps en logging, periodos de retencion cortos) siempre deben documentarse.

Fase 4: Automatización y retroalimentacion

El paso final y más importante del ciclo: convertir los hallazgos en detección automatizada. Si el hunt descubrio una técnica nueva, el hunter escribe una regla Sigma, YARA o KQL que detecte esa técnica de forma automática en el futuro.

Este paso cierra el ciclo: lo que antes era una busqueda manual se convierte en detección automatizada, liberando al hunter para buscar la siguiente amenaza desconocida.

Ciclo del Threat Hunting:

  Hipotesis --> Investigacion --> Descubrimiento --> Automatizacion
      ^                                                    |
      |____________________________________________________|
                    (retroalimentacion)

Frameworks de Threat Hunting

Varios frameworks proporcionan estructura adicional al proceso de hunting.

MITRE ATT&CK como mapa de cobertura

ATT&CK es el framework más usado para planificar hunts. Cada técnica (T-code) describe una accion que un adversario puede realizar. El hunter mapea las técnicas contra la cobertura de detección existente e identifica gaps: técnicas sin reglas, sin visibilidad o sin datos para detectarlas.

Un heat map de ATT&CK donde las técnicas cubiertas están en verde y las descubiertas en rojo proporciona una vista inmediata de donde concentrar los esfuerzos de hunting.

TaHiTI (Targeted Hunting integrating Threat Intelligence)

TaHiTI, desarrollado por FI-ISAC (Financial ISAC holandesa), es un framework que estructura el proceso de hunting en tres fases: initiation, hunting y finalization. Su foco esta en integrar inteligencia de amenazas como motor principal de las hipotesis.

PEAK (Prepare, Execute, Act, Knowledge)

PEAK, creado por SplunkSURGe, organiza el hunting en cuatro fases con enfasis en la preparacion (entender el entorno y las fuentes de datos) y en la gestión del conocimiento (documentar y compartir hallazgos).

Tipos de Threat Hunting

No todos los hunts son iguales. Existen tres tipos principales segun el disparador y el enfoque.

Hunting estructurado (hypothesis-driven)

Es el tipo más riguroso. Parte de una hipotesis formal, sigue un plan de investigación documentado y produce resultados reproducibles. Es el tipo recomendado para equipos con cierta madurez.

Ejemplo: "Hipotesis: adversarios están abusando de certutil.exe para descargar payloads en nuestros endpoints Windows. Plan: buscar ejecuciones de certutil con parámetros -urlcache o -split en logs de Sysmon Event ID 1 de los últimos 30 dias."

Hunting no estructurado (IOC-driven)

Parte de un indicador específico (un hash, una IP, un dominio) obtenido de un feed de inteligencia o un reporte de incidente. El hunter busca ese indicador en los datos historicos y pivota sobre los hallazgos.

Es el tipo más simple de hunting y a menudo se solapa con la respuesta a incidentes. Sin embargo, sigue siendo proactivo porque busca indicadores que las reglas automatizadas no están verificando.

Hunting situacional

Responde a un cambio en el entorno o contexto: una nueva vulnerabilidad publicada, una fusion empresarial, un cambio de infraestructura o un evento geopolitico. El hunter evalua como ese cambio puede alterar el perfil de riesgo y busca amenazas asociadas.

Ejemplo: tras la publicacion de CVE-2024-3400 (PAN-OS), un hunt situacional buscaria indicadores de explotación en los firewalls Palo Alto de la organización.

Datos Necesarios para el Hunting

La calidad del hunting depende directamente de la calidad y cobertura de los datos disponibles. Sin telemetria, no hay hunting posible.

Fuentes de datos esenciales

Logs de endpoint. Sysmon en Windows es la fuente más rica: creación de procesos (Event ID 1), conexiones de red (ID 3), creación de archivos (ID 11), carga de drivers (ID 6) y modificaciones de registro (ID 13). En Linux, auditd proporciona visibilidad similar.

Logs de red. Zeek (antes Bro) genera registros detallados de conexiones TCP/UDP, consultas DNS, sesiones HTTP y certificados SSL. Los logs de firewall y proxy complementan la visibilidad de red.

Logs de autenticación. Active Directory genera eventos clave: logon exitoso (4624), logon fallido (4625), creación de sesión con privilegios (4672), uso de Kerberos (4768/4769). Estos logs son fundamentales para detectar movimiento lateral y acceso a credenciales.

Logs de aplicación. Servidores web, bases de datos, aplicaciones cloud (O365, GCP, AWS CloudTrail) y herramientas de colaboracion generan logs que complementan la visibilidad.

Retencion de datos

Un aspecto critico: los adversarios avanzados pueden mantener persistencia durante meses. Si los logs solo se retienen 30 dias, un hunt sobre actividad de hace tres meses es imposible. La recomendacion mínima es 90 dias para logs operacionales y 12 meses para logs de seguridad clave.

Habilidades del Threat Hunter

Un buen threat hunter combina conocimientos de tres áreas:

Conocimiento ofensivo. Entender como piensan y operan los adversarios. No se necesita ser un pentester experto, pero si comprender las técnicas de ATT&CK a nivel práctico: como funciona un Pass-the-Hash, que aspecto tiene una inyección de proceso en los logs, como se configura un C2.

Conocimiento defensivo. Saber que datos generan los sistemas, donde buscar evidencia y como interpretar los logs. Esto incluye conocer los formatos de eventos de Windows, la estructura de logs de Zeek, las capacidades del SIEM y las limitaciones de cada fuente de datos.

Pensamiento analitico. Formular hipotesis, disenar investigaciones, interpretar resultados ambiguos y pivotar cuando la evidencia no es concluyente. El hunting es un proceso cientifico: hipotesis, observacion, conclusion.

Metricas de Éxito

Medir la efectividad del hunting es necesario para justificar la inversion y mejorar el programa. Las metricas más útiles son:

Hunts completados por período. Cuantos hunts se ejecutaron en el trimestre. Mide la actividad del programa.

Tasa de descubrimiento. Porcentaje de hunts que encontraron actividad maliciosa o sospechosa. Una tasa del 10-20% es normal y saludable. El 100% indicaria que solo se buscan cosas obvias.

Tiempo medio de descubrimiento (TTD). Cuanto tiempo pasa desde que una amenaza entra en la red hasta que el hunting la descubre. Comparar con el TTD de la detección automatizada muestra el valor anadido del hunting.

Reglas creadas. Número de reglas de detección nuevas generadas a partir de hunts. Esta es la metrica que mejor demuestra el valor del hunting: convierte lo desconocido en detectable.

Cobertura ATT&CK. Porcentaje de técnicas de ATT&CK que han sido objeto de al menos un hunt. Muestra el progreso del programa en cubrir el espectro de amenazas.

Errores Comunes al Empezar

Varios errores recurrentes afectan a los equipos que comienzan con el hunting:

Confundir hunting con respuesta a alertas. Revisar la cola del SIEM no es hunting. El hunting comienza donde terminan las reglas automatizadas.

No documentar los hunts. Sin documentación, los hallazgos se pierden, las hipotesis se repiten y el equipo no aprende. Cada hunt debe documentarse con hipotesis, fuentes de datos consultadas, consultas usadas, hallazgos y recomendaciones.

Buscar sin baseline. Si no conoces el comportamiento normal de tu red, no puedes identificar anomalias. Antes de cazar amenazas, documenta los patrones normales: que procesos se ejecutan en los servidores, que tráfico DNS es habitual, que horarios de acceso son tipicos.

No automatizar hallazgos. Si un hunt descubre una técnica nueva y el equipo no crea una regla de detección, el mismo hunt tendrá que repetirse manualmente. La automatización es el paso que multiplica el valor del hunting.

Intentar hacerlo todo a la vez. Los equipos nuevos deben empezar con hunts simples (buscar IOCs específicos, verificar una técnica concreta) e ir subiendo en complejidad a medida que adquieren experiencia y datos.

Conclusiones

El threat hunting es una capacidad esencial para cualquier equipo de seguridad que quiera ir más alla de la detección reactiva. No requiere herramientas costosas para empezar: un SIEM o EDR con buena telemetria, conocimiento del framework ATT&CK y un analista con curiosidad y metodologia son suficientes.

El valor real del hunting no esta solo en encontrar amenazas activas, sino en el ciclo completo: formular hipotesis, investigar, descubrir (o descartar) y automatizar. Cada iteracion de este ciclo mejora la postura de seguridad de la organización.

En los siguientes artículos de esta serie exploraremos el modelo de madurez de Sqrrl, como construir hipotesis basadas en ATT&CK y como usar herramientas especificas como Sysmon, Zeek, ELK y Velociraptor para ejecutar hunts efectivos.