Resumen Técnico: Honeyval – Un Marco de Evaluación Integral para Trampas HTTP Potenciadas por LLM

Declaración del Problema

Las trampas (honeypots) son sistemas señuelo defensivos diseñados para imitar componentes reales de una pila de software con el fin de detectar, monitorear y estudiar a los atacantes. Si bien las trampas de alta interacción tradicionales ofrecen simulaciones realistas, dependen de recursos del sistema reales, exponiendo a los defensores a riesgos de seguridad significativos. Recientemente, los Modelos de Lenguaje Grandes (LLM) han surgido como una solución para simular interacciones del sistema con alta fidelidad sin requerir acceso a recursos del host vulnerables.

Sin embargo, el desarrollo de trampas potenciadas por LLM carece de un marco de evaluación unificado, escalable y reproducible. Los métodos de evaluación actuales sufren tres limitaciones principales:

1. Escalabilidad: La dependencia de pruebas manuales en laboratorio o despliegues reales dispersos dificulta el desarrollo iterativo.
2. Reproducibilidad: Las evaluaciones a menudo carecen de configuraciones de sistema precisas. Cuando los LLM simulan sistemas mal especificados, generan detalles inconsistentes (por ejemplo, estados del sistema de archivos) entre ejecuciones, lo que hace que los resultados sean incomparables.
3. Representatividad: Las comparaciones estáticas de comandos y salidas o las interacciones abiertas no logran capturar cadenas de ataque realistas ni adaptarse a objetivos adversarios específicos.

Las evaluaciones existentes suelen medir la similitud de las respuestas frente a comandos fijos, realizan pruebas manuales o se despliegan en línea. Estos métodos no abordan adecuadamente la dinámica de "gato y ratón" donde tanto atacantes como defensores se adaptan mutuamente.

Metodología: El Marco Honeyval

Para abordar estas brechas, los autores introducen Honeyval, un marco de evaluación integral diseñado específicamente para trampas HTTP potenciadas por LLM. El marco se basa en 16 configuraciones realistas de aplicaciones backend obtenidas de BaxBench, una referencia para la seguridad de aplicaciones web generadas por LLM.

Componentes Principales

1. Entornos: Honeyval utiliza 16 aplicaciones backend distintas (por ejemplo, calculadoras, catálogos de productos, servicios de inicio de sesión) definidas por especificaciones OpenAPI estandarizadas. Cada aplicación incluye:

   • Una implementación segura.
   • Una implementación insegura y explotable.
   • Un conjunto de pruebas funcionales.
   • Un objetivo de explotación definido (por ejemplo, descargar un script, eliminar una tabla de base de datos, modificar una contraseña de administrador o exfiltrar almacenamiento del navegador).

2. Tareas de Evaluación: El marco emplea tres tareas distintas para garantizar robustez y comparabilidad:

   • Tarea Principal (Trampa vs. Atacante): Un agente de hacking interactúa directamente con la trampa potenciada por LLM. La trampa simula la API del backend, mientras que el agente intenta lograr el objetivo de explotación definido. Las métricas rastreadas incluyen la longitud de la interacción (número de solicitudes), costos de ejecución, latencia y tasas de detección de la trampa.
   • Tarea de Control del Agente: El agente de hacking interactúa con las implementaciones reales seguras e inseguras de las aplicaciones backend. Esta tarea mide la capacidad base del agente para explotar vulnerabilidades y su capacidad para distinguir entre sistemas reales y trampas (Tasa de Falsos Positivos).
   • Tarea de Control de la Trampa: La trampa se prueba contra el conjunto de pruebas funcionales de la aplicación backend que simula. Esto asegura que las respuestas del LLM tengan alta fidelidad funcional y no sean fácilmente identificadas por solicitudes benignas.

3. Agentes y Modelos:

   • Atacantes: El marco se prueba contra un agente ReAct personalizado y agentes de codificación de vanguardia (Claude Code, Gemini CLI).
   • Trampas: El estudio evalúa cinco LLM rentables (Gemini 3 Flash, Claude Haiku 4.5, Gemini 2.5 Flash, Qwen 3.5 9B, GPT 5.4 Nano) que actúan como columna vertebral de la simulación.
   • Líneas Base: Una trampa de baja interacción basada en reglas (API simulada) sirve como línea base para la comparación.

4. Adaptabilidad: El marco permite probar configuraciones personalizadas de trampas (por ejemplo, instruir al LLM para intentar inyección de prompts o convencer al atacante de que el sistema es seguro) y configuraciones de agentes (por ejemplo, instruir a los agentes para ocultar su intención).

Contribuciones Clave

1. Formulación de Requisitos: Los autores identifican y formalizan cuatro requisitos clave para la evaluación de trampas LLM: Escalabilidad, Reproducibilidad, Representatividad y Adaptabilidad.
2. Marco Honeyval: Presentan y publican como código abierto el primer marco de evaluación integral para trampas HTTP potenciadas por LLM, que cuenta con 16 entornos backend fundamentados y una estructura de tareas tripartita (Principal, Control del Agente, Control de la Trampa).
3. Evaluación Empírica Exhaustiva: El artículo presenta una evaluación a gran escala de LLM rentables como trampas frente a agentes de hacking de IA de última generación, analizando dinámicas de interacción, asimetrías de costos y tasas de detección.

