Threat Hunting desde cero: metodología, hipótesis y ejemplos

1. Abres el SIEM: no hay alertas no significa que no haya actividad #

Abres el panel principal de tu SIEM o de tu consola de seguridad.

No hay ninguna alerta crítica en rojo parpadeando. El agente de endpoint tampoco muestra un incidente evidente. La cola de tickets de guardia está completamente en calma.

¿Significa eso que no hay un atacante operando dentro de la infraestructura corporativa?

No.

Significa únicamente que ninguna de las detecciones automáticas configuradas actualmente ha producido una señal suficiente para llamar tu atención.

Principio fundamental: No hay alertas no significa que no haya actividad.

Ahora imagina que tu equipo recibe un informe de inteligencia de amenazas: diversos grupos de ciberdelincuencia están abusando de comandos nativos del sistema operativo (Living off the Land) para enumerar grupos del dominio y recursos compartidos semanas antes de desplegar ransomware o exfiltrar bases de datos.

En ese momento te planteas una pregunta legítima:

«¿Está ocurriendo algo parecido en nuestros servidores y estaciones de trabajo en este mismo instante?»

No tienes una alerta concreta para investigar. No hay una campana de notificación sonando en la pantalla. Lo que tienes es una pregunta técnica relevante. Y ahí es donde empieza el trabajo de Threat Hunting.

2. Qué es formalmente Threat Hunting (NIST y MITRE) #

En el ámbito defensivo profesional, el Threat Hunting no es un truco improvisado ni un pasatiempo de fin de semana. Es una capacidad operativa formalizada por los principales organismos internacionales de ciberseguridad.

• NIST SP 800-53 Rev. 5: En su catálogo de controles de seguridad, el NIST define formalmente el control RA-10 (Threat Hunting). Establece que la organización debe implementar una capacidad activa de caza orientada a buscar indicadores de compromiso en los sistemas y a detectar, rastrear y dificultar a aquellos adversarios avanzados que consiguen eludir los controles de seguridad perimetrales y automáticos existentes.
• NIST Cybersecurity Framework 2.0 (CSF 2.0): Incluye el Threat Hunting dentro de la función IDENTIFY y la categoría de Evaluación de Riesgos (Risk Assessment - ID.RA), señalando que las organizaciones maduras emplean la caza activa de amenazas para evaluar de forma continua las exposiciones reales frente a actores internos y externos.
• MITRE: En sus investigaciones y programas sobre TTP-Based Hunting, MITRE describe el Threat Hunting como la detección e investigación proactiva de actividad maliciosa dentro de una red, fundamentada en el conocimiento estructurado de las tácticas, técnicas y procedimientos de los adversarios.

La palabra clave que articula todas estas definiciones oficiales es una sola:

PROACTIVA.

En el modelo clásico de operaciones, el analista espera pacientemente a que un sistema genere:

ALERT: MALWARE DETECTED ON HOST PC-FIN-021 (Severity: High)

En Threat Hunting no esperamos a que la máquina toque la alarma. Asumimos la posibilidad de que el adversario ya esté operando dentro (la premisa Assume Breach) y salimos a buscar evidencia empírica en los datos a partir de una hipótesis fundamentada.

3. Threat Hunting no significa buscar al azar #

Existe una confusión muy extendida entre quienes se aproximan por primera vez a esta disciplina: creer que hacer Threat Hunting consiste en entrar a la consola del SIEM, escribir una palabra clave genérica y examinar registros hasta que el ojo humano tropiece con algo extraño.

Escribir en la barra de búsqueda:

powershell

y sentarse a revisar una lista de 40.000 eventos con la esperanza de «ver qué salta» no constituye una metodología técnica de caza.

Ese enfoque errático puede, por pura casualidad, llevar a un descubrimiento puntual. Sin embargo, adolece de graves limitaciones operativas:

• No es reproducible: Otro analista de tu equipo no podrá repetir el mismo análisis dentro de un mes con garantías de coherencia.
• No es medible: Resulta imposible evaluar qué porcentaje de tu superficie o qué técnicas adversarias fueron realmente verificadas.
• No tiene criterio de finalización: ¿Cuándo se da por terminado el análisis? ¿Al cansarse de mirar líneas de texto?
• Genera fatiga cognitiva extrema: Obliga a inspeccionar volúmenes ingentes de ruido benigno sin un filtro conceptual previo.
• No se puede operacionalizar: Es muy difícil convertir una tarde de búsquedas erráticas en una mejora concreta de ingeniería de detección.

En cambio, una verdadera sesión de Threat Hunting comienza con un razonamiento articulado:

«Si un adversario utiliza PowerShell desde aplicaciones de usuario para ejecutar código en memoria, deberíamos encontrar relaciones poco habituales entre procesos de la suite Office y la consola PowerShell en estaciones de trabajo donde ese patrón jamás se utiliza legítimamente.»

Ahora no estamos mirando al azar. Tenemos una hipótesis técnica. Y los datos de logs de seguridad pueden confirmarla, matizarla o debilitarla.

4. Detección automática vs Triage vs Threat Hunting #

Para comprender la posición del hunting dentro de las operaciones de seguridad, conviene comparar tres situaciones que conviven a diario en un Centro de Operaciones de Seguridad (SOC):

Analicemos un caso concreto:

1. Detección automática: Una regla de correlación vigila la creación de procesos y genera una alarma en el momento exacto en que detecta WINWORD.EXE iniciando powershell.exe.
2. Triage: El analista de guardia recibe esa alerta específica y formula preguntas inmediatas: ¿Qué usuario estaba conectado? ¿En qué equipo? ¿Qué documento se abrió antes? ¿Qué comandos se ejecutaron después? ¿Cuál es el alcance?
3. Threat Hunting: No existe necesariamente ninguna alerta en la consola. El analista defensivo se pregunta: «¿Qué aplicaciones ofimáticas o visores de documentos están iniciando shells o utilidades administrativas en la empresa, y cuáles de esas relaciones no están justificadas por el software corporativo?» A partir de esa pregunta, examina la telemetría histórica.

