Threat Hunting: Qué es y cómo funciona

Threat hunting es la práctica de buscar proactivamente a través de redes y endpoints atacantes que ya han superado tus detecciones existentes. Parte de un supuesto simple e incómodo: algo malo puede estar ya adentro, y ninguna alerta se disparó por ello. En lugar de esperar a que una regla SIEM se active, un cazador forma una hipótesis y busca evidencia para confirmarla o descartarla.

Por qué la detección sola no es suficiente

La detección basada en firmas y reglas atrapa patrones conocidos. Los atacantes que usan living-off-the-land binaries (LOLBins), credenciales válidas o técnicas lentas de bajo volumen pueden mantenerse bajo esos umbrales durante semanas. Threat hunting llena ese vacío al hacer que un humano cuestione activamente los datos: ¿tiene sentido esa invocación de PowerShell desde una estación de trabajo financiera a las 2 a.m.? ¿Por qué svchost.exe está haciendo una conexión saliente a una IP sin reverse DNS?

Esto no es incident response. IR comienza después de que sabes que algo sucedió. Hunting comienza cuando aún no lo sabes, y el objetivo es descubrirlo antes de que un evento más grande obligue a hacer la pregunta.

Los tres puntos de partida comunes

La mayoría de las búsquedas comienzan desde uno de tres ángulos:

• Impulsado por inteligencia: un nuevo threat report describe un TTP (por ejemplo, abuso de una tarea programada para persistence), y verificas si está presente en tu entorno.
• Conciencia situacional: observas qué es realmente inusual para tu organización — una cuenta de servicio autenticándose desde un país desde el que nunca lo ha hecho, o un pico en tráfico SMB entre estaciones de trabajo que normalmente solo hablan con servidores.
• Impulsado por analítica: construyes una línea base del comportamiento normal (árboles de procesos, tiempos de inicio de sesión, volumen de consultas DNS) y buscas outliers estadísticos contra ella.

MITRE ATT&CK es la referencia que la mayoría de los equipos usan para estructurar hipótesis. En lugar de "buscar malware", eliges una técnica como T1053 (Scheduled Task/Job) y preguntas: ¿qué parecería en nuestros Windows Event Logs o telemetría EDR, y puedo consultarlo ahora?

Cómo se ve el flujo de trabajo real

Una búsqueda generalmente sigue este ciclo:

1. Forma una hipótesis específica y comprobable (no "verificar intrusiones" sino "verificar nuevas tareas programadas creadas fuera de ventanas de parches en los últimos 30 días").
2. Identifica las fuentes de datos necesarias — Sysmon Event ID 1 para creación de procesos, Windows Security Event ID 4698 para creación de tareas programadas, árboles de procesos EDR, o logs de conexión Zeek para contexto de red.
3. Consulta y pivotea. En la práctica esto significa escribir KQL en Microsoft Sentinel, SPL en Splunk, o consultas directas contra un índice Elastic.
4. Realiza triage de resultados — la mayoría serán falsos positivos o actividad admin benignos, y el trabajo consiste en reducir ese ruido a lo que es genuinamente anómalo.
5. Documenta hallazgos, ya sea un compromiso confirmado, una brecha de detección, o simplemente un