Resultados y Análisis

Longitud de Interacción y Compromiso

Las trampas potenciadas por LLM superan significativamente a las líneas base basadas en reglas en la participación de los atacantes.

• Métrica: Longitud promedio de interacción (solicitudes por interacción).
• Hallazgo: Las trampas potenciadas por LLM sostuvieron interacciones con un promedio de 82.6 solicitudes, en comparación con 30.6 solicitudes para las trampas basadas en reglas. Esto indica que los LLM pueden mantener la ilusión de un sistema real mucho más tiempo, proporcionando a los defensores más datos sobre las tácticas de los atacantes.

Detectabilidad

• Métrica: Tasa de Verdaderos Positivos (TPR) de detección de trampas por agentes frente a Tasa de Falsos Positivos (FPR) en aplicaciones reales.
• Hallazgo: Mientras que las trampas basadas en reglas fueron identificadas a tasas abrumadoras, las trampas potenciadas por LLM fueron significativamente más difíciles de detectar. En la mayoría de los casos, las tasas de detección estuvieron muy por debajo del 40%. Cabe destacar que incluso modelos más pequeños como Qwen 3.5 9B rindieron bien. Sin embargo, los agentes que utilizan Gemini CLI mostraron altas tasas de detección pero también altos FPR en aplicaciones reales, lo que sugiere un juicio poco fiable en esa configuración específica.

Asimetría de Costos

• Métrica: Ventaja relativa de costo de ejecución (Costo del Agente / Costo de la Trampa).
• Hallazgo: A pesar de utilizar una arquitectura ingenua donde la trampa procesa cada solicitud individualmente, las trampas potenciadas por LLM generalmente mantuvieron una ventaja de costos sobre los agentes atacantes. Esto sugiere que incluso en una configuración no optimizada, el defensor puede sostener la interacción a un costo menor que el que el atacante puede sostener para el ataque.

Compensaciones entre Latencia y Fidelidad

• Latencia: Una limitación clave identificada es la latencia de respuesta. Incluso los modelos más rápidos (Gemini 3 Flash) tardaron aproximadamente 3.3 segundos por respuesta.
• Fidelidad: Los modelos lograron alta fidelidad funcional (puntuaciones Pass@1 >70% en conjuntos de pruebas), pero esto vino a costa de una alta generación de tokens (promediando 200–500+ tokens por respuesta), lo que incrementa los costos y la latencia.
• Correlación con Detección: Si bien la latencia no se correlacionó estrictamente con las tasas de detección en todos los modelos, los agentes citaron frecuentemente la latencia de respuesta y los tiempos de espera como evidencia para clasificar una aplicación como una trampa.

Impacto de Instrucciones Personalizadas

El estudio exploró la modificación de los prompts de las trampas para lograr objetivos contraofensivos:

• Prompt "Convencer": Instruir a la trampa para afirmar que la aplicación es segura aumentó la longitud de la interacción (promedio 102.6 solicitudes) pero también incrementó la tasa de detección (TPR 0.45).
• Prompt "Inyección Cuidadosa" (Prompt Injection): Instruir a la trampa para intentar inyección de prompts aumentó significativamente las tasas de detección (TPR 0.49) y redujo la longitud de la interacción, ya que los agentes a menudo detectaron los intentos de inyección. Esta configuración también degradó la fidelidad funcional en conjuntos de pruebas benignos.

Significado y Afirmaciones

El artículo afirma que Honeyval proporciona una base necesaria, escalable y reproducible para el desarrollo de trampas potenciadas por LLM. Los autores afirman que:

1. Los LLM son Defensores Prometedores: Las trampas potenciadas por LLM ofrecen una alternativa viable a los sistemas de alta interacción, proporcionando simulaciones de alta fidelidad con riesgo de seguridad mínimo y costos operativos más bajos en comparación con el costo del ataque.
2. La Evaluación es Crítica: Las compensaciones únicas observadas (por ejemplo, interacciones más largas frente a un mayor riesgo de detección al usar prompts contraofensivos) destacan la necesidad de las tareas de control proporcionadas por Honeyval para monitorear los efectos secundarios de los cambios de configuración.
3. Direcciones Futuras: El trabajo sugiere que, aunque las arquitecturas ingenuas actuales son efectivas, las mejoras futuras en la gestión del contexto (caché, memoria) y el hardware de inferencia podrían mejorar aún más el rendimiento. El marco está diseñado para apoyar la evolución tanto de atacantes como de defensores automatizados.

Los autores concluyen que, si bien las trampas potenciadas por LLM muestran una clara promesa, su implementación requiere una configuración y monitoreo cuidadosos, lo cual facilita Honeyval. El marco se publica como código abierto para avanzar en los esfuerzos de la comunidad en este dominio.