Como documenta Microsoft en sus manuales de seguridad defensiva, la frontera no siempre es absolutamente rígida. Existen tres modalidades reconocidas de caza:

• Hunting proactivo: Guiado por hipótesis independientes de incidentes en curso.
• Hunting reactivo: Ejecutado durante la investigación de un incidente para determinar si el atacante se expandió hacia otros activos.
• Hunting post-incidente: Realizado tras erradicar una amenaza para verificar la ausencia de persistencias residuales y perfeccionar las coberturas.

Por eso, la distinción fundamental no reside en decir «en hunting nunca hay una alerta previa», sino en entender su motor esencial:

Principio fundamental: El Threat Hunting está dirigido por preguntas e hipótesis humanas, no únicamente por la cola de alertas automatizadas.

5. Threat Hunting no sustituye a las detecciones (el ciclo continuo) #

Un error estratégico frecuente en algunas organizaciones consiste en asumir una falsa dicotomía:

«Como tenemos analistas de Threat Hunting altamente especializados, podemos descuidar la creación y optimización de nuestras reglas de detección automática.»

Este razonamiento es peligroso y económicamente insostenible. Un analista humano no puede supervisar manualmente millones de eventos por segundo que fluyen por un SIEM empresarial las 24 horas del día. La detección automática y la caza proactiva no compiten: se alimentan mutuamente en un circuito cerrado y virtuoso.

Cuando un hunt descubre un comportamiento sospechoso repetible (por ejemplo, una cadena de procesos anómala), el objetivo no es volver a buscar ese mismo patrón manualmente a mano cada lunes por la mañana. El objetivo es transferir ese conocimiento validado al equipo de Detection Engineering para codificarlo en una regla permanente (en formato Sigma, KQL o SPL). De este modo, el hunter queda liberado para investigar la siguiente hipótesis desconocida.

6. Metodología práctica de 8 etapas para Threat Hunting #

Para estructurar la caza de forma disciplinada y repetible, trabajaremos con un marco operativo compuesto por ocho etapas secuenciales:

Este flujo se alinea estrechamente con la formación oficial sobre TTP-Based Threat Hunting Training diseñada por el equipo de MITRE, la cual estructura el proceso analítico alrededor de:

1. Definición de hipótesis comprobables fundamentadas en tácticas adversarias.
2. Identificación de requisitos de datos y telemetría de soporte.
3. Detección y mitigación de brechas de recolección (collection gaps).
4. Desarrollo de analíticas y consultas progresivas.
5. Ejecución de la investigación y derivación a respuesta o ingeniería.

Examinemos con detalle cada uno de estos pasos y cómo aplicarlos en escenarios defensivos reales.

7. Paso 1: Empieza por contexto, no por una query #

El error más habitual del analista novato es abrir la consola de búsqueda de su herramienta e intentar escribir código de consulta de forma inmediata. Antes de teclear una sola instrucción, necesitas un motivo fundamentado para buscar:

Principio fundamental: Threat Hunting no empieza con una query. Empieza con una pregunta.

Las preguntas e hipótesis de caza defensiva no surgen de la nada. Provienen de fuentes concretas de conocimiento del entorno y de la amenaza:

• Inteligencia de Amenazas (Cyber Threat Intelligence - CTI): Informes de actores de amenaza relevantes para tu sector industrial que detallan el uso de herramientas específicas o técnicas evasivas.
• Matriz MITRE ATT&CK: Técnicas y subtécnicas adversarias identificadas en las fases de Ejecución, Persistencia, Evasión de Defensas o Descubrimiento.
• Incidentes de seguridad anteriores: Lecciones aprendidas en tu propia organización tras gestionar una intrusión reciente mediante tus playbooks de respuesta a incidentes.
• Alertas de severidad baja o media cerradas sin impacto: Señales aisladas que no justificaron un incidente individual, pero cuya agregación estadística sugiere un patrón más profundo.
• Resultados de auditorías y ejercicios Red Team / Pentesting: Vías de acceso y movimientos laterales ejecutados con éxito por evaluadores éticos durante pruebas autorizadas.
• Publicación de nuevas vulnerabilidades (CVEs) y exploits de prueba de concepto: Especialmente aquellas que abusan de servicios expuestos a Internet o utilidades de administración remota.
• Cambios recientes en la infraestructura tecnológica: Migraciones masivas a la nube, despliegue de nuevas herramientas de soporte o reconfiguraciones de redes corporativas.

Supongamos que tu equipo analiza un informe de inteligencia reciente: adversarios con motivación financiera están empleando herramientas nativas de administración del sistema operativo para enumerar cuentas y grupos de usuarios poco después de comprometer un equipo mediante phishing. En lugar de limitarte a archivar el PDF, formulas una pregunta operativa inicial:

«¿Tenemos estaciones de trabajo donde un proceso no administrativo esté realizando actividades sistemáticas de descubrimiento de cuentas, grupos de Active Directory o configuración de red?»

Todavía no hemos abierto ninguna consola. Todavía no hemos escrito una sola línea de código. Y eso es exactamente lo correcto: tenemos una dirección clara que orientará todo el trabajo analítico posterior.

8. Paso 2: Formula una hipótesis comprobable y refutable #

Una pregunta estratégica debe traducirse en una hipótesis operativa. Pero no cualquier enunciado sirve como hipótesis científica en ciberseguridad.

La diferencia entre una mala hipótesis y una hipótesis técnica válida

Examinemos dos ejemplos de hipótesis deficientes muy comunes:

• Mala hipótesis 1: «Puede haber hackers operando dentro de los servidores de la empresa.» No es operativa. Es una afirmación tan vaga que no sugiere qué datos interrogar ni qué patrones buscar.
• Mala hipótesis 2: «Vamos a buscar cosas raras en la actividad de PowerShell.» ¿Qué define exactamente qué es «raro»? Sin un marco de normalidad previo, la subjetividad del analista dominará la investigación.

Comparemos esos enunciados con una hipótesis estructurada y comprobable:

