Caza de amenazas para principiantes: encontrar lo que las alertas no detectan

TL;DR

La caza de amenazas es la práctica proactiva de buscar en redes y conjuntos de datos adversarios que las herramientas de detección automatizada no detectan. Investigaciones del SANS Institute muestran que las organizaciones con programas dedicados de caza de amenazas detectan brechas 2,5 veces más rápido que aquellas que dependen únicamente de alertas. Esta guía cubre la metodología basada en hipótesis, el framework MITRE ATT&CK como mapa de caza, fuentes de datos esenciales como telemetría EDR y logs DNS, y herramientas prácticas incluyendo Elastic, Splunk y Velociraptor.

El dashboard del SIEM mostraba verde en todos los paneles. Sin alertas críticas. Sin eventos de alta gravedad. Nada que demandara atención. Dentro de esa misma red, un grupo de amenazas persistentes avanzadas había mantenido acceso durante seis meses. Habían comprometido un controlador de dominio, exfiltrado 14 gigabytes de propiedad intelectual y establecido tres mecanismos de persistencia separados en endpoints de dos continentes. Cada acción que realizaron cayó por debajo de los umbrales de detección que el equipo de seguridad había configurado. Cada herramienta funcionó exactamente como fue diseñada. Y cada herramienta los pasó por alto.

Fue un cazador de amenazas quien los encontró. No a través de una alerta. No a través de una coincidencia de firma. A través de una hipótesis: "Si un adversario hubiera comprometido nuestro entorno, ¿dónde establecería persistencia y cómo se vería eso en nuestra telemetría?" Esa única pregunta, formulada por una analista que se negó a confiar en el silencio como evidencia de seguridad, desató seis meses de espionaje no detectado.

Esta es la promesa central de la caza de amenazas. Dejas de esperar a que las herramientas te digan que algo está mal. Vas a buscarlo.

Reactivo vs. proactivo: por qué las alertas no son suficientes

Los centros de operaciones de seguridad tradicionales funcionan con un modelo reactivo. Las herramientas de detección generan alertas. Los analistas las clasifican. El ciclo se repite. Este modelo funciona para amenazas conocidas, los ataques que coinciden con firmas y reglas existentes. Falla contra adversarios que estudian tus capacidades de detección y operan deliberadamente por debajo de ellas.

Según el Informe Global de Amenazas 2025 de CrowdStrike, el 75% de las intrusiones involucraron actividad manual en el teclado que generó alertas automatizadas mínimas. Los atacantes usaron credenciales legítimas, herramientas nativas del sistema operativo y utilidades administrativas de confianza. Sin malware que active el antivirus. Sin exploit que coincida con una firma. Solo un humano sentado ante un teclado, usando las mismas herramientas que tus administradores usan todos los días.

La caza proactiva de amenazas invierte el modelo. En lugar de esperar a que la máquina diga "algo está mal", un analista humano dice "déjame verificar que nada esté mal". La distinción suena sutil. En la práctica, es la diferencia entre descubrir una brecha en 8 días versus 21. El informe M-Trends 2025 de Mandiant documentó esta brecha exacta: las organizaciones con programas de caza estructurados redujeron el tiempo medio de permanencia de 21 días a 8.

El modelo reactivo responde la pregunta: "¿Qué detectaron nuestras herramientas?" El modelo proactivo responde: "¿Qué podrían haber pasado por alto nuestras herramientas?" Ambas preguntas importan. Solo una de ellas atrapa al adversario que leyó tu documentación de detección antes de lanzar su campaña.

Caza basada en hipótesis: empezar con una pregunta

Toda caza de amenazas efectiva comienza con una hipótesis. No una sospecha vaga, sino una declaración específica y comprobable sobre el comportamiento del adversario. Una hipótesis le da dirección a la caza, define qué datos examinar y establece criterios claros de éxito o fracaso.

Una hipótesis débil: "Algo podría estar mal en nuestra red."

