¿Qué es el threat hunting y en qué se diferencia de esperar la alerta?

El threat hunting, o caza de amenazas, es la búsqueda deliberada de un atacante que ya está dentro y que no ha disparado ninguna alarma. Parte de una suposición incómoda: que las herramientas no lo detectaron, que los registros no lo marcaron y que si nadie va a buscarlo, nadie lo va a encontrar.

No es una herramienta que se compra ni una función que se activa. Es un trabajo que alguien hace, con una hipótesis, unos datos y unas horas por delante.

¿En qué se diferencia de esperar una alerta?

En quién empieza la conversación.

El modelo normal de un centro de operaciones es reactivo por diseño: llega una alerta, alguien la analiza, decide si es real y actúa. Funciona bien, y es donde se resuelve la inmensa mayoría del trabajo diario.

Pero ese modelo tiene un límite que conviene entender sin dramatismo: solo puede avisar de lo que alguien programó que avisara. Cada alerta existe porque un humano, en algún momento, describió un patrón y dijo que eso merecía atención. Lo que nadie describió no genera nada. No es un fallo de la herramienta, es su naturaleza.

La caza invierte el orden. No espera a que algo suene. Alguien se sienta con una sospecha concreta y va a comprobarla en los datos.

¿Por qué hace falta si ya tengo SIEM y EDR?

Porque el SIEM y el EDR son excelentes en lo conocido y ciegos en lo que no está modelado. Y hay tres situaciones bastante comunes donde eso deja hueco.

Cuando el atacante usa herramientas legítimas. Un intruso que se mueve con las utilidades de administración que ya vienen en el sistema no instala nada raro, no ejecuta nada desconocido y no dispara casi nada. Todo lo que hace está permitido. El problema no es cada acción por separado, es la secuencia.

Cuando lo que entra es válido. Una credencial robada o una sesión secuestrada no producen un intento fallido de acceso. Producen un acceso correcto. No hay nada que bloquear.

Cuando la regla existe pero la cobertura no. Esto es lo más frecuente y lo más incómodo: la detección está bien escrita, pero el servidor donde ocurrió no envía ese tipo de registro. La regla no falló, nunca llegó a ejecutarse.

¿Cómo es una cacería de verdad?

Siempre empieza con una hipótesis, no con una herramienta. Una hipótesis es una frase que se puede comprobar o descartar con datos. Por ejemplo, esta:

“Si alguien robó credenciales de un administrador, debería ver sesiones de cuentas privilegiadas fuera del horario habitual y desde equipos que esa persona no usa nunca.”

A partir de ahí el trabajo es ordenado y bastante aburrido, que es justo lo que debe ser:

• Decidir qué datos responderían esa pregunta: registros de autenticación, inventario de equipos, horarios reales de cada persona.
• Establecer qué es lo normal antes de buscar lo anormal. Sin esa línea base no hay nada que comparar y todo parece sospechoso.
• Buscar las desviaciones y revisarlas una a una, sabiendo de antemano que la mayoría van a tener explicación.
• Documentar el resultado, incluso cuando el resultado es que no había nada.
• Convertir lo aprendido en una detección automática, para no tener que volver a cazar lo mismo el mes que viene.

Ese último paso es el que separa una caza útil de un rato de curiosidad. Cada hipótesis comprobada debería dejar detrás una regla nueva o una fuente de datos que antes no llegaba.

Para ordenar qué hipótesis vale la pena perseguir, casi todo el sector usa el catálogo MITRE ATT&CK, que recopila las técnicas documentadas que emplean los atacantes reales. Permite darle la vuelta a la pregunta: de todas esas técnicas, ¿cuáles detectaría usted hoy y cuáles no?

¿Qué hipótesis vale la pena perseguir primero?

Esta es la pregunta que más cuesta responder cuando se empieza, así que van cuatro que funcionan en casi cualquier empresa mediana y que no requieren herramientas especiales. Cada una está formulada para poder descartarse con datos.

Cuentas privilegiadas fuera de su patrón. Si alguien robó credenciales de administración, debería haber sesiones de esas cuentas en horarios o desde equipos que no corresponden a la persona. Es la más rentable para empezar porque las cuentas privilegiadas son pocas y el volumen de datos es manejable.

Herramientas de administración usadas donde no tocan. Las utilidades que vienen con el sistema operativo son legítimas en manos del equipo de sistemas y muy sospechosas en un equipo de contabilidad. Buscar ejecuciones de esas herramientas fuera del área que debería usarlas encuentra cosas con una frecuencia incómoda.

Salidas de datos que no encajan. Volúmenes de información saliendo hacia destinos con los que la empresa no trabaja, o a horas en las que no debería salir nada. No hace falta saber qué contiene: basta con que el patrón no tenga explicación.

Cuentas de servicio comportándose como personas. Una identidad automática que de pronto accede a sistemas nuevos, o que cambia de ritmo, o que se autentica desde un sitio distinto. Casi nadie las vigila, precisamente porque son automáticas y se da por hecho que hacen siempre lo mismo.

Las cuatro tienen algo en común y conviene verlo: ninguna busca un programa malicioso. Buscan comportamiento que no encaja. Un atacante competente evita el programa malicioso justamente porque sabe que eso sí se detecta. Lo que no puede evitar es comportarse distinto a quien dice ser. Los avisos de CISA son una buena fuente para elegir la hipótesis del mes, porque describen lo que se está usando ahora mismo contra empresas reales.

¿Qué hace falta para poder hacerlo?

Cuatro cosas, y la última es la que casi siempre falta.

• Telemetría suficiente. No se puede cazar en datos que no existen. Si los servidores críticos no envían registros de proceso y de autenticación, no hay caza posible por mucho talento que haya.
• Retención. Un atacante puede llevar meses dentro. Si solo se guardan siete días de registros, la caza empieza y termina en esa semana.
• Conocimiento del entorno. Saber qué es raro en esta empresa concreta. Un proceso ejecutándose a las tres de la mañana puede ser un intruso o puede ser el cierre contable de todos los meses.
• Tiempo protegido. Horas de alguien que no estén ocupadas atendiendo la cola de alertas. Esta es la que se cae primero: cuando hay presión, la caza es lo que se pospone, porque no tiene a nadie reclamándola.

¿Cada cuánto se hace?

Lo razonable en una empresa mediana es una caza formal al mes, de entre cuatro y ocho horas, sobre una hipótesis elegida a conciencia. No hace falta más para empezar a obtener valor, y es un compromiso que se puede sostener.

Lo que no funciona es la caza improvisada, esa de “cuando tengamos un rato”. Ese rato no llega nunca, porque siempre hay algo más urgente con alguien detrás pidiéndolo.

También conviene lanzar una caza puntual cuando aparece una amenaza nueva relevante para el sector, para comprobar si esa técnica concreta habría pasado desapercibida en su entorno.

¿Y si no encuentra nada?

Es el resultado más frecuente, y mucha gente lo interpreta como tiempo perdido. Es exactamente al revés.

Una caza que no encuentra intrusos casi siempre encuentra otras cosas, y todas valen dinero:

• Equipos que no estaban enviando registros y nadie lo sabía.
• Detecciones que estaban mal configuradas y no se habrían disparado nunca.
• Cuentas con permisos que ya no corresponden a nadie.
• Una línea base documentada de lo que es normal, que hace más rápida la siguiente investigación de verdad.

Y produce algo más difícil de medir pero igual de real: la diferencia entre creer que no hay nadie dentro y haberlo comprobado. No son lo mismo, aunque el informe se parezca.

Esa es, por cierto, la dificultad de fondo de toda la prevención, y la hemos tratado aparte en el artículo sobre cómo medir lo que no llegó a pasar.

Preguntas frecuentes

Buscar en vez de esperar

La diferencia entre un centro de operaciones que solo reacciona y uno que además caza no se nota el día que suena la alarma. Se nota el día que no suena y resulta que había algo.

Nadie puede garantizar que no haya nadie dentro de su red. Lo que sí se puede es ir a mirar, dejarlo escrito y hacerlo otra vez el mes que viene.