«Si un adversario está llevando a cabo descubrimiento de entorno mediante herramientas nativas de Windows, deberíamos observar secuencias inusuales de comandos de reconocimiento ejecutadas por procesos no administrativos o por cuentas de usuario estándar que habitualmente no realizan tareas de soporte técnico.»

Esta hipótesis posee propiedades fundamentales: define el actor hipotético, el mecanismo utilizado, el comportamiento esperado y el criterio de anomalía dentro del entorno.

El requisito imprescindible de falsabilidad

En el método científico, una hipótesis solo es válida si existe la posibilidad matemática y empírica de ser refutada. Si cualquier resultado posible sirve para confirmar tu teoría, no tienes una hipótesis técnica; tienes un sesgo de confirmación.

Consideremos este planteamiento erróneo:

«Cualquier ejecución de PowerShell en los endpoints de los usuarios puede ser potencialmente maliciosa.»

Si la telemetría muestra ejecuciones de PowerShell, el analista concluye: «¡Confirmado, hay actividad sospechosa!» Si la telemetría no muestra ejecuciones, concluye: «¡El atacante está evadiendo la consola y ocultando sus huellas!» De este modo, la teoría jamás puede descartarse.

Una hipótesis verdaderamente útil debe permitir la obtención de datos que reduzcan la sospecha y demuestren que el comportamiento observado es enteramente benigno. Por ejemplo:

«Las ejecuciones de PowerShell iniciadas por procesos de Microsoft Office son extremadamente infrecuentes en estaciones de trabajo y podrían señalar una ejecución no autorizada de macros o exploits.»

A partir de aquí podemos medir parámetros cuantificables y contrastables con la realidad:

• ¿Ocurren estas ejecuciones en nuestro parque de equipos?
• ¿Con qué frecuencia exacta se registran en los últimos 30 días?
• ¿En qué estaciones de trabajo y con qué cuentas de usuario?
• ¿Qué líneas de comandos exactas se pasaron como argumentos?
• ¿Corresponden a automatizaciones corporativas documentadas por el equipo de TI?

Principio fundamental: Query no es hipótesis. La consulta es solo el código con el que interrogas la base de datos; la hipótesis es la afirmación comprobable que da sentido y propósito a tu análisis.

9. Paso 3: Traduce la hipótesis a comportamiento observable #

Nuestra hipótesis habla de «descubrimiento de usuarios y red». Sin embargo, cuando abres tu repositorio de telemetría, ninguna base de datos contiene un campo mágico etiquetado como:

attacker_is_doing_discovery = true

El analista defensivo debe actuar como un traductor entre los conceptos abstractos de las amenazas y los eventos granulares generados por los sistemas operativos. En el ecosistema Windows, el descubrimiento se materializa habitualmente en la invocación de utilidades de línea de comandos integradas en el propio sistema:

Advertencia crítica de análisis: Ninguno de estos ejecutables es malicioso por sí mismo. Todos son herramientas legítimas de administración desarrolladas por Microsoft e instaladas por defecto en cualquier instalación de Windows. Su carácter potencialmente sospechoso depende exclusivamente del contexto:

• ¿Quién las ejecuta? No es lo mismo un administrador de sistemas de guardia que un empleado del departamento de Facturación.
• ¿Qué proceso padre las creó? Es esperable que whoami.exe sea invocado desde una sesión interactiva de un administrador, pero resulta altamente sospechoso si su proceso padre es sqlservr.exe, w3wp.exe o excel.exe.
• ¿En qué secuencia temporal? Un administrador ejecuta un comando cuando necesita consultar un dato concreto. Un script automatizado de reconocimiento o un atacante interactivo suele disparar cinco utilidades distintas en menos de 90 segundos.

Por esta razón, MITRE promueve con tanta firmeza el Threat Hunting basado en TTPs (Tácticas, Técnicas y Procedimientos): porque el comportamiento adversario ofrece un nivel de abstracción defensiva mucho más sólido y duradero que la búsqueda efímera de hashes de archivo o direcciones IP.

10. Paso 4: Determina qué telemetría necesitas y brechas de recolección #

Antes de escribir una sola línea de KQL (Kusto Query Language), SPL (Splunk) o Lucene en tu consola, debes responder a una pregunta operativa ineludible:

«¿Dispongo en mi infraestructura de las fuentes de datos necesarias para observar este comportamiento si estuviera ocurriendo?»

Si la telemetría no existe o no se recopila de forma centralizada, el Threat Hunting no puede hacer magia ni inventar los hechos. Cada categoría de comportamiento exige campos de datos específicos:

Una brecha de datos también es un resultado de hunting

Imaginemos que tu hipótesis exige correlacionar el proceso padre (ParentImage) con la línea de comandos completa ejecutada (CommandLine) en estaciones de trabajo Windows. Al preparar la consulta en el SIEM, descubres con sorpresa que solo el 25 % de los equipos de la compañía tiene habilitada la directiva de auditoría «Include command line in process creation events» o el sensor de Sysmon.

¿Es esto una pérdida de tiempo? En absoluto.

No habrás encontrado a un atacante, pero acabas de descubrir una vulnerabilidad operativa de primer nivel:

Principio fundamental: Una brecha de datos también es un resultado. Revela que la organización sufre un punto ciego que impediría investigar un incidente real.

En el marco formativo de MITRE, la fase de Collection Gap Identification se considera un entregable defensivo tan valioso como la identificación de malware. Ese hallazgo genera de inmediato un ticket de mejora hacia el equipo de ingeniería de infraestructura para corregir la directiva de grupo (GPO) y ampliar la cobertura.

11. No confundas "no encontré nada" con "nada ocurrió" #

Supongamos que ejecutas una consulta en tu repositorio de logs buscando ejecuciones de PowerShell iniciadas por Microsoft Word a lo largo de los últimos 30 días:

RESULTADO DE LA BÚSQUEDA: 0 COINCIDENCIAS (0 eventos encontrados)

La tentación inmediata de un analista inexperto es afirmar con rotundidad ante su responsable: «Excelente noticia, hemos comprobado que en el último mes nadie ha atacado nuestra empresa a través de documentos de Word.»

