Cuando el pentest muerde: atacar las herramientas que hacen red team por ti

¿Qué es esto?

Un preprint publicado el 23 de junio de 2026 (arXiv:2606.24496) presenta lo que sus autores describen como el primer análisis de seguridad en profundidad de los agentes autónomos que hoy ejecutan operaciones de seguridad ofensiva. La comunidad ha dedicado dos años a hacer más capaces estas herramientas «agentic red team»; mucho menos se ha preguntado si es seguro ejecutarlas. La conclusión incomoda: la mayoría de las herramientas de uso extendido comparten los mismos fallos estructurales, y un defensor situado en el objetivo de una prueba de intrusión puede volver la automatización del atacante contra él.

El modelo de amenaza es el de un pentest corriente. El operador apunta un agente autónomo a un objetivo y lo deja trabajar. Lo que el estudio añade es que, en un compromiso de caja negra, el objetivo es una entrada no confiable con la que el agente debe interactuar —y es justo en la interacción con entradas no confiables donde los agentes se ven comprometidos. De ahí una inversión de papeles: la máquina que ejecuta el instrumental ofensivo, y no el objetivo, es la que acaba comprometida.

Cómo funciona

Estas plataformas suelen compartir una estructura de tres partes: un orquestador que ejecuta el bucle del agente y guarda los activos sensibles (claves de API de LLM, registros entre sesiones, habilidades, memoria), uno o varios nodos de trabajo —normalmente contenedores Kali— que ejecutan realmente los comandos de shell y las herramientas ofensivas contra los objetivos, y una interfaz para el operador. Los workers tocan el mundo exterior; el orquestador guarda las joyas de la corona.

La técnica de manipulación descrita, que los autores llaman «agent-phishing», evita deliberadamente la inyección de prompt clásica. En su lugar, un defensor deposita en un honeypot artefactos plausibles —una utilidad de bóveda de contraseñas, un asistente de restauración de bases de datos, un desempaquetador de configuración— de modo que parezcan exactamente lo que el agente necesita para avanzar. El agente los descubre, los descarga a su propia infraestructura, los inspecciona y los ejecuta, porque desde su punto de vista así progresa el compromiso. La herramienta trampa hace lo que anuncia (descifra una contraseña y termina limpiamente), pero el análisis de un archivo de entrada manipulado dispara un fallo de seguridad de memoria que entrega el control al atacante como efecto colateral silencioso. Como el binario porta un error de implementación trabajado en lugar de malware evidente, los análisis estático y dinámico tienden a dejarlo pasar. Este detalle importa, por eso lo mantenemos abstracto: aquí no se reproduce ningún payload funcional.

Una vez que se ejecuta código en un worker, el artículo detalla una cadena de escalada: del worker al orquestador mediante aislamiento de sistema de archivos incompleto (volúmenes compartidos con escritura que exponen el código del orquestador) o aislamiento de red débil (red del host, API internas alcanzables); persistencia, ya sea troyanizando código fuente y configuración que sobreviven a los reinicios de contenedor, o envenenando habilidades y memoria episódica de larga duración para que las sesiones futuras se reinfecten; escape del entorno aislado mediante ajustes de contenedor demasiado permisivos como --privileged, CAP_NET_RAW o un socket Docker montado; y finalmente el compromiso completo del host.

Por qué importa

En un banco de pruebas automatizado que abarca diez de estas herramientas y seis modelos de frontera —incluidos Claude Opus 4.8, GPT-5.5 y Gemini 3.1 Pro— las cargas depositadas alcanzaron ejecución de código dentro del worker en el 97,8 % de las ejecuciones completadas. Los únicos fallos fiables ocurrían cuando el modelo se negaba por completo a realizar la prueba de intrusión; en cuanto un test empezaba de verdad, el agente casi siempre encontraba, descargaba, inspeccionaba y ejecutaba la herramienta plantada. El radio de impacto es real por lo que estos sistemas custodian: el orquestador de un agente ofensivo concentra claves de API, registros de clientes y habilidades de ataque reutilizables, y sus workers ya tienen permiso para generar tráfico de red hostil. Un compromiso convierte una plataforma de red team autorizada en infraestructura controlada por el atacante.

Peor aún, las barreras que muchos de estos productos promocionan no ayudan una vez que cae el worker. Las políticas se aplican en la capa del orquestador —por ejemplo, bloquear escaneos hacia dominios .gov— mientras que el comportamiento real del worker a nivel de sistema operativo queda sin vigilar. Un adversario con un shell en el worker sencillamente actúa fuera del campo de visión de la barrera.

Defensas

Los autores recomiendan dejar de tratar como confiable al worker gobernado por el modelo, y diseñar para un radio de impacto pequeño cuando —no si— se vea comprometido:

Suponga que el worker es hostil. El componente que ingiere los datos no confiables del objetivo debe ser la parte menos privilegiada del sistema. Diseñe como si un atacante ya tuviera un shell en él.

Mantenga los secretos fuera de los workers. Las claves de API de LLM, los registros de clientes y las credenciales pertenecen al orquestador o a un servicio de secretos, nunca montados en el contenedor que toca los objetivos.

Aplique el aislamiento en la capa de SO y de red, no solo en los prompts. Enrute la salida de los workers por un proxy externo que aplique la política sobre el tráfico real, retire capacidades de contenedor demasiado permisivas (--privileged, CAP_* innecesarias, sockets Docker montados) y dé a los workers acceso de sistema de archivos y de red acotado y mínimo.

No ejecute herramientas descargadas en el orquestador. Evite ejecutar binarios provistos por el objetivo cerca del núcleo de confianza; exponga las acciones de alta capacidad solo mediante API estrechas y endurecidas en lugar de un shell crudo.

Trate la memoria y las habilidades como superficie de ataque. La persistencia mediante memoria episódica o habilidades envenenadas es una vía documentada: firme, acote y revise las entradas duraderas del agente para que una sola sesión no pueda reinfectar en silencio a la siguiente.

Estado

Elemento	Referencia	Notas
Estudio principal	arXiv:2606.24496, 23 jun 2026	Primer análisis de seguridad en profundidad de herramientas ofensivas agénticas de uso extendido
Técnica	«Agent-phishing»	Engaño contextual, sin inyección de prompt; el agente ejecuta por sí mismo una herramienta plantada
Resultado medido	Mismo artículo	Ejecución de código en el worker en el 97,8 % de las ejecuciones completadas, sobre 10 herramientas y 6 modelos
Modelos evaluados	Mismo artículo	Incluye Claude Opus 4.8, GPT-5.5, Gemini 3.1 Pro
Cobertura independiente	GBHackers, 25 jun 2026; resumen de Adversa AI, 2 jul 2026	Difusión pública de la divulgación

La lección duradera va más allá del instrumental ofensivo: cualquier agente que inspeccione y ejecute artefactos de un entorno no confiable está a un archivo manipulado de correr el código del atacante. La suposición prudente es que la parte de su sistema que toca el exterior será comprometida; diseñe para que, cuando lo sea, el daño se detenga ahí.