Threat Hunting:

cómo buscar amenazas antes de que salten las alarmas

Serie Blue Team  |  unfantasmaenelsistema.com

Un SOC bien montado tiene decenas de reglas de detección, un SIEM que correla eventos y alertas que llegan a un analista cuando algo encaja con un patrón conocido. Todo eso es detección reactiva: funciona cuando el atacante hace algo que ya sabíamos buscar. El problema es el hueco que queda: el adversario que se mueve despacio, con herramientas legítimas y sin disparar ninguna firma. Ese intruso puede estar semanas dentro sin que ninguna alarma suene.

El threat hunting es la disciplina que ataca ese hueco. En lugar de esperar a que salte una alerta, un analista formula una hipótesis —»si hubiera un atacante usando esta técnica, dejaría este rastro»— y va a los datos a comprobarla. Este artículo explica cómo se estructura esa búsqueda: de dónde salen las hipótesis, qué datos hacen falta, qué técnicas de análisis se usan y cómo el resultado de un hunt mejora la detección automática para la próxima vez.

1. Qué es —y qué no es— el threat hunting

Threat hunting es la búsqueda proactiva e iterativa de actividad maliciosa que ha evadido los controles de detección existentes. Las tres palabras importan. Proactiva: se lanza sin que haya una alerta previa. Iterativa: cada búsqueda refina la siguiente. Y evadido los controles: se asume que el atacante ya está dentro y que las herramientas automáticas no lo han visto.

Esa asunción —la hipótesis de la brecha— es lo que separa al hunter del analista de SOC. El analista pregunta «¿esta alerta es real?». El hunter pregunta «¿qué está pasando que nadie me está contando?».

El hunting se apoya en las otras tres y las alimenta. Cuando un hunt encuentra algo, se convierte en un incidente y arranca la respuesta. Cuando un hunt no encuentra nada pero descubre un punto ciego en la telemetría, mejora la detección. Un hunt «sin resultado» rara vez es tiempo perdido: casi siempre deja una regla nueva, una fuente de logs que faltaba o una línea base documentada.

2. La pirámide del dolor: qué merece la pena cazar

David Bianco propuso en 2013 la pirámide del dolor, y sigue siendo la mejor guía para decidir sobre qué construir un hunt. La idea: los indicadores de compromiso no son todos iguales; algunos le cuestan al atacante un segundo cambiarlos y otros le obligan a rehacer su operación entera.

La moraleja para el hunter: cazar en la base de la pirámide es barato pero efímero. Un hunt de hashes o IPs caduca en días. Un hunt sobre comportamiento —»procesos de Office que lanzan PowerShell codificado», «cuentas de servicio que de repente hacen logon interactivo»— sigue siendo válido meses después y afecta a familias enteras de adversarios, no a una sola muestra.

3. De dónde salen las hipótesis

Un hunt sin hipótesis es solo mirar logs con la esperanza de que salte algo a la vista. Una hipótesis buena es concreta, comprobable con los datos que tienes y ligada a una amenaza plausible para tu organización. Hay tres fuentes principales.

3.1 Basadas en ATT&CK (orientadas a técnica)

Se parte del catálogo de MITRE ATT&CK y se elige una técnica relevante para tu entorno. La hipótesis toma la forma: «un adversario podría estar usando T1053.005 (Scheduled Task) para persistir; si es así, veríamos creación de tareas programadas fuera de las ventanas de despliegue y por parte de procesos inusuales». Priorizar es más fácil si cruzas ATT&CK con tu modelo de amenazas: qué grupos te apuntan, qué técnicas usan, cuáles de esas técnicas cubre ya tu detección y cuáles no.

3.2 Basadas en inteligencia (orientadas a actor o campaña)

Sale un informe sobre una campaña activa contra tu sector. El informe describe TTP concretas: un cargador que escribe en una ruta determinada, un patrón de beaconing, el abuso de una utilidad firmada. La hipótesis: «si esta campaña nos ha alcanzado, encontraríamos <estos artefactos> en nuestros hosts». Es el tipo de hunt más urgente y el más acotado en tiempo.

3.3 Basadas en anomalía (orientadas a datos)

No hay técnica ni informe de partida: se explora una fuente de datos buscando lo que se sale de la norma. «¿Qué ejecutables solo aparecen en un host de toda la flota?» «¿Qué destinos DNS reciben peticiones a intervalos sospechosamente regulares?» Requiere conocer bien qué es normal en tu red, y por eso suele dar sus mejores frutos cuando ya existe una línea base.

4. El bucle del hunt

El hunting es cíclico. Una vuelta completa tiene cuatro fases, y la salida de la cuarta realimenta a la primera.