Esa conclusión es metodológicamente incorrecta. Antes de asegurar que una actividad no ocurrió, debes someter tu resultado a un exhaustivo checklist de visibilidad técnica:

1. ¿Todos los equipos enviaban logs? ¿Estaban los agentes de monitorización encendidos y transmitiendo, o sufrieron desconexiones prolongadas?
2. ¿El campo de proceso padre estaba presente? Si el evento solo capturó el nombre del ejecutable pero ignoró la relación parental, tu filtro descartó los eventos reales.
3. ¿La retención cubre realmente los 30 días? ¿O tu política de cuotas en el SIEM provocó que los eventos más antiguos se sobreescribieran tras 14 días?
4. ¿La sintaxis de la consulta era precisa? ¿Diferenció entre mayúsculas y minúsculas? ¿Buscó powershell.exe pero omitió pwsh.exe o versiones renombradas?
5. ¿Los datos estaban correctamente normalizados? ¿El parser del SIEM extrajo el campo con el nombre esperado o lo indexó bajo una etiqueta genérica?
6. ¿Existen activos fuera del alcance? ¿Qué ocurre con los portátiles de usuarios remotos que no se conectaron a la VPN corporativa?

Principio fundamental: No encontré nada no significa que nada ocurrió.

Regla de oro: La ausencia de resultados en una búsqueda solo es significativa dentro del perímetro estricto de la visibilidad y retención que realmente tenemos.

12. Paso 5: Empieza con una consulta amplia e iterativa #

Otro fallo clásico al diseñar cacerías técnicas consiste en redactar desde el primer minuto una macro-consulta repleta de veinte condiciones lógicas simultáneas:

// ERROR DE ENFOQUE: Consulta excesivamente restringida desde el inicio
DeviceProcessEvents
| where InitiatingProcessFileName =~ "winword.exe"
| where FileName =~ "powershell.exe"
| where ProcessCommandLine contains "-enc"
| where DeviceName startswith "PC-VIP"
| where Timestamp between (datetime(2026-10-01) .. datetime(2026-10-02))

Si introduces tantos filtros restrictivos a ciegas, corres el riesgo de perder de vista la imagen global de tu infraestructura. El método profesional avanza en embudo: de lo amplio a lo específico.

Si deseas investigar shells originados por aplicaciones ofimáticas, comienza con una consulta conceptual amplia que interrogue la totalidad de los procesos hijos:

// PASO 1 DEL EMBUDO: ¿Qué procesos hijos generan las aplicaciones ofimáticas en general?
DeviceProcessEvents
| where InitiatingProcessFileName in~ ("WINWORD.EXE", "EXCEL.EXE", "POWERPNT.EXE", "OUTLOOK.EXE")
| summarize TotalEjecuciones = count() by FileName

Al inspeccionar la distribución de los resultados agregados, podrías observar una imagen reveladora:

splwow64.exe (controlador de impresión)      --------> 14.820 ejecuciones (esperado)
msedge.exe (navegador al abrir enlaces)       -------->  3.410 ejecuciones (esperado)
AcroRd32.exe (visor de PDF)                   -------->    850 ejecuciones (esperado)
powershell.exe (consola de comandos)          -------->     14 ejecuciones (¡ANÓMALO!)
cmd.exe (símbolo del sistema)                 -------->      2 ejecuciones (¡ANÓMALO!)

A partir de este primer vistazo cuantitativo, el proceso se vuelve iterativo y guiado por la evidencia:

Cada respuesta no cierra la investigación; te proporciona los datos concretos necesarios para formular una consulta más precisa y quirúrgica.

13. Paso 6: Busca rareza con contexto (raro ≠ malicioso) #

Una de las técnicas estadísticas más potentes utilizadas en Threat Hunting es el Análisis de Frecuencia Inversa (conocido en inglés como Stacking o Least Frequency of Occurrence - LFO).

Supongamos que buscas ejecuciones de PowerShell en toda la empresa y el SIEM devuelve 12.000 eventos en la última semana. Leerlos línea a línea es absurdo. En su lugar, aplicamos una agregación por proceso padre (ParentImage):

PROCESO PADRE                         RECUENTO
----------------------------------------------
ccmexec.exe (Microsoft SCCM)            8.420  (Gestión de parches habitual)
monitoring_agent.exe                    2.150  (Monitorización corporativa)
explorer.exe                            1.410  (Administradores abriendo consolas)
code.exe (Visual Studio Code)              16  (Equipo de desarrollo interno)
WINWORD.EXE                                12  (¿Macros de usuarios?)
AcroRd32.exe                                2  (¿Lector de PDF ejecutando scripts?)

La técnica de stacking coloca la anomalía en la parte inferior de la lista. Las dos ejecuciones generadas por el lector de PDF llaman inmediatamente la atención. Sin embargo, en este punto el analista debe recordar dos axiomas fundamentales de la seguridad defensiva:

Axioma 1: Raro no significa malicioso.

Axioma 2: Común no significa benigno.

Un software nuevo recién instalado en un único equipo aparecerá solo una vez en tu entorno y será 100 % legítimo. Un script anual de contabilidad fiscal se ejecutará solo un viernes por la tarde y no será malicioso. Por el contrario, un adversario avanzado puede utilizar comandos extremadamente comunes (como ping.exe o ipconfig.exe) miles de veces sin levantar sospechas numéricas.

La rareza estadística proporciona una pista investigativa prioritaria, nunca una sentencia condenatoria. Es el contexto técnico el que determina qué merece seguir investigándose:

Principio fundamental: El objetivo no es tener razón. El objetivo es explicar los datos.

14. Paso 7: Pivota entre entidades y hosts #

Cuando un hallazgo inicial pasa el filtro de la rareza, no nos quedamos observándolo de forma aislada. Ha llegado el momento de pivotar.

Imaginemos que localizamos el siguiente evento sospechoso:

