Un análisis de seguridad pionero de 12 herramientas de seguridad ofensiva agénticas ampliamente desplegadas revela fallos arquitectónicos críticos que permiten a los adversarios robar claves API de LLM, establecer puntos de apoyo persistentes y lograr el compromiso total del host, incluso dentro de contenedores aislados (sandboxed).

Investigadores de seguridad de Cracken han publicado el primer análisis de seguridad exhaustivo de sistemas de red-team agénticos, herramientas impulsadas por IA diseñadas para realizar de forma autónoma pruebas de penetración y operaciones de seguridad ofensiva.

El estudio expone un conjunto generalizado de fallos de diseño compartidos que permiten a un adversario activo exfiltrar credenciales sensibles, convertir la propia infraestructura de la víctima en un arma y comprometer totalmente la máquina del operador, incluso cuando el agente se ejecuta dentro de un contenedor Docker aislado.

Vulnerabilidades de las Herramientas de IA de Red-Team

Los sistemas agénticos de red-team son plataformas totalmente autónomas impulsadas por LLM, construidas para simular operaciones de seguridad ofensiva, incluyendo pruebas de penetración de caja negra.

Los investigadores analizaron 12 herramientas populares de código abierto, incluyendo PentestGPT, RedAmon, DarkMoon, AIRecon, CAI, PentAGI, STRIX, Artemis, METATRON y otras; todas ellas combinan un orquestador de modelo de lenguaje extenso con un contenedor de trabajo Kali Linux capaz de ejecutar comandos de shell arbitrarios contra los objetivos.

Estas herramientas están entrando rápidamente en los flujos de trabajo de seguridad de producción, con una adopción acelerada en los equipos de seguridad empresariales y un creciente interés de las fuerzas ciber-militares, lo que convierte su superficie de ataque en un área de preocupación urgente.

Los investigadores introducen una cadena de ataque (cyber kill chain) adaptada específicamente para sistemas agénticos de red-team, que progresa a través de cinco etapas:

1. RCE del trabajador mediante manipulación del agente — El atacante despliega un honeypot que contiene un payload preparado maliciosamente. Sin ninguna inyección de prompt explícita, el agente lo descarga y lo ejecuta, concediendo una shell inversa en el contenedor del trabajador.
2. Escalada de privilegios — El aislamiento débil del sistema de archivos o de la red entre los contenedores del trabajador y el orquestador permite el movimiento lateral. En PentestGPT, un volumen de Docker escribible expuso el archivo settings.json del orquestador, permitiendo la inyección de hooks que activaban una RCE en el orquestador en cada inicio de sesión posterior.
3. Persistencia — Los atacantes envenenan componentes no volátiles: archivos de código fuente, directorios de servidores MCP expuestos mediante montajes de vinculación (bind mounts), o almacenes de memoria episódica. El código troyanizado restablece el punto de apoyo automáticamente al reiniciar el contenedor.
4. Escape del sandbox — Los montajes de sockets de Docker mal configurados y el acceso a la red del host permiten al atacante lanzar contenedores directamente en el demonio Docker del host, saliendo completamente del entorno aislado.
5. Compromiso del host — Se logra la ejecución completa de código en la máquina del operador, lo que permite la instalación tradicional de C2 y actividades de post-explotación.

Un hallazgo particularmente alarmante es el novedoso ataque de phishing para agentes, una técnica de manipulación sin inyección de prompts que logró un éxito del 97,8% en todos los agentes y LLM probados.

El atacante coloca un binario totalmente funcional (por ejemplo, un descriptor de claves de contraseña llamado pwcrypt) en un honeypot controlado por el adversario, completo con un README convincente y registros de pipeline de CI fabricados.

El agente descarga y ejecuta el binario, creyendo que es un artefacto crítico. El binario contiene una vulnerabilidad de corrupción de memoria autoinyectada, no código malicioso, que se activa al ejecutarse y secuestra el flujo de control para lograr la ejecución de código arbitrario.

Esto anula completamente la inspección basada en modelos, ya que no hay shellcode, payload codificado ni patrones de llamadas al sistema sospechosos. El ataque fue efectivo contra Claude Opus 4.8, GPT-5.5, Gemini 3.1 Pro, DeepSeek V4 Pro, GLM-5.1 y Kimi K2.6.

Una vez establecido el punto de apoyo, la exfiltración de secretos es trivialmente alcanzable en 11 de las 12 herramientas analizadas. La mayoría de los frameworks ubican al trabajador y al orquestador en el mismo contenedor, exponiendo directamente las claves API del LLM y la memoria entre sesiones.

En RedAmon, una clave API interna compartida y una red puente de Docker no autenticada permitieron al atacante enumerar y exfiltrar el historial de conversaciones, incluyendo hosts objetivo y credenciales de cada usuario en todas las sesiones.

Siete de las doce herramientas implementan barandillas (guardrails), filtros de regex o validadores de "LLM como juez" para bloquear objetivos sensibles. El estudio concluye que ninguno es efectivo.

Las barandillas se aplican solo en la capa de orquestación, validando las decisiones del LLM pero nunca monitoreando la actividad de red real del trabajador. Un atacante con una shell de trabajador elude cada barandilla de forma invisible, un problema reflejado en la reciente divulgación de Microsoft de CVE-2026-25592 y CVE-2026-26030 en Semantic Kernel, donde los investigadores confirmaron que los LLM no son límites de seguridad.

Los investigadores proponen una arquitectura segura basada en una invariante: trata al trabajador de LLM como un entorno no confiable. Los principios clave incluyen una separación estricta entre trabajador y orquestador sin montajes compartidos escribibles, segmentación de red autenticada, aislamiento de secretos (las claves API nunca deben llegar al trabajador), aplicación de barandillas en la capa del trabajador mediante filtrado de salida de red y sistemas de archivos de trabajador inmutables que se reconstruyan entre operaciones.