• 1. Hipótesis. Se formula una afirmación concreta y comprobable sobre actividad maliciosa posible, con su fuente (ATT&CK, inteligencia o anomalía) y el rastro esperado.
• 2. Datos. Se identifica qué telemetría respondería a la pregunta y se comprueba que existe, que cubre el periodo y el alcance necesarios, y que es fiable. Aquí se descubren la mitad de los puntos ciegos.
• 3. Análisis. Se consultan y transforman los datos —filtrado, agregación, stacking, correlación— hasta poder afirmar o negar la hipótesis. Los hallazgos ambiguos se investigan hasta resolverlos.
• 4. Documentar y mejorar. Se registra el hunt (hipótesis, consultas, resultado). Si hubo hallazgo malicioso, se abre incidente. En todo caso: la lógica que funcionó se convierte en regla de detección, y los datos que faltaban se añaden a la cola de ingesta.

Ese cuarto paso es el que hace que el programa madure. Un equipo que caza pero no documenta repite los mismos hunts y nunca reduce su superficie ciega. Un equipo que convierte cada hunt exitoso en detección automática va trasladando trabajo del analista a la máquina y libera tiempo para cazar cosas más difíciles.

5. Las fuentes de datos que necesitas

El hunting es tan bueno como la telemetría que lo sustenta. Estas son las fuentes que aportan más por hunt, y qué tipo de pregunta responde cada una.

6. Técnicas de análisis

6.1 Stacking por frecuencia (frequency analysis)

La técnica más rentable y la más sencilla. Se toma un atributo —nombre de proceso padre de `powershell.exe`, ruta de un servicio, nombre de tarea programada, user-agent— y se cuenta cuántas veces aparece cada valor en toda la flota. Lo interesante casi nunca es lo más frecuente (eso es la línea base); es la cola larga: los valores que aparecen una o dos veces.

-- Pseudo-consulta: procesos padre de powershell.exe, ordenados por rareza
SELECT parent_image, COUNT(*) AS n, COUNT(DISTINCT host) AS hosts
FROM process_events
WHERE image LIKE '%\powershell.exe'
  AND event_time > now() - INTERVAL 7 DAY
GROUP BY parent_image
ORDER BY n ASC;   -- lo raro primero, no lo comun
 
-- winword.exe u outlook.exe como padre de powershell = mirar ya

6.2 Least-common / outliers

Variante del stacking centrada en el extremo: «enséñame los ejecutables que solo existen en un host de los 4.000», «los servicios cuyo binario está en una ruta que no usa nadie más». Un atacante que despliega una herramienta propia genera, por definición, un artefacto poco común. No todo outlier es malicioso —software de nicho, cacharreo de un administrador— pero la lista es corta y se revisa entera.

6.3 Baselining (línea base)

Consiste en documentar qué es normal para poder reconocer lo anormal: qué cuentas hacen logon en los controladores de dominio, qué procesos hacen conexiones salientes a Internet, a qué hora corren las tareas programadas legítimas, qué rango de volumen de datos sube cada host. Con la línea base escrita, muchos hunts se reducen a «muéstrame lo que se sale de esto».

6.4 Agrupación y análisis temporal

Para C2 sobre HTTP o DNS, el patrón revelador no es el destino sino el ritmo: peticiones a intervalos casi constantes durante horas. Se agrupan las conexiones por par origen-destino y se estudia la distribución de tiempos entre peticiones. Una desviación típica muy baja —con o sin jitter aleatorio superpuesto— delata un beacon automatizado frente al tráfico irregular de un humano.

7. Ejemplos de hunts concretos

Ninguno de estos hunts depende de un IOC concreto: todos describen un comportamiento. Por eso siguen siendo útiles cuando el atacante cambia de infraestructura, y por eso los buenos hunts acaban convertidos en reglas de detección estables.

8. Madurez del equipo de hunting

El modelo de madurez de hunting (HMM) de David Bianco describe cinco niveles según el grado de automatización y la calidad de los datos. Sirve para situarse y para saber cuál es el siguiente paso realista.

El salto que más rinde es de HMM1 a HMM2: pasar de «buscar IOCs sueltos» a «tener los datos centralizados y aplicar procedimientos repetibles». El salto a HMM4 no significa dejar de cazar, sino que cada hunt bueno se convierte en regla y el equipo siempre está cazando en terreno nuevo.

Conclusión

El threat hunting parte de asumir que la detección automática tiene huecos y que un atacante puede estar ya dentro sin haber disparado ninguna alerta. El trabajo del hunter es formular hipótesis concretas y comprobables —desde ATT&CK, desde inteligencia o desde anomalías en los datos— e ir a la telemetría a confirmarlas o descartarlas.

El valor duradero está en cazar comportamientos, no indicadores: la pirámide del dolor explica por qué un hunt de TTP afecta a familias enteras de adversarios mientras que uno de hashes caduca en días. Las técnicas base —stacking por frecuencia, least-common, baselining, análisis temporal— no necesitan herramientas caras, solo datos centralizados y saber qué es normal.

Y el bucle se cierra en el cuarto paso: documentar el hunt y convertir lo que funcionó en detección automática. Un programa de hunting maduro no es el que caza más, es el que traslada sin parar trabajo del analista a la máquina y siempre está buscando en el terreno que todavía nadie sabe automatizar.

unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)