Timestamp:        2026-10-07 14:22:15 UTC
Host:             PC-HR-014
User:             juan.perez
Process:          C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
ParentProcess:    C:\Program Files\Adobe\Acrobat DC\Acrobat\AcroRd32.exe
CommandLine:      powershell.exe -NoP -NonI -W Hidden -Enc SQBFAFgA...

A partir de este único registro, desplegamos múltiples líneas de investigación dimensional:

Fíjate en la potencia del pivote por comportamiento: los hashes de archivo cambian con un simple byte de modificación; las direcciones IP y nombres de dominio rotan en minutos gracias a infraestructuras Fast Flux o servicios en la nube; pero la necesidad arquitectónica de un exploit de abusar de un visor para invocar un intérprete de comandos sobrevive y permanece constante.

15. Tiempo, terreno y comportamiento: el modelo MITRE #

En su investigación sobre TTP-Based Threat Hunting, los especialistas de MITRE articulan el espacio de análisis de la caza defensiva alrededor de tres dimensiones vectoriales:

1. Dimensión Tiempo

Ningún evento de seguridad ocurre en el vacío. El análisis temporal responde a interrogantes cruciales:

• ¿A qué hora exacta ocurrió el evento inicial? ¿Se produjo en horario laboral o a las 03:00 de la madrugada?
• ¿Qué ocurrió exactamente 5 minutos antes? (Por ejemplo: la recepción de un correo en Outlook o la descarga de un adjunto).
• ¿Qué ocurrió inmediatamente después? (Establecimiento de persistencia en el Registro o balizado de red recurrente).
• ¿Es un evento único o se repite en intervalos periódicos regulares (posible señal de canal C2)?

2. Dimensión Terreno

El terreno define la topología de la organización donde tiene lugar la actividad:

• ¿En qué segmento de red se encuentra el equipo afectado? ¿Es la red de usuarios generales, la DMZ pública o la zona de servidores de bases de datos?
• ¿Qué tipo de activo es? ¿Un portátil de soporte técnico, un controlador de dominio o un servidor de cobros transaccionales?
• ¿Qué identidad de usuario está involucrada? ¿Un usuario común o una cuenta con privilegios de Administrador de Dominio?

3. Dimensión Comportamiento

El comportamiento examina la lógica intrínseca de la acción ejecutada:

• ¿Qué relaciones de procesos se construyeron?
• ¿Qué argumentos y banderas se pasaron a la línea de comandos?
• ¿Qué llamadas a librerías nativas (DLLs) o inyecciones en procesos de memoria tuvieron lugar?

Una dirección IP aislada o un hash solitario apenas proporcionan contexto. Pero una secuencia temporal de comportamientos sospechosos ejecutándose sobre un activo crítico de tu terreno empieza a contar una historia forense inequívoca.

16. Ejemplo completo 1: Hunting de comandos de descubrimiento #

Analicemos un caso práctico completo paso a paso, desde la concepción de la idea hasta la documentación de los resultados en un entorno empresarial.

1. Contexto y Motivación

Un informe de inteligencia defensiva describe que múltiples grupos de ransomware realizan una fase intensiva de reconocimiento interno en las primeras 48 horas tras ganar acceso inicial, ejecutando utilidades de línea de comandos integradas en Windows para inventariar usuarios y conectividad.

2. Hipótesis Operativa

«Si un adversario está llevando a cabo descubrimiento de red en nuestras estaciones de trabajo corporativas, observaremos la ejecución de múltiples utilidades nativas de reconocimiento en una ventana temporal reducida (menos de 5 minutos), invocadas por usuarios no técnicos o procesos no habituales.»

3. Telemetría Requerida

Eventos de creación de procesos con registro de línea de comandos y proceso padre (Sysmon Event ID 1 o Windows Event ID 4688 centralizados en el SIEM).

4. Búsqueda Inicial y Refinamiento

Comenzamos buscando cualquier ejecución de las herramientas típicas de reconocimiento en los últimos 14 días:

// Consulta conceptual en el SIEM
ProcessName IN ("whoami.exe", "net.exe", "net1.exe", "nltest.exe", "systeminfo.exe", "ipconfig.exe", "quser.exe")

El resultado arroja 48.312 eventos. Es un volumen inasumible para inspección manual. El motivo es que los scripts de arranque y las herramientas de gestión de TI ejecutan ipconfig.exe constantemente.

Aplicamos el segundo nivel de refinamiento: agrupamos por Host + Usuario y buscamos equipos donde se hayan ejecutado al menos 3 herramientas distintas en un intervalo inferior a 5 minutos:

// Agregación por ventana temporal
| summarize HerramientasDistintas = dcount(ProcessName), ListaComandos = make_set(ProcessName)
  by Host, User, bin(Timestamp, 5m)
| where HerramientasDistintas >= 3

La lista se reduce drásticamente de 48.000 eventos a una única secuencia sospechosa:

Host:             PC-FIN-021
Usuario:          ana.lopez
Ventana temporal: 2026-10-05 09:31:00 a 09:33:15 UTC

Secuencia registrada:
09:31:05  whoami.exe
09:31:22  ipconfig.exe /all
09:32:01  nltest.exe /dclist:corporativo.local
09:32:40  net.exe group "Domain Admins" /domain
09:33:10  systeminfo.exe

5. Fase de Pivote e Investigación

La secuencia coincide exactamente con el comportamiento esperado de un adversario. Sin embargo, no saltamos a conclusiones precipitadas. Pivotamos hacia el proceso padre:

• Todos los comandos fueron invocados por cmd.exe.
• ¿Quién creó ese cmd.exe? Revisamos el ParentProcessId: fue creado por remote_management_agent.exe.
• Investigamos el binario del agente: pertenece a la solución corporativa de inventario desplegada por el departamento de sistemas.
• Contactamos con el responsable de infraestructura: confirma que todos los lunes a las 09:30 se lanza un trabajo programado de actualización de datos de hardware en la subred financiera.

6. Conclusión y Valor Defensivo

El resultado respecto a la presencia de un atacante es negativo. No había ninguna amenaza maliciosa en PC-FIN-021. Sin embargo, la sesión generó un valor defensivo tangible:

• Se verificó que la visibilidad de creación de procesos en la subred de Finanzas funciona con total fidelidad.
• Se documentó la línea base legítima de la herramienta de inventario corporativa.
• Se añadió una excepción controlada (filtrando por la firma digital del agente de soporte) para que futuras cacerías de reconocimiento descarten este ruido automáticamente.

17. Ejemplo completo 2: Office iniciando shells y ofuscación #

Examinemos ahora un segundo escenario de caza donde la hipótesis conduce a un hallazgo de alta severidad.

1. Hipótesis Operativa

«Las aplicaciones ofimáticas (Word, Excel, PowerPoint) no deberían iniciar habitualmente intérpretes de comandos en estaciones de trabajo de usuarios estándar, y cualquier invocación con argumentos ofuscados constituye una anomalía de alta prioridad.»

2. Búsqueda y Análisis de Agrupación

Lanzamos una consulta que filtra todas las ejecuciones de procesos hijos donde el padre es una aplicación de Office y el hijo es un intérprete de comandos (powershell.exe, cmd.exe, wscript.exe, cscript.exe, mshta.exe):

RESULTADOS OBTENIDOS EN LOS ÚLTIMOS 30 DÍAS:
Total eventos: 15
  - 10 ejecuciones: EXCEL.EXE -> powershell.exe
  -  3 ejecuciones: WINWORD.EXE -> cmd.exe
  -  2 ejecuciones: WINWORD.EXE -> powershell.exe

3. Discriminación por Contexto (Grupo A vs Grupo B)

Al analizar los 15 eventos en detalle, descubrimos dos grupos radicalmente distintos:

• Grupo A (13 eventos): Proceden de dos equipos del departamento de Logística. La línea de comandos de PowerShell ejecuta un script localizado en una carpeta compartida de red interna (\\fileserver\macros\export_sap.ps1). Es una macro interna documentada hace tres años. Se cataloga como actividad legítima conocida.
• Grupo B (2 eventos): Ocurren en el equipo PC-DIR-003 correspondiente a la Dirección General. La relación observada es alarmante:

  ParentProcess: C:\Program Files\Microsoft Office\root\Office16\WINWORD.EXE
  Process:       C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
  CommandLine:   powershell.exe -NoProfile -WindowStyle Hidden -ExecutionPolicy Bypass -Enc JABjAGwAaQBlAG4AdAA...

4. Pivote Temporal Forense

Nos centramos exclusivamente en el incidente de PC-DIR-003 y aplicamos un pivote temporal sobre los 10 minutos anteriores y posteriores:

5. Escalado y Transferencia

En este instante exacto, el Threat Hunting ha cumplido su objetivo. No nos quedamos investigando de forma aislada. La hipótesis ha quedado demostrada y la evidencia señala una intrusión activa en un activo crítico de la compañía.

El analista activa de inmediato el protocolo de escalado hacia el equipo de Respuesta a Incidentes para ejecutar las acciones de contención contempladas en los playbooks de respuesta (aislamiento del endpoint, revocación de tokens y preservación forense de memoria).

18. Paso 8: Criterios de salida y documentación de conclusiones negativas #

Una sesión de Threat Hunting no debe convertirse en un agujero negro de tiempo donde un analista se pierde durante semanas en los datos simplemente porque «todavía quedan muchas queries posibles que probar».

Principio fundamental: El objetivo del hunter no es investigar eternamente. Es responder a una pregunta concreta y transferir el conocimiento adquirido.

Un hunt bien diseñado debe finalizar obligatoriamente bajo alguno de estos cinco criterios de salida formales:

1. Hipótesis Respaldada (Amenaza Encontrada): Se localiza evidencia de actividad maliciosa. Se genera el caso formal, se preservan las evidencias técnicas y se escala al equipo de respuesta a incidentes.
2. Hipótesis No Respaldada (Sin Evidencia): Tras agotar las consultas dentro de la ventana y alcance previstos, los datos no muestran indicios de la técnica adversaria. El hunt se cierra formalmente.
3. Información Insuficiente (Brecha de Datos): La hipótesis no puede comprobarse debido a falta de retención, ausencia de fuentes o sensores inactivos. Se abre un requerimiento de ingeniería de telemetría.
4. Comportamiento Legítimo Identificado: Las anomalías encontradas se explican enteramente por aplicaciones o scripts autorizados de la empresa. Se documenta la línea base y se afinan futuras búsquedas.
5. Hunt Derivado: Durante la exploración surgen indicios de un fenómeno distinto e imprevisto. En lugar de desviar el objetivo actual, se documenta la nueva pregunta para abordarla en un hunt independiente.

Cómo documentar una conclusión negativa con rigor técnico

Cuando un hunt termina sin encontrar amenazas, la documentación jamás debe reducirse a una frase vacía como «No encontramos nada». Una conclusión negativa profesional debe definir con precisión quirúrgica qué se buscó, dónde se buscó y qué limitaciones existieron:

Ahora cualquier auditor, responsable de seguridad o compañero del SOC sabe exactamente qué grado de certeza tiene la organización respecto a esa amenaza.

19. Plantilla estándar para documentar un Threat Hunt #

Para asegurar la repetibilidad y el valor histórico de cada investigación, todo programa de caza debe emplear una plantilla estandarizada compuesta por once campos esenciales:

20. Threat Hunting basado en MITRE ATT&CK #

La matriz MITRE ATT&CK es el catálogo de referencia mundial sobre comportamiento adversario. Sin embargo, utilizar ATT&CK en Threat Hunting requiere una comprensión madura de su naturaleza:

Error frecuente: ATT&CK no es un motor de base de datos ni una colección de firmas antivirus. No puedes abrir tu SIEM y buscar simplemente el término T1087 esperando que aparezca una lista mágica de ataques.

Los sistemas operativos registran operaciones de bajo nivel (aperturas de sockets, lecturas de memoria, creación de subprocesos), no identificadores de la matriz. La metodología profesional utiliza ATT&CK como una fuente estructurada para conceptualizar hipótesis:

