Cyber Defense Benchmark: los LLM punteros fallan en el threat hunting

¿Qué es esto?

Un argumento recurrente en el tooling de seguridad es el del analista SOC autónomo: apunte un agente LLM a sus logs y déjelo cazar. Un nuevo benchmark pone a prueba esa promesa de forma directa, y el resultado es un fallo rotundo.

El 21 de abril de 2026 (última revisión el 23 de abril de 2026), Alankrit Chona, Igor Kozlov y Ambuj Kumar publicaron Cyber Defense Benchmark: Agentic Threat Hunting Evaluation for LLMs in SecOps (arXiv:2604.19533). El trabajo mide la capacidad de los agentes LLM para la tarea central del SOC, el threat hunting: a partir de una base de logs de Windows en bruto, sin preguntas guiadas ni pistas, encontrar las marcas de tiempo exactas de los eventos maliciosos.

Es mucho más difícil que los cuestionarios de seguridad de opción múltiple en los que los LLM ya puntúan bien. No hay pregunta que responder, solo un pajar y la instrucción de hallar las agujas. En cinco modelos punteros, todos fallaron gravemente.

Cómo funciona

El benchmark envuelve 106 procedimientos de ataque reales del corpus de código abierto OTRF Security-Datasets —que abarca 86 subtécnicas de MITRE ATT&CK repartidas en 12 tácticas— en un entorno de aprendizaje por refuerzo.

Cada episodio funciona así, según el artículo:

1. Un simulador de campaña determinista reproduce un ataque real,
   desplazando las marcas de tiempo y ofuscando los nombres de
   entidades para que el agente no memorice la grabación pública.
2. El agente recibe una base SQLite en memoria de
   75.000 a 135.000 registros (ruido de fondo en su mayoría benigno).
3. El agente envía iterativamente consultas SQL para investigar,
   y luego marca explícitamente las marcas de tiempo que cree maliciosas.
4. Las marcas se puntúan al estilo CTF contra una verdad base
   derivada de reglas de detección Sigma.

Usar reglas Sigma —un formato de detección agnóstico del SIEM, mapeado a ATT&CK— como verdad base significa que el agente se evalúa frente a lo que un ingeniero de detección competente marcaría realmente, no frente a una clave sintética.

Los modelos probados fueron Claude Opus 4.6, GPT-5, Gemini 3.1 Pro, Kimi K2.5 y Gemini 3 Flash, en 26 campañas que cubren 105 de los 106 procedimientos.

Por qué importa

Las cifras son contundentes. El mejor modelo, Claude Opus 4.6, marcó correctamente solo el 3,8 % de los eventos maliciosos de media. Ninguna ejecución de ningún modelo encontró jamás todas las marcas de un episodio.

Los autores definen un umbral de despliegue razonable: ≥ 50 % de recall en cada táctica ATT&CK, el mínimo antes de dejar que un agente cace sin supervisión. Ningún modelo lo supera. El líder lo alcanzó en 5 de 13 tácticas; los otros cuatro modelos en cero.

La brecha que importa es la que separa este resultado de los benchmarks pulidos que citan los proveedores. Los LLM parecen sólidos en cuestionarios de seguridad ricos en pistas. Sumerja los mismos modelos en una caza abierta y basada en evidencias dentro de logs ruidosos y el rendimiento se desploma. La habilidad medida aquí —pivotar con paciencia e iteración por un gran corpus para ensamblar señales débiles en un hallazgo confirmado— es exactamente lo que hace un analista SOC, y exactamente lo que los benchmarks preparados no capturan.

Para quien evalúe un producto de «threat hunting con IA», esta es una razón concreta para exigir evaluación en tareas abiertas, no en cuestionarios de clasificación.

Defensas

Es un hallazgo de madurez defensiva, así que la «defensa» consiste en desplegar los LLM en un SOC sin confiar en exceso en ellos.

1. No ejecute caza autónoma sin supervisión. Con esta evidencia, un agente LLM dejado solo para encontrar eventos maliciosos perderá la gran mayoría. Mantenga a un analista humano en el bucle para cualquier caza que condicione una respuesta.
2. Use los LLM donde realmente son fuertes. Resumir una alerta, redactar una consulta, explicar una regla Sigma, triar un evento ya detectado —tareas estrechas y acotadas— no tienen nada que ver con el descubrimiento abierto. Acote la herramienta a esos usos.
3. Evalúe con sus propias tareas abiertas. La precisión que anuncia un proveedor en cuestionarios dice poco sobre la caza. Reproduzca datos de ataque reales (el corpus OTRF es público) y mida el recall por táctica ATT&CK antes de confiar en un agente.
4. Trate el recall, no la precisión, como métrica de seguridad. Un cazador que pierde el 96 % de los eventos es peligroso aunque todo lo que marca sea correcto. Mida lo que no logró encontrar.
5. Ponga una detección determinista debajo. Las reglas Sigma y la detección por firmas captaron estos eventos por construcción. Los agentes LLM deberían situarse encima de una ingeniería de detección fiable, no reemplazarla.

Estos puntos refuerzan la advertencia más amplia de la temporada: evaluar agentes de seguridad es difícil y una sola cifra oculta el punto de operación en el que realmente trabajará.

Estado

Elemento	Referencia	Fecha	Notas
Cyber Defense Benchmark	arXiv:2604.19533	2026-04-21 (v1) → 2026-04-23 (v3)	106 procedimientos, 86 subtécnicas ATT&CK, 12 tácticas
Mejor resultado	Claude Opus 4.6	2026	3,8 % de eventos marcados; pasa 5/13 tácticas
Otros modelos	GPT-5, Gemini 3.1 Pro, Kimi K2.5, Gemini 3 Flash	2026	Superan el umbral en cero tácticas
Verdad base	OTRF Security-Datasets + reglas Sigma	en curso	Corpus público; resultados reproducibles

La conclusión no es que los LLM sean inútiles en un SOC, sino que el threat hunting abierto aún no es una tarea delegable. Mídala antes de confiar en ella.