Una hipótesis fuerte: "Un adversario podría estar usando tareas programadas en endpoints Windows para mantener persistencia, creando tareas que ejecutan comandos PowerShell codificados durante horas no laborales."

La diferencia es la comprobabilidad. La hipótesis fuerte te dice exactamente qué fuente de datos consultar (logs del Programador de tareas de Windows, event ID 4698), qué patrón buscar (comandos codificados en Base64 en acciones de tareas) y cuándo buscar (tiempos de ejecución entre las 23:00 y las 05:00). Puedes probarla o desmentirla dentro de una ventana de investigación definida.

El framework Sqrrl (ahora archivado, su metodología sigue siendo fundamental) identifica tres fuentes para la generación de hipótesis:

Las hipótesis basadas en inteligencia provienen de informes de inteligencia de amenazas. Cuando se documenta una nueva campaña APT, preguntas: "¿Podría este grupo habernos atacado usando estas técnicas?" Luego cazas los indicadores y comportamientos específicos descritos en el informe.

Las hipótesis situacionales provienen de tu propio entorno. Una nueva migración a la nube, una adquisición reciente o un pico inusual en tráfico DNS saliente pueden generar preguntas de caza. Estas cazas son únicas de tu organización y no pueden externalizarse a reglas de detección genéricas.

Las hipótesis basadas en analítica provienen de anomalías estadísticas en tus datos. Un endpoint que de repente empieza a hacer consultas DNS a dominios con nombres de alta entropía. Una cuenta de servicio que se autenticó desde una estación de trabajo por primera vez en seis meses. Un proceso que lee archivos de 400 directorios en menos de un minuto. Estas anomalías no activan alertas, pero justifican investigación.

MITRE ATT&CK como tu marco de caza

El framework MITRE ATT&CK es la estructura más adoptada para organizar actividades de caza de amenazas. Cataloga más de 200 técnicas de adversarios en 14 tácticas, desde el acceso inicial hasta la exfiltración. Para los cazadores de amenazas, ATT&CK sirve tanto como mapa como checklist.

Cada técnica ATT&CK describe cómo los adversarios logran un objetivo específico. La técnica T1053 (Scheduled Task/Job) describe cómo los atacantes usan los programadores de tareas del sistema operativo para ejecutar código malicioso en momentos predeterminados. La técnica T1071 (Application Layer Protocol) describe cómo los atacantes canalizan tráfico de comando y control a través de HTTP, HTTPS o DNS para mezclarse con la actividad normal de la red. Cada entrada incluye ejemplos del mundo real, guía de detección y referencias a grupos de amenazas específicos que han usado la técnica.

Así es como ATT&CK se traduce en un flujo de trabajo de caza estructurado:

1. Selecciona una táctica. Empieza con una de las 14 tácticas ATT&CK. Persistencia y evasión de defensa son puntos de partida sólidos porque los atacantes deben usarlas en casi toda intrusión.

2. Elige técnicas específicas. Bajo la táctica de Persistencia, ATT&CK lista técnicas como Boot or Logon Autostart Execution, Create or Modify System Process y Scheduled Task/Job. Selecciona una basada en tu hipótesis basada en inteligencia o situacional.

3. Mapea a fuentes de datos. ATT&CK te dice exactamente qué fuentes de datos revelan cada técnica. Para Scheduled Task/Job, necesitas Windows Event Log (Event IDs 4698, 4702), logs de creación de procesos (Sysmon Event ID 1) y eventos de creación de archivos en directorios de tareas.

4. Escribe consultas de detección. Traduce la descripción de la técnica en consultas específicas contra tus datos de log. Busca tareas programadas creadas por cuentas de usuario no estándar, tareas con argumentos de comando codificados o tareas que apuntan a ejecutables en directorios temporales.

5. Investiga anomalías. Cualquier resultado que no coincida con patrones administrativos conocidos se convierte en una pista. Sigue cada pista examinando los eventos circundantes: ¿qué pasó en ese endpoint antes y después de que se creara la tarea sospechosa?

La encuesta SANS 2025 sobre caza de amenazas encontró que el 68% de las organizaciones con programas activos de caza descubrieron amenazas que las herramientas de detección existentes no identificaron. ATT&CK es el marco que hace que este tipo de descubrimiento estructurado sea repetible.

Fuentes de datos: dónde dejan rastro los adversarios

Una caza de amenazas es tan buena como los datos disponibles. Sin visibilidad, incluso la mejor hipótesis queda sin comprobar. Cinco fuentes de datos forman la base de una caza efectiva.

La telemetría EDR es la fuente individual más valiosa. Las plataformas de Endpoint Detection and Response como CrowdStrike Falcon, Microsoft Defender for Endpoint y SentinelOne registran árboles de creación de procesos, modificaciones de archivos, cambios de registro, conexiones de red y cargas de DLL a nivel de host. Cuando un adversario ejecuta cmd.exe para lanzar powershell.exe para ejecutar un comando codificado, EDR captura toda la cadena de relación padre/hijo. Esta visibilidad hace posible distinguir la actividad administrativa legítima de la ejecución de herramientas adversarias.

Los logs de consultas DNS revelan la comunicación con infraestructura de comando y control. Los atacantes frecuentemente usan algoritmos de generación de dominios (DGA) para crear dominios que resuelven solo durante horas antes de rotar. Estos dominios tienen alta entropía de caracteres, patrones TLD inusuales y sin reputación histórica. El logging pasivo de DNS captura cada consulta de cada endpoint, creando un registro consultable que sobrevive a los dominios efímeros.

Los logs de proxy y gateway web capturan metadatos de tráfico HTTP/HTTPS saliente. Incluso cuando el tráfico está cifrado, puedes analizar dominios de destino, cadenas User-Agent, patrones de temporización de solicitudes y volúmenes de transferencia de datos. Una estación de trabajo que envía exactamente 4.096 bytes de datos a la misma IP externa cada 60 segundos está exhibiendo comportamiento de beaconing consistente con malware de comando y control.

Los logs de autenticación de Active Directory y proveedores de identidad exponen el movimiento lateral. Un adversario que compromete un endpoint típicamente necesita moverse por la red para alcanzar objetivos de alto valor como servidores de bases de datos y controladores de dominio. Cada salto requiere autenticación. Los patrones inusuales incluyen una sola cuenta autenticándose en 30 sistemas en una hora, cuentas de servicio iniciando sesión interactivamente, o cuentas administrativas autenticándose desde estaciones de trabajo en ubicaciones geográficas donde no hay administradores.

Los datos de flujo de red (NetFlow, sFlow) proporcionan un registro de cada conversación de red: origen, destino, puertos, protocolos, conteo de bytes y duración. Aunque carece de contenido del payload, los datos de flujo sobresalen para identificar conexiones de larga duración, uso inusual de puertos y grandes transferencias de datos que señalan exfiltración.

El flujo de trabajo de caza: de la hipótesis al hallazgo

Una caza de amenazas estructurada sigue un ciclo repetible. Aunque las cazas individuales varían en alcance y técnica, el flujo de trabajo permanece consistente.

Paso 1: Formula la hipótesis. Define qué estás buscando, dónde esperas encontrar evidencia y cómo se ve lo "normal" en ese contexto. Escríbelo. Una hipótesis que no puedes articular es una hipótesis que no puedes comprobar.

Paso 2: Identifica los datos necesarios. Mapea la hipótesis a fuentes de datos y tipos de log específicos. Verifica que los datos existen, cubren el período de tiempo relevante y son consultables. Descubrir una brecha de datos antes de empezar a cazar es mejor que descubrirla a mitad del camino.

Paso 3: Construye y ejecuta consultas. Traduce la hipótesis en consultas de búsqueda contra tu SIEM, plataforma EDR o data lake. Empieza amplio para entender la línea base, luego estrecha progresivamente para aislar anomalías. Por ejemplo, comienza contando todos los eventos de creación de tareas programadas, luego filtra por tareas creadas por cuentas no estándar, luego examina aquellas con argumentos codificados.

Paso 4: Analiza los resultados. Evalúa cada anomalía contra tu conocimiento del entorno. No todo lo atípico es malicioso. Un servidor que hace 10.000 consultas DNS por hora podría ser una aplicación web ocupada, no un host comprometido. El contexto transforma los puntos de datos en inteligencia.

Paso 5: Documenta y escala. Registra tus hallazgos, ya sea que hayas encontrado una amenaza o confirmado que el entorno está limpio para el alcance examinado. Si descubres actividad maliciosa confirmada, escala a tu proceso de respuesta a incidentes. Si descubres brechas de detección, crea nuevas alertas o reglas para prevenir que el mismo punto ciego persista.

Paso 6: Refina y repite. Cada caza genera nuevas preguntas. La tarea programada que investigaste era legítima, pero notaste tres cuentas de servicio con privilegios administrativos que nadie en el equipo reconoce. Eso se convierte en la próxima hipótesis.

Herramientas del oficio

No necesitas una plataforma dedicada de caza de amenazas para empezar. Las herramientas que la mayoría de las organizaciones ya despliegan para monitoreo de seguridad funcionan como instrumentos de caza cuando se usan con intención.

Elastic Security (ELK Stack)

El Stack Elastic (Elasticsearch, Logstash, Kibana) se despliega ampliamente para agregación y búsqueda de logs. Para la caza de amenazas, sus fortalezas son consultas flexibles con KQL (Kibana Query Language), búsqueda rápida de texto completo en miles de millones de eventos y dashboards de visualización que revelan patrones.

Una consulta KQL de ejemplo para cazar ejecución sospechosa de PowerShell:

process.name: "powershell.exe" AND process.args: ("-enc" OR "-encodedcommand" OR "FromBase64String") AND NOT user.name: ("SYSTEM" OR "svc-deploy")

Esta consulta encuentra procesos PowerShell lanzados con comandos codificados, excluyendo cuentas de servicio conocidas. Cualquier resultado justifica investigación inmediata porque los administradores legítimos raramente necesitan codificar sus comandos.

Splunk

El Search Processing Language (SPL) de Splunk está diseñado específicamente para la investigación de seguridad. Sus comandos estadísticos permiten a los cazadores identificar valores atípicos en conjuntos masivos de datos.

Una consulta SPL de ejemplo para cazar comportamiento de beaconing DNS:

index=dns sourcetype=stream:dns
| stats count dc(query) as unique_queries avg(bytes_out) as avg_bytes by src_ip dest_ip
| where count > 500 AND unique_queries < 10 AND avg_bytes < 512
| sort - count

Esta consulta identifica endpoints que hacen muchas solicitudes DNS a pocos dominios únicos con tamaños de payload pequeños y consistentes. Esas tres características juntas indican beaconing automatizado en lugar de comportamiento de navegación humano.

Velociraptor

Velociraptor es una herramienta open source de visibilidad de endpoints y forense diseñada específicamente para la caza de amenazas y la respuesta a incidentes. A diferencia de la caza basada en SIEM, Velociraptor consulta los endpoints directamente y en tiempo real usando VQL (Velociraptor Query Language).

Velociraptor sobresale en cazas que requieren información del estado de los endpoints: DLLs cargadas actualmente, procesos en ejecución, conexiones de red abiertas, tareas programadas y entradas de registro. Escribes un artefacto VQL que describe lo que buscas, lo despliegas en miles de endpoints simultáneamente y recoges resultados en minutos.

Para equipos sin una plataforma EDR comercial, Velociraptor proporciona caza de endpoints a escala empresarial sin coste de licencia. Es particularmente potente para cazar mecanismos de persistencia porque puede consultar el estado actual de los endpoints en lugar de depender de eventos de log históricos.

Caza de amenazas vs. respuesta a incidentes: disciplinas complementarias

Un punto de confusión común es el límite entre la caza de amenazas y la respuesta a incidentes. Comparten herramientas, técnicas y a menudo los mismos analistas. La distinción radica en lo que activa la actividad.

La respuesta a incidentes comienza cuando algo se activa: una alerta salta, un usuario reporta actividad sospechosa o una parte externa te notifica de un compromiso. Sabes que algo ocurrió. El trabajo es contención, investigación y remediación.

La caza de amenazas comienza cuando nada se ha activado. Sin alerta, sin reporte, sin notificación. Operas bajo la suposición de que un adversario podría estar presente a pesar del silencio. El trabajo es descubrimiento. Buscas evidencia de que una brecha ha ocurrido, está ocurriendo o se está preparando.

Las dos disciplinas se alimentan mutuamente. Las cazas que descubren amenazas transicionan a flujos de trabajo de respuesta a incidentes. Las investigaciones de respuesta a incidentes que revelan brechas en la cobertura de detección generan hipótesis para futuras cazas. El analista SOC que investigó un incidente de phishing el mes pasado y descubrió que la organización no tenía visibilidad sobre el abuso de tokens OAuth ahora tiene una hipótesis de caza para el próximo trimestre.

Las organizaciones con programas de seguridad maduros ejecutan ambas actividades continuamente. La capacidad reactiva maneja lo conocido. La capacidad proactiva busca lo desconocido. Ninguna por sí sola es suficiente.

Construir tu primer programa de caza

Iniciar una práctica de caza de amenazas no requiere un equipo dedicado ni herramientas especializadas. Requiere una decisión deliberada de asignar tiempo para investigación proactiva.

Comienza dedicando cuatro horas por semana a la caza estructurada. Elige una técnica ATT&CK por sesión. Escribe la hipótesis. Ejecuta las consultas. Documenta los resultados. Cuatro horas por semana durante 52 semanas producen 52 cazas documentadas, un cuerpo de evidencia que demuestra tanto la conciencia de la postura de seguridad como la mejora continua ante auditores, ejecutivos y reguladores.

Construye una cartera de hipótesis. Cada informe de inteligencia de amenazas que lees, cada incidente al que respondes, cada anomalía que notas durante el monitoreo rutinario puede generar una hipótesis de caza. Mantén una lista priorizada para que siempre sepas qué cazar a continuación.

Mide el impacto de tu programa. Rastrea el número de cazas completadas, técnicas ATT&CK únicas cubiertas, hallazgos confirmados, nuevas reglas de detección creadas a partir de resultados de caza y brechas de detección identificadas. Estas métricas justifican la inversión de tiempo y guían la asignación de recursos a medida que el programa madura.

El modelo de madurez de caza de amenazas del SANS Institute describe cinco niveles desde HMM0 (inicial, principalmente reactivo) hasta HMM4 (líder, con flujos de caza automatizados integrados en las operaciones del SOC). La mayoría de las organizaciones empiezan en HMM1. El objetivo no es alcanzar HMM4 inmediatamente sino progresar de forma constante haciendo de la caza una práctica consistente y documentada en lugar de un ejercicio ocasional.

Del monitoreo pasivo al descubrimiento activo

La industria de la seguridad pasó dos décadas construyendo máquinas de alertas más rápidas, inteligentes y más costosas. Funcionan. Capturan la mayoría de las amenazas. Pero "la mayoría" no es "todas", y las amenazas que no detectan tienden a ser las que causan daños catastróficos.

La caza de amenazas cierra esa brecha. Reconoce una verdad fundamental de que ningún sistema de detección es completo y canaliza ese reconocimiento en acción productiva. La analista que encontró el APT de seis meses no usó una herramienta que el resto del equipo no tenía. Usó el mismo SIEM, el mismo EDR, los mismos datos a los que todos los demás tenían acceso. La diferencia fue una pregunta: "¿Y si hay algo aquí que no hemos visto?"

Esa pregunta, formulada de forma consistente e investigada metódicamente, es toda la disciplina. Empieza con una hipótesis. Ejecuta una caza. Documenta lo que encuentres. Luego hazlo de nuevo la semana que viene. Los adversarios no están esperando a que tus herramientas se pongan al día. Tú tampoco deberías.