Qué es threat hunting: definición, metodología y herramientas

El threat hunting es una práctica defensiva proactiva en la que un analista busca evidencia de actividad maliciosa que las herramientas automáticas de detección no han alertado. La diferencia con la operativa estándar de un SOC es la dirección del trabajo: el SOC reacciona a alertas que ya saltaron, el threat hunter parte de una hipótesis (un atacante con cierta TTP estaría en mi entorno) y busca evidencia activamente en logs, telemetría EDR, identidad y red. La asunción de partida es realista: si una alerta no ha saltado no significa que el atacante no esté.

Esta entrada explica qué es el threat hunting, en qué se diferencia de la detección reactiva, las tres metodologías más usadas, qué papel tiene MITRE ATT&CK, qué herramientas hacen falta y cómo encaja en un programa defensivo maduro.

Qué es el threat hunting

El threat hunting es la actividad de buscar manualmente actividad maliciosa que ha evadido los controles automáticos. La definición operativa que cualquier equipo serio acepta:

• Es proactivo, no reactivo. El analista no espera la alerta; va a buscarla.
• Es basado en hipótesis. Cada cacería empieza con una premisa concreta (un atacante haciendo kerberoasting estaría en este dominio, un infostealer estaría exfiltrando datos vía DNS, un atacante con persistencia vía scheduled tasks aparecería en estos logs).
• Es iterativo. Cada cacería confirma o descarta la hipótesis y produce nuevas reglas de detección, nuevas hipótesis o el inicio de un incidente formal.
• Es investigativo, no automático. El threat hunter usa herramientas (SIEM, EDR, sysmon) pero el cerebro lo pone él. Las herramientas dan visibilidad; la hipótesis y la decisión las pone el humano.

El threat hunting no sustituye a la detección automática. La complementa cubriendo el espacio entre lo que las reglas saben buscar y lo que un atacante hábil sabe esconder.

Threat hunting vs detección reactiva

Las dos disciplinas conviven en un programa defensivo maduro:

• Detección reactiva (SIEM, EDR, IDS): reglas y modelos que disparan alertas cuando un patrón conocido aparece. Operada por el SOC en turnos 24x7. Indispensable, pero limitada a lo que ya sabes buscar.
• Threat hunting: investigación activa sobre datos de los últimos días, semanas o meses para detectar lo que no disparó alerta. Suele ejecutarse por analistas senior fuera de turnos en cazas planificadas (típicamente 1-3 cazas semanales en programas establecidos).

La asunción crítica del hunting es que el atacante hábil sabe quedarse por debajo del umbral de las reglas: no usa Mimikatz visible, no llama a net group "Domain Admins", no se conecta directamente con PsExec. Usa Living Off the Land, abusa de procesos legítimos, hace pausas largas entre acciones. Las reglas SIEM no le ven; un humano que conoce sus TTPs sí.

Las tres metodologías de threat hunting

Cualquier programa de hunting profesional combina las tres en distintas proporciones.

1. Driven por hipótesis (hypothesis-driven)

Es la metodología más usada. El analista parte de una hipótesis concreta basada en threat intelligence reciente, en una TTP de MITRE ATT&CK o en un incidente externo del sector.

Ejemplo operativo. Tras la publicación de un advisory sobre PetitPotam (NTLM relay contra ADCS), el analista plantea la hipótesis: si un atacante intentara explotarlo en mi entorno, vería en logs de Active Directory autenticaciones de la cuenta de máquina del controlador de dominio contra el servidor ADCS desde IPs internas no esperadas. Lanza la query y busca evidencia.

2. Driven por indicadores (IoC-driven)

Parte de un indicador concreto: una IP, un hash, un dominio, una clave de registro publicada en un informe de threat intelligence reciente.

Ejemplo. CISA publica un advisory con 30 indicadores asociados a Akira ransomware. El analista busca esos indicadores en EDR, SIEM, DNS, proxy y firewall sobre una ventana de 90 días. Es la modalidad más rápida y la base mínima de cualquier programa.

Limitación: los IoCs caducan rápido. Una IP de C2 cambia en horas; un hash, en días. La cacería IoC-driven cubre incidentes recientes; no detecta atacantes que rotan infraestructura.

3. Driven por TTPs (TTP-driven)

La más madura. En lugar de buscar indicadores, busca comportamientos. Las técnicas de MITRE ATT&CK son el catálogo de referencia.

Ejemplo. La técnica T1078.002 (Valid Accounts: Domain Accounts) es muy usada por ransomware. El analista construye una caza recurrente que detecte autenticaciones exitosas de cuentas privilegiadas desde estaciones nuevas, desde IPs no habituales o fuera de horario. Es una cacería que cubre múltiples grupos y que sigue siendo útil cuando los IoCs específicos cambian.