1. Selecciona una técnica adversaria relevante: Por ejemplo, T1087 (Account Discovery) o T1059.001 (PowerShell).
2. Estudia la descripción y los procedimientos reales: Lee cómo los grupos de ciberdelincuencia implementan esa técnica en la práctica (comandos exactos, banderas, scripts auxiliares).
3. Pregunta cómo se manifiesta en tu infraestructura: En un dominio de Windows, la enumeración de cuentas locales o de dominio deja huellas en la creación de procesos y en el tráfico Kerberos o LDAP hacia los controladores de dominio.
4. Verifica qué fuentes de telemetría capturan esas huellas: Creación de procesos en endpoints, eventos de seguridad 4688, consultas LDAP en los Domain Controllers.
5. Diseña la analítica abstracta: Busca patrones de comportamiento independientes de nombres de archivo específicos (por ejemplo, procesos no administrativos realizando ráfagas de consultas a grupos privilegiados de Active Directory).

21. IoC Hunting frente a TTP Hunting y los 4 enfoques de caza #

En la práctica operativa conviven dos grandes modalidades de búsqueda:

Ambos enfoques son complementarios. Cuando recibes inteligencia urgente sobre una campaña activa, buscar sus IoCs conocidos en tus registros de los últimos 60 días es una medida rápida y necesaria. Pero el verdadero salto de calidad defensiva reside en buscar la técnica que hay detrás.

Los cuatro enfoques metodológicos de Threat Hunting

Dependiendo de cuál sea el catalizador inicial de la investigación, distinguimos cuatro enfoques operativos:

• 1. Hypothesis-Driven (Guiado por Hipótesis): El enfoque más puro. El analista formula una teoría defensiva fundamentada en el comportamiento esperado de una amenaza y diseña pruebas para contrastarla con los datos.
• 2. Baseline-Driven (Guiado por Línea Base): Parte del conocimiento riguroso de la normalidad corporativa. Se calcula qué procesos o conexiones son habituales en el parque y se inspeccionan las anomalías que aparecen en la cola de menor frecuencia estadística.
• 3. Intelligence-Driven (Guiado por Inteligencia): Se alimenta directamente de informes estratégicos y técnicos de CTI sobre amenazas dirigidas contra el sector de la organización.
• 4. Incident-Driven (Guiado por Incidentes): Se activa tras la resolución de un incidente confirmado en un activo para verificar retrospectivamente si el mismo patrón o técnica se manifestó en otros sistemas que pasaron desapercibidos.

22. Cómo diseñar consultas progresivas por capas analíticas #

Para no perderse en la inmensidad de los registros, una buena estrategia técnica consiste en construir las consultas analíticas avanzando a través de seis capas lógicas consecutivas:

1. Capa 1 — Volumen: ¿Cuántos eventos existen en total para esta categoría en el periodo evaluado? (Visión macroscópica).
2. Capa 2 — Distribución: ¿En qué activos, sistemas operativos y departamentos se distribuyen esos eventos?
3. Capa 3 — Rareza (Stacking): ¿Qué combinaciones de campos ocurren con menor frecuencia estadística dentro de la muestra?
4. Capa 4 — Relaciones Estructurales: ¿Qué procesos padre crearon a los procesos hijos? ¿Qué puertos de red y protocolos se invocaron?
5. Capa 5 — Temporalidad: ¿Qué eventos ocurrieron en los 5 minutos inmediatamente anteriores y posteriores a la anomalía?
6. Capa 6 — Alcance Global: Si se confirma un elemento sospechoso, ¿dónde más aparece ese indicador o comportamiento en toda la red corporativa?

23. Herramientas: Defender, Elastic y el rol de la Inteligencia Artificial #

Threat Hunting es una metodología independiente de proveedores comerciales. Sin embargo, es útil conocer cómo las principales plataformas del mercado implementan estas capacidades:

• Microsoft Defender XDR (Advanced Hunting): Permite interrogar hasta 30 días de telemetría de endpoints, identidades, correo y aplicaciones cloud utilizando KQL (Kusto Query Language). Cuenta con tablas especializadas como DeviceProcessEvents, DeviceNetworkEvents y IdentityLogonEvents.
• Elastic Security: Ofrece capacidades masivas de búsqueda e investigación sobre grandes volúmenes históricos mediante lenguajes como ES|QL y EQL (Event Query Language), permitiendo correlacionar secuencias temporales de eventos de endpoints y red con extraordinaria velocidad.
• Splunk Enterprise Security: Emplea SPL (Search Processing Language) para agregar, normalizar y aplicar modelos estadísticos sobre terabytes de registros heterogéneos.

El papel real de los asistentes de Inteligencia Artificial en Threat Hunting

En la actualidad, las consolas de seguridad integran asistentes de inteligencia artificial generativa capaces de traducir solicitudes en lenguaje natural a consultas en KQL o SPL. Esto reduce indudablemente la fricción sintáctica para los analistas.

Sin embargo, es crucial entender los límites insalvables de esta tecnología:

Principio fundamental: La IA puede escribir una query. El hunter todavía tiene que saber qué pregunta intenta responder.

Un modelo de lenguaje no conoce la arquitectura interna de tu red corporativa, no sabe qué aplicaciones internas son legítimas en tu empresa, no puede evaluar si una muestra de telemetría sufre puntos ciegos ni puede discernir el impacto sobre el negocio de una acción de respuesta. La inteligencia artificial es una herramienta de asistencia; el razonamiento crítico sigue perteneciendo exclusivamente al analista humano.

24. De hallazgos a Detection Engineering y reglas defensivas #

El ciclo de vida del Threat Hunting se cierra con la operacionalización. Cuando un hunt concluye identificando un comportamiento altamente sospechoso o una técnica que carecía de cobertura automática, no debemos conformarnos con cerrar el informe:

En este punto colaboramos estrechamente con los ingenieros de detección para traducir la lógica del hunt en una regla formal (por ejemplo, mediante reglas Sigma en YAML). De este modo, la próxima vez que un adversario intente ejecutar esa misma técnica en cualquier rincón de la red, el sistema generará una alerta inmediata en tiempo real sin requerir una nueva cacería manual.

25. Laboratorios prácticos paso a paso #

No necesitas disponer de malware real ni exponer tu red a riesgos para aprender a cazar amenazas. Puedes entrenar tu capacidad analítica generando comportamiento benigno controlado en un laboratorio local.

26. Métricas efectivas y los 12 errores más frecuentes #

¿Cómo se mide el éxito de una capacidad de Threat Hunting en una organización? Un error garrafal cometido por algunos directivos es evaluar al equipo exclusivamente por:

KPI ERRÓNEO: Número de atacantes o incidentes críticos descubiertos al mes

Esa métrica genera incentivos perversos. Si tu red está extraordinariamente protegida y no hay intrusiones activas durante un trimestre, ¿significa que los analistas de hunting fracasaron? En absoluto. Medir la caza solo por «amenazas encontradas» empuja a los analistas a magnificar falsos positivos para justificar su trabajo.

Las organizaciones maduras miden el programa a través de métricas de madurez y valor defensivo global:

• Hunts planificados y completados con rigor documental: Número de hipótesis evaluadas formalmente a lo largo del año.
• Cobertura de técnicas evaluada: Porcentaje de técnicas de MITRE ATT&CK verificadas sobre los activos críticos.
• Brechas de colección descubiertas y remediadas: Puntos ciegos de telemetría identificados y subsanados con los equipos de infraestructura.
• Nuevas detecciones automatizadas generadas: Número de reglas que pasaron de consultas manuales de hunting a detección automática 24/7.
• Reglas existentes afinadas y mejoradas: Reducción de falsos positivos en las alertas del SOC gracias al conocimiento de líneas base obtenido en las cacerías.
• Líneas base documentadas: Catálogo de comportamientos corporativos legítimos identificados y aprobados formalmente.

Los 12 errores más frecuentes en Threat Hunting

Evita caer en las trampas operativas más comunes observadas en la industria:

27. Madurez del SOC, NIST RA-10 y transición a Playbooks #

¿Cuándo está preparada una organización para implementar un programa formal de Threat Hunting? No se necesita una infraestructura tecnológica perfecta, pero sí una base mínima de madurez operativa.

El documento de MITRE «11 Strategies of a World-Class Cybersecurity Operations Center» advierte con lucidez que el Threat Hunting aporta su máximo retorno de inversión cuando el SOC ya dispone de capacidades consolidadas para:

• Manejar el triage y resolución de alertas rutinarias con fluidez en los niveles SOC Nivel 1, Nivel 2 y Nivel 3.
• Contar con telemetría centralizada de endpoints y red con una retención mínima razonable (al menos 30 a 90 días).
• Disponer de un proceso formal de respuesta a incidentes capaz de tomar el control cuando un hunter confirma una intrusión.

No tiene sentido estratégico contratar especialistas en Threat Hunting si la compañía todavía desconoce qué porcentaje de sus servidores corporativos está enviando registros al SIEM.

La conexión necesaria: de Threat Hunting a Playbooks de Respuesta

A lo largo de este análisis hemos trabajado con una pregunta fundamental:

«¿Está ocurriendo esta actividad no detectada en nuestros sistemas?»

Cuando la respuesta es afirmativa y el hunter confirma la presencia de un adversario, surge inmediatamente el dilema operativo más delicado de las operaciones de defensa:

«Ahora que sabemos que el atacante está dentro, ¿qué hacemos exactamente? ¿Quién tiene autoridad para desconectar el servidor? ¿Cómo preservamos la evidencia sin alterarla? ¿A quién debemos llamar?»

Si esas decisiones críticas tienen que improvisarse en mitad de la noche, el equipo cometerá errores graves que facilitarán la propagación de la amenaza. Para evitarlo, las operaciones maduras conectan el Threat Hunting con procedimientos preestablecidos y ensayados:

Ahí es donde entran en juego los playbooks de respuesta a incidentes, encargados de transformar el descubrimiento de una amenaza en una secuencia coordinada de contención, erradicación y recuperación del negocio.

28. Preguntas frecuentes sobre Threat Hunting #

29. Conclusión: de la pregunta a los datos #

El Threat Hunting no comienza abriendo una consola y escribiendo a toda prisa:

DeviceProcessEvents | where FileName == "powershell.exe"

ni tecleando en el buscador:

index=windows sourcetype=XmlWinEventLog

Comienza en la mente del analista formulando una pregunta rigurosa:

«¿Qué quiero descubrir?»

A partir de esa duda profesional, el razonamiento avanza de forma metódica y estructurada:

Y solo cuando esa base analítica está consolidada, se activa el proceso iterativo sobre los datos:

En ocasiones descubrirás a un adversario operando en silencio. En otras ocasiones documentarás una automatización corporativa legítima que nunca nadie había registrado. Y en otras ocasiones descubrirás que un segmento crítico de servidores no estaba enviando logs de procesos.

Las tres respuestas son extraordinariamente valiosas si están respaldadas por hechos empíricos.

Threat Hunting no consiste en encontrar algo extraño por casualidad.

Consiste en formular una pregunta defensiva fundada y perseguirla a través de la telemetría hasta poder explicar con certeza técnica qué dicen —y qué no dicen— los datos de tu organización.

Para seguir profundizando en la operativa defensiva integral del Blue Team, continúa con los recursos complementarios del cluster:

• En nuestra guía sobre SOC Nivel 1, Nivel 2 y Nivel 3: funciones y diferencias desglosamos cómo se integran las responsabilidades de triage, ingeniería y hunting en las operaciones diarias.
• En nuestro análisis de playbooks de respuesta a incidentes explicamos cómo formalizar los procedimientos de contención y erradicación cuando un hunt confirma una amenaza.
• En nuestra guía de MITRE ATT&CK para analistas SOC exploramos cómo aprovechar la matriz de comportamiento como fuente inagotable de hipótesis defensivas.
• En nuestro manual de SIEM: arquitectura y uso en el SOC analizamos la ingestión, normalización y consultas correlacionadas sobre repositorios de eventos.