Threat hunting no es triaje de alertas con otro nombre. El hunter parte de una hipótesis y prueba contra los datos; el analista de SOC responde a una alerta generada por una regla. Ambos roles son necesarios y conviene separarlos: si el hunter está cubriendo cola de alertas, no está cazando.
Qué es threat hunting
Threat hunting es la búsqueda proactiva de adversarios que ya están dentro del entorno, sin esperar a que dispare una alerta. Parte de una hipótesis razonada (por ejemplo, «un atacante con acceso inicial usaría persistencia mediante tarea programada» o «el grupo X que se mueve en nuestro sector exfiltra por DNS lento») y la prueba contra la telemetría disponible: endpoints, identidades, red, cloud, correo. La hipótesis suele apoyarse en TTPs de MITRE ATT&CK, en informes de inteligencia de amenazas y en el conocimiento del propio negocio. A diferencia del SOC tradicional, el hunter no recibe alertas: las construye. Por eso es la única función capaz de cazar adversarios que aún no han hecho ruido y de generar detecciones nuevas que luego van al SIEM.
Por qué importa
Para una organización con SOC operando, el mensaje incómodo es que la mayoría de los incidentes graves de los últimos años se descubrieron por una pista externa (un proveedor, un cliente, un investigador) y no por una alerta interna. La mediana de tiempo de permanencia ha bajado, pero sigue midiéndose en semanas o meses según informes públicos. Threat hunting cubre esa franja: el adversario que ya pasó los controles preventivos y que aún no ha disparado la regla del SIEM. Cada hipótesis verificada deja un activo permanente, una nueva regla de detección o un caso de uso afinado que mejora la capacidad del SOC para el resto del año. Para programas regulados (NIS2, DORA, ISO 27001) el hunting aporta evidencia de capacidad defensiva activa, no solo de capacidad reactiva, lo que es cada vez más exigido por auditoría.
Puntos clave
Las hipótesis se construyen sobre tres fuentes. TTPs concretos de MITRE ATT&CK que aplican al sector de la organización, informes de inteligencia de amenazas sobre actores que están activos contra cargas parecidas y conocimiento del propio entorno (qué identidades son privilegiadas, qué activos serían objetivo de extorsión).
El hunting necesita telemetría suficiente. EDR con visibilidad de procesos y línea de comandos, logs de identidad (Entra ID, on-prem AD), DNS, proxy, autenticaciones en aplicaciones críticas y, si aplica, telemetría cloud (CloudTrail, Azure Activity, GCP Audit). Sin esa base, las hipótesis son ejercicios teóricos sin posibilidad de verificación.
Cada hunting deja productos. Una regla nueva en el SIEM, una alerta afinada, una mejora del playbook, una recomendación de hardening o, en el peor caso, un incidente abierto. Una sesión que no entrega ninguna de esas cinco salidas es una sesión perdida y conviene revisar la hipótesis o la calidad de los datos.
Los marcos públicos ayudan a estructurar el trabajo. SANS publica un modelo de madurez de hunting y la propia documentación de MITRE incluye técnicas con ejemplos de detección. Apoyarse en estos marcos evita reinventar la rueda y facilita la comunicación con auditoría y con clientes internos.
Threat hunting es complementario al SOC gestionado y a la respuesta a incidentes. El SOC monitoriza, el hunter caza y respuesta contiene. En organizaciones medianas las tres funciones pueden compartir personas, pero el tiempo dedicado a cada una debe estar claro: si todo es respuesta, no hay caza.
Ejemplo: hunt mensual de persistencia y C2 en una empresa con Microsoft 365 y EDR
Una empresa con SOC interno, EDR desplegado y Microsoft 365 como núcleo de colaboración decide programar un ciclo mensual de threat hunting. En el primer ciclo se eligen dos hipótesis concretas. La primera, basada en TTPs frecuentes (T1053 Scheduled Task de MITRE ATT&CK), busca tareas programadas creadas por procesos no administrativos en estaciones que no son de IT. La segunda, basada en informes recientes sobre el sector, busca señales de C2 sobre DNS lento y comunicaciones salientes a dominios de paste sites desde procesos del paquete Office.
El equipo consulta telemetría de EDR, logs de DNS y registros de creación de tareas durante los últimos noventa días. La primera hipótesis devuelve cero hallazgos relevantes, pero detecta que las consultas no llegan completas desde dos sedes pequeñas; ese hallazgo, aunque no es un incidente, alimenta una mejora de cobertura. La segunda hipótesis encuentra un patrón de balizamiento sobre DNS en una estación del departamento financiero. Se abre un indicador de compromiso y, tras análisis forense en frío, se confirma un implant con conectividad C2 activa pero sin acción posterior visible. Respuesta a incidentes aísla la estación, recoge memoria, busca movimiento lateral y persistencia en activos adyacentes y completa el ciclo. El hunting entrega tres salidas: el incidente contenido, una regla nueva en SIEM para detectar el patrón de balizamiento en el futuro y un gap de cobertura documentado en las dos sedes.
Errores habituales
- Confundir threat hunting con escribir más reglas en el SIEM. Las reglas las debe escribir cualquiera con conocimiento de detección; el hunting parte de una hipótesis y prueba contra datos. La salida puede ser una regla, pero el ejercicio no es escribir reglas sin contexto.
- Lanzar hunts sin telemetría adecuada. Si el EDR no captura línea de comandos, si los logs de identidad no llegan al SIEM o si DNS interno no se almacena, las hipótesis se vuelven ejercicios teóricos. Primero datos, después hunting.
- Hacer hunting solo cuando aparece tiempo libre. Sin cadencia (mensual o quincenal según madurez) y sin objetivos de cobertura por categoría ATT&CK, el programa se evapora en cuanto sube la carga de alertas.
- No documentar el resultado. Una sesión sin hipótesis registrada, fuentes de datos consultadas y salida concreta (regla, mejora, incidente) no es auditable ni reproducible. El registro es la mitad del valor del hunting.
- Asumir que con threat intelligence comprada ya hay hunting. La inteligencia es un insumo; sin hunters que la traduzcan en hipótesis sobre el entorno propio, los informes mensuales se acumulan sin convertirse en detección.
Términos relacionados
Servicios relacionados
Este concepto puede tener relación con servicios como:
Preguntas frecuentes
¿En qué se diferencia el threat hunting del SOC tradicional?
El SOC tradicional responde a alertas generadas por reglas predefinidas. Threat hunting parte de hipótesis razonadas y busca activamente actividad maliciosa que aún no ha disparado ninguna regla. El SOC detecta lo conocido; el hunter caza lo desconocido. Ambas funciones son necesarias y conviene separarlas para que ninguna canibalice tiempo de la otra.
¿Qué datos hace falta tener para empezar a hacer hunting?
La base mínima es EDR con visibilidad de procesos y línea de comandos, logs de identidad (Entra ID o Active Directory), logs de DNS, logs de proxy o navegación y registros de autenticación en aplicaciones críticas. Si la organización vive en cloud hace falta además telemetría de CloudTrail, Azure Activity o GCP Audit. Sin esa base las hipótesis no se pueden verificar.
¿Con qué frecuencia se hace threat hunting?
Depende de la madurez. Programas iniciales arrancan con una sesión al mes centrada en una o dos hipótesis. Programas maduros tienen hunting continuo distribuido por categorías de MITRE ATT&CK con cobertura medible. Lo importante es la cadencia: sin frecuencia regular el programa se evapora cuando sube la carga del SOC.
¿Hace falta inteligencia de amenazas para hacer hunting?
Ayuda mucho, pero no es estrictamente obligatorio. Se puede arrancar con TTPs públicos de MITRE ATT&CK y conocimiento del propio entorno. La inteligencia de amenazas eleva la calidad de las hipótesis porque permite priorizar a los actores y técnicas que están activos contra cargas parecidas en el momento del ejercicio.
¿Threat hunting puede subcontratarse?
Sí. Un servicio gestionado de threat hunting aporta capacidad continua sin necesidad de mantener el rol internamente. La condición es que tenga acceso a la telemetría suficiente y que entregue productos concretos (reglas nuevas, mejoras de cobertura, hipótesis ejecutadas con resultado), no solo informes mensuales genéricos.