Las cazas TTP-driven son las que más esfuerzo inicial piden y las que más vida útil tienen. Una caza bien construida sirve durante años con ajustes menores.

MITRE ATT&CK: el lenguaje común

MITRE ATT&CK es la matriz de referencia para describir comportamientos de atacantes. Está organizada en:

• Tácticas: el "por qué" de la fase. Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Command and Control, Exfiltration, Impact.
• Técnicas y subtécnicas: el "cómo" concreto. Por ejemplo bajo Credential Access aparecen OS Credential Dumping (T1003), Brute Force (T1110), Kerberoasting (T1558.003), entre otras.
• Procedimientos: implementaciones concretas observadas en campañas reales.

Para threat hunting:

• Plantear cazas mapeadas a técnicas concretas garantiza cobertura y permite medir.
• ATT&CK Navigator ayuda a visualizar qué técnicas tienen detección automática, cuáles están cubiertas por hunting y cuáles son ciegas.
• Los grupos APT y los marcos de threat intelligence comerciales (Mandiant, CrowdStrike, Microsoft) publican qué técnicas usa cada actor. Eso ayuda a priorizar qué cazas montar primero según el threat profile de la organización.

Herramientas que se usan en threat hunting

No hay un único producto "threat hunting". La caza se hace sobre la pila defensiva:

• SIEM: el corazón del hunting cuando los logs están bien centralizados. Splunk, Elastic, Sentinel, Chronicle, QRadar permiten queries flexibles sobre semanas o meses.
• EDR con telemetría rica: CrowdStrike, SentinelOne, Microsoft Defender for Endpoint, Elastic, Tanium. El EDR da visibilidad de procesos, líneas de comando, conexiones de red por proceso, modificaciones de registro, persistencia. Es la fuente más rica para hunting de endpoint.
• NDR (Network Detection and Response): ExtraHop, Vectra, Darktrace. Telemetría completa de red sin depender del endpoint. Útil para detectar exfiltración, túneles y movimiento lateral cuando el EDR no cubre todos los activos.
• Active Directory + Identity logs: Entra ID Audit, AD Security logs, Okta logs. La cacería de credenciales y movimiento lateral exige tener estos logs y no es trivial sin ellos.
• Threat intelligence: feeds comerciales (Recorded Future, Mandiant, Microsoft Defender TI) y abiertos (MISP, Open Threat Exchange) que aportan los IoCs y TTPs frescos sobre los que construir cazas.
• Plataformas de hunting dedicadas: Hunt by SpecterOps, Vectra Recall, Microsoft Defender XDR Hunting, Elastic Security. Permiten guardar cazas, ejecutarlas en programado y compartir resultados.

Lo más importante no es la herramienta sino los datos: si los logs críticos (Active Directory, DNS, proxy, firewall, EDR) no están centralizados con retención suficiente, no hay hunting posible.

Ejemplos de cazas frecuentes

Tres cazas que aparecen en cualquier programa serio:

Detección de kerberoasting

Hipótesis: si un atacante intenta kerberoasting, hará peticiones TGS-REQ contra cuentas con SPN. Caza: contar peticiones TGS-REQ por cuenta de origen en las últimas 24 horas, alertar cuando una cuenta pide más de N tickets de servicios distintos sin patrón conocido.

Persistencia vía scheduled tasks

Hipótesis: muchos atacantes crean scheduled tasks para persistencia. Caza: detectar creación de scheduled tasks (event 4698) cuyo comando ejecute PowerShell con argumentos sospechosos (-EncodedCommand, descarga remota), o cuya cuenta creadora no sea administrador conocido.

Exfiltración vía DNS

Hipótesis: un infostealer puede tunelizar exfiltración por DNS para evitar proxy. Caza: detectar dominios DNS con longitud anómala, frecuencia muy alta de queries únicas desde un endpoint, o consultas a dominios con baja reputación.

Cada caza confirmada genera una regla SIEM que la automatiza para el futuro.

Por qué el threat hunting reduce el dwell time

El dwell time (tiempo desde el acceso inicial del atacante hasta la detección) es la métrica que más impacta el coste de un incidente. Informes anuales (Mandiant M-Trends, IBM Cost of a Data Breach) sitúan el dwell time medio global en pocas semanas con tendencia a la baja, pero el atacante hábil que se mantiene bajo el umbral del SOC reactivo puede pasar meses dentro.

El threat hunting ataca exactamente ese gap: encuentra lo que los controles automáticos no han detectado. Programas maduros reportan reducciones medibles del dwell time tras introducir cazas regulares.

Threat hunting y compliance

• NIS2 (artículo 21). Eficacia de medidas técnicas y procedimientos de detección. Programas con hunting documentado y trazable forman parte de la evidencia.
• DORA (artículo 9). Capacidades de detección y respuesta en entidades financieras. El hunting es parte natural del programa.
• ENS (Real Decreto 311/2022, Marco Operacional). Detección de incidentes con frecuencia adecuada al nivel del sistema. El hunting cubre el escalón superior al monitoreo automático.
• ISO 27001:2022 (controles 8.16 y 5.7). Monitoring activities y threat intelligence. El hunting documentado evidencia ambos.

Errores comunes al montar un programa de threat hunting

Cuatro patrones que aparecen en programas que no terminan de cuajar:

1. Hunting sin datos suficientes. Sin logs de Active Directory, DNS internos, sysmon o EDR con telemetría completa, las cazas se quedan en superficiales. Antes de contratar hunters senior, asegurar la pila de logs.
2. Hunting sin hipótesis. "Mirar a ver qué encontramos" no es hunting. Cada caza necesita pregunta concreta y criterio de éxito.
3. No automatizar las cazas confirmadas. Cada caza confirmada debe convertirse en regla SIEM o EDR. Si no, el equipo repite la misma caza cada mes en lugar de avanzar.
4. Confundir hunting con response. Cuando una caza confirma actividad maliciosa, el siguiente paso es activar el playbook de incidente, no seguir investigando indefinidamente.

Preguntas frecuentes

¿Qué diferencia hay entre threat hunting y monitoreo de SOC?

El monitoreo del SOC es reactivo: gestiona alertas que ya disparó el SIEM o el EDR. El threat hunting es proactivo: el analista parte de una hipótesis y va a buscar evidencia que no disparó alerta. Son complementarios; un SOC maduro hace ambos.

¿Qué perfil tiene un threat hunter?

Senior. Combina conocimiento profundo de Windows interno, Active Directory, redes y al menos un SIEM y un EDR concretos. Lee informes de threat intelligence, traduce TTPs a queries y tiene paciencia para investigar sin alerta previa. Suele tener experiencia previa en SOC, blue team o incident response.

¿Hace falta un equipo dedicado o vale con que el SOC lo haga en huecos?

Depende de la madurez. Un programa inicial puede empezar con cazas semanales del propio SOC sobre IoCs publicados. Programas serios separan hunting del monitoreo reactivo, porque mezclar las dos disciplinas en el mismo turno satura al analista y dilata la investigación.

¿Cada cuánto se hace una caza?

Programas establecidos lanzan 1-3 cazas planificadas por semana, con duración variable (algunas se cierran en horas, otras requieren varios días de investigación cruzada). Cada caza queda documentada y, si confirma actividad maliciosa, se eleva a incidente formal.

¿Threat hunting requiere herramientas comerciales caras?

Ayudan, pero no son condición. Con un SIEM bien desplegado (Wazuh, Elastic SIEM, Sentinel en su tier base), un EDR con telemetría detallada y feeds de threat intelligence abiertos (MISP, Open Threat Exchange) se cubre el 80% del valor. La pieza no negociable es el dato: sin logs centralizados con retención, no hay hunting.

¿Cómo mido el éxito de un programa de hunting?

Métricas razonables: número de cazas ejecutadas, número de cazas que produjeron una nueva regla de detección, dwell time del último incidente confirmado, cobertura ATT&CK mapeada (qué porcentaje de técnicas relevantes para el threat profile están cubiertas con detección o hunting). Lo que no funciona es medir por número de incidentes detectados directamente: una buena caza puede no encontrar nada, lo cual también es información.

Recursos relacionados

• Qué es un SOC: el equipo y los procesos donde el threat hunting suele integrarse en organizaciones maduras.
• Qué es un SIEM: la plataforma donde el threat hunter ejecuta queries sobre semanas o meses de telemetría.
• Qué es un EDR: la fuente más rica de telemetría para hunting de endpoint.
• Tipos de malware: las familias cuyo comportamiento construye las hipótesis de hunting.
• Qué es un ransomware: la familia con dwell times más cortos en 2025-2026 y donde el hunting marca la diferencia entre detectar a tiempo y restaurar desde backup.

Threat hunting en Secra

En Secra apoyamos programas defensivos en la fase de threat hunting con análisis táctico (mapeo ATT&CK del threat profile, diseño de cazas, integración con SIEM/EDR existentes) y ejecución de cazas puntuales sobre la telemetría del cliente cuando se sospecha actividad o se quiere validar cobertura. Si tu equipo está montando un programa de hunting o quiere integrar inteligencia táctica al SOC, escríbenos a través de contacto o consulta nuestro servicio de threat intelligence.