AuditBench: los LLM que investigan ataques son máquinas de falsos positivos

¿Qué es esto?

Los proveedores de seguridad presentan cada vez más a los LLM como analistas SOC incansables, capaces de leer logs y encontrar intrusiones. AuditBench, un artículo de benchmark enviado a arXiv el 9 de junio de 2026 (arXiv:2606.10281, Anand, Hou, Fields, Kantchelian, Tao, Thomas y Ho), es uno de los primeros intentos sistemáticos de medir si esa promesa sobrevive al contacto con logs de auditoría reales. Los autores construyeron un conjunto de datos etiquetado de logs de sistema Linux y Windows que abarca más de 50 escenarios de investigación — tanto maliciosos como benignos — y calificaron a cinco LLM de frontera en cuatro tareas que los equipos de respuesta a incidentes realizan de verdad: triaje de alertas (clasificación de ataques) e identificación de movimiento lateral, mecanismos de persistencia y exfiltración de datos.

Cómo funciona

El benchmark combina dos fuentes de datos. Una parte de laboratorio contiene 25 escenarios ejecutados en máquinas virtuales, con técnicas de ataque extraídas de MITRE ATT&CK e implementadas mediante el framework Atomic Red Team. Una segunda parte deriva 16 escenarios de ataque del conjunto de datos OpTC de DARPA. Cada escenario lleva etiquetas de verdad de terreno verificadas manualmente, de modo que el pipeline de evaluación puede calcular tasa de verdaderos positivos, tasa de falsos positivos y F1 por tarea.

Dos decisiones de diseño importan a los profesionales. Primero, los logs se entregan al modelo en dos representaciones: la salida cruda de colectores nativos como auditd en Linux, o una representación de aristas pre-procesada, construida a partir de un grafo de procedencia. Segundo, los modelos evaluados se dividen en grandes (GPT-5, Gemini 2.5 Pro) y pequeños (GPT-5 mini, Gemini 2.5 Flash, Llama 4 Maverick), lo que permite comprobar directamente si la escala compra habilidad investigadora.

Por qué importa

El resultado principal es aleccionador: el rendimiento es desigual en todas las tareas, con una fuerte tendencia a veredictos excesivamente suspicaces — los modelos marcan actividad benigna como maliciosa, reproduciendo exactamente la avalancha de falsos positivos que ya ahoga a los equipos SOC. Un asistente que amplifica la fatiga de alertas no es neutral: los falsos positivos son una superficie de ataque operativa conocida, y trabajos recientes sobre capacidad de supervisión muestran que los analistas se degradan rápido bajo volumen.

Segundo, ningún modelo domina estrictamente, y — en contra de las expectativas de escalado — el mejor modelo pequeño iguala o supera con frecuencia al mejor modelo grande. Con la representación de aristas, los modelos pequeños alcanzaron F1 de 1,00 frente a 0,77 de los grandes en clasificación, y 0,80 frente a 0,57 en persistencia; los grandes solo mantuvieron la ventaja en exfiltración (0,77 frente a 0,56). La representación de los datos y la construcción del prompt movieron los resultados tanto como la elección del modelo.

Tercero, el artículo evalúa la calidad de las explicaciones con un juez de implicación textual (NLI): incluso cuando el veredicto es correcto, el razonamiento declarado por el modelo no siempre está respaldado por los logs — un riesgo real cuando los analistas pegan narrativas de LLM en informes de incidentes.

Defensas

Para los equipos que despliegan investigación asistida por LLM, los hallazgos de AuditBench se traducen en salvaguardas concretas:

• Trate los veredictos del LLM como sugerencias de triaje, nunca como conclusiones definitivas. Mantenga a un analista humano como autoridad sobre las decisiones de cierre y presupueste el sesgo de falsos positivos.
• Invierta en la representación de datos antes que en el tamaño del modelo. Un pre-procesamiento con grafo de procedencia cambió los resultados más que pasar a un modelo mayor — y permite que modelos más baratos hagan el trabajo.
• Verifique las explicaciones, no solo los veredictos. Exija que toda evidencia citada por el LLM (nombres de procesos, líneas de log, marcas de tiempo) se compruebe mecánicamente contra los logs reales antes de entrar en un informe.
• Haga benchmark con su propia telemetría. Los perfiles de error varían mucho por tarea; un modelo fuerte en persistencia puede ser débil en exfiltración. Construya un pequeño conjunto de escenarios etiquetados (Atomic Red Team lo abarata) y mida antes de confiar.
• Endurezca el propio pipeline de logs. Un LLM que lee logs es también un objetivo de inyección de prompts — cadenas controladas por el atacante en argumentos de procesos o nombres de archivo viajan directamente al contexto del modelo.

Estado

Elemento	Detalle
Artículo	arXiv:2606.10281, enviado el 9 de junio de 2026
Alcance	4 tareas de IR, 50+ escenarios, Linux + Windows
Modelos evaluados	GPT-5, Gemini 2.5 Pro, GPT-5 mini, Gemini 2.5 Flash, Llama 4 Maverick
Hallazgo clave	Rendimiento desigual, propenso a falsos positivos; modelos pequeños competitivos
Trabajo previo	ExCyTIn-Bench (arXiv:2507.14201) para agentes de investigación