Mi compañero de batallas José Ramón Palanco - que acabó en mi equipo de Eleven Paths tras la adquisición de su startup Dinoflux -, se lanzó a la aventura de construir Plexicus.ai, inicialmente una plataforma para hacer patching con IA, que fue evolucionando.
Esta idea creció y creció, y hoy en día es una solución para hacer AI Swarm Penterst, Exploiting y Patching, todo ello utilizando un Enjambre de Agentes IA que colaboran entre ellos. Es decir, para detectar con código, explotar con IA, cerrar con un PR.
escrito por Chema Alonso con la colaboración de Pablo González, Fran Ramírez, Amador Aparicio, Manuel S. Lemos y José Palanco de Plexicus.ai en 0xWord
De esto va el artículo de hoy, que que le he pedido al gran José Ramón Palanco que me escriba, para que conozcáis de primera mano cómo funciona esta tecnología que está transformando la forma en la que se gestionan los procesos de Offensive Security en las organizaciones. Así que os dejo aquí.
Chema Alonso
AI SWARM PENTEST
Autor: José Ramón Palanco,
Lo he dicho muchas veces y lo repito: no tenemos escasez de herramientas, tenemos escasez de criterio. SAST, análisis de dependencias, DAST, herramientas de cloud... cada uno genera su lista, las listas se solapan, los tickets se amontonan y al final la persona de seguridad se pasa el día haciendo triaje mientras el desarrollador mira el ticket dudando de si es de verdad.
Y datos, que los hay: el DBIR de Verizon de este año pone la explotación de vulnerabilidades como vector inicial en el 31% de las brechas analizadas. Mientras, eu-LISA publicó en julio un informe sobre IA generativa en el desarrollo de software que viene a decir, con rodeos institucionales, lo que ya sabemos todos: se genera código más rápido de lo que se puede revisar. La cuenta no sale.
Primera regla: demuestra que la web es tuya
Antes de lanzar esta tecnología contra cualquier web tienes que demostrar que el objetivo es tuyo, igual que cuando verificas un dominio en Search Console: o una meta tag en el HTML, o un fichero subido al servidor, o un registro DNS TXT. Vale para una aplicación concreta o para el dominio entero, a elegir. Parece una tontería y no lo es: es lo que separa una prueba controlada de un problema legal.
Luego configuras la misión como si le pasaras el briefing a un pentester que va a ir presencial. La profundidad: rápida (minutos), estándar (entre media hora y una hora) o profunda (de una a cuatro horas). Cuántos agentes entran en paralelo. Por dónde quieres que se centren: autenticación, lógica de negocio, inyecciones, control de acceso, APIs, pagos, subida de ficheros, SSRF... Y sobre todo lo que NO se toca, que queda por escrito antes de empezar:
Primera regla: demuestra que la web es tuya
Antes de lanzar esta tecnología contra cualquier web tienes que demostrar que el objetivo es tuyo, igual que cuando verificas un dominio en Search Console: o una meta tag en el HTML, o un fichero subido al servidor, o un registro DNS TXT. Vale para una aplicación concreta o para el dominio entero, a elegir. Parece una tontería y no lo es: es lo que separa una prueba controlada de un problema legal.
Luego configuras la misión como si le pasaras el briefing a un pentester que va a ir presencial. La profundidad: rápida (minutos), estándar (entre media hora y una hora) o profunda (de una a cuatro horas). Cuántos agentes entran en paralelo. Por dónde quieres que se centren: autenticación, lógica de negocio, inyecciones, control de acceso, APIs, pagos, subida de ficheros, SSRF... Y sobre todo lo que NO se toca, que queda por escrito antes de empezar:
Nada de acciones destructivas, ni borrar cuentas, ni mandar emails o SMS, ni capturar pagos, ni hacer flooding del rate-limit.
Puedes darle credenciales de prueba (usuario y contraseña, token, API keys, lo que sea), que se guardan cifradas y, prometen, no acaban en ningún log. Usad una cuenta de pruebas, que para eso están.
Para la demo se usa demo.testfire.net, que es el Altoro Mutual de toda la vida, el banco vulnerable de propósito de IBM donde ha practicado media industria. Ojo, si ese banco existiera de verdad hubiera quebrado antes de 2010.
La colmena: cuatro Hunters y un escéptico
El motor se llama Nexus, y más que un escáner es una colmena. Varios agentes especializados comparten una memoria común y trabajan el objetivo a la vez. Hay agentes «Hunter» que mapean la superficie, lanzan hipótesis y prueban caminos. Y hay un agente escéptico que hace justo lo contrario de lo que esperarías de una IA: desconfiar. Su regla aparece en pantalla, en inglés pero clarísima: nada se cree sin replay. Un hallazgo no es un hallazgo hasta que otro agente, otro distinto, lo ha reproducido desde cero.
Para la demo se usa demo.testfire.net, que es el Altoro Mutual de toda la vida, el banco vulnerable de propósito de IBM donde ha practicado media industria. Ojo, si ese banco existiera de verdad hubiera quebrado antes de 2010.
La colmena: cuatro Hunters y un escéptico
El motor se llama Nexus, y más que un escáner es una colmena. Varios agentes especializados comparten una memoria común y trabajan el objetivo a la vez. Hay agentes «Hunter» que mapean la superficie, lanzan hipótesis y prueban caminos. Y hay un agente escéptico que hace justo lo contrario de lo que esperarías de una IA: desconfiar. Su regla aparece en pantalla, en inglés pero clarísima: nada se cree sin replay. Un hallazgo no es un hallazgo hasta que otro agente, otro distinto, lo ha reproducido desde cero.
En la demo en vivo se ve a uno de los Hunters «guardando material» (credenciales, tokens, sesiones) en la memoria compartida y proponiendo una capacidad conseguida en el login: bypass de la autenticación por SQL injection, entrando como admin. Otro propone una SQLi en el login que vuelca las cuentas. Y todo, absolutamente todo, aparece como no confirmado hasta que llega la reproducción. Cuando llega, pasa al tablero de evidencias. Esa disciplina de demostrarlo dos veces es la que llevo veinte años exigiendo a los informes de pentest.
Todo queda registrado, y esto importa para quien haya discutido alguna vez con un proveedor: vista del navegador en vivo, war room con la actividad de los agentes, grafo de ataque con los caminos confirmados y los descartados (que también valen mucho), grabación de la sesión y, al final, informe en PDF y en JSON con la parte ejecutiva, la cadena completa, los pasos de reproducción y las capturas.
Todo queda registrado, y esto importa para quien haya discutido alguna vez con un proveedor: vista del navegador en vivo, war room con la actividad de los agentes, grafo de ataque con los caminos confirmados y los descartados (que también valen mucho), grabación de la sesión y, al final, informe en PDF y en JSON con la parte ejecutiva, la cadena completa, los pasos de reproducción y las capturas.
Y si no encuentran nada, no rellenan el informe con «posibles problemas». Llevamos décadas entregando informes con humo; esto va por otros derroteros.
Del bug al pull request, sin pasar por el ticket
La segunda pata conecta cada hallazgo con el código: rutas, flujos de datos, alcanzabilidad, la traza de taint desde el dato que mete el usuario hasta el sink. Y un detalle que a mí me parece menor y no lo es: cada hallazgo pasa por un veredicto de IA que intenta tirarlo abajo como falso positivo antes de que llegue a tu mesa. Si sobrevive, llega marcado como real. En la demo, un caso de libro de texto: un index.php que concatena lo que llega por GET directamente en la consulta. SQL injection, CWE-89, CVSS 9.8, crítica. Veredicto: se mantiene como real, confianza cien sobre cien.
Y luego llega la parte que, la plataforma de Plexicus hace de forma diferencial. Un módulo llamado Plexicus Remedium clona el repositorio, se prepara un entorno de trabajo y se pone a arreglar el bug. Y te abre el Pull Request.
- $sql = "SELECT * FROM usuarios WHERE id = $id"; // Vulnerable a SQL Injection- $result = $conn->query($sql);+ // Consulta preparada con parámetros para evitar SQL Injection+ $stmt = $conn->prepare("SELECT * FROM usuarios WHERE id = ?");+ $stmt->bind_param("i", $id);+ $stmt->execute();+ $result = $stmt->get_result();
Y no, la máquina no fusiona nada en producción por su cuenta. El PR lo revisa, lo prueba y lo aprueba tu equipo, que para eso cobra, y una ejecución posterior confirma que el bug demostrado ya no está. La IA hace el trabajo pesado; la responsabilidad se queda en los humanos, que son los responsables finales de gestionar la ciberseguridad de la empresa.
La plataforma trae además XBOM, un inventario unificado que junta SBOM, CBOM y AIBOM: qué componentes tiene tu software, qué criptografía usa (con el ojo puesto en la migración post-cuántica, que llega queramos o no) y qué modelos de IA tienes desplegados.
Tener un inventario de cuáles son, simplemente, los modelos de IA que se están usando para evitar el Shadow AI, o qué algoritmos y certificados cripográficos se usan en las empresas es una preocupación hoy en día para cualquier CISO.
La demo completa
Os dejo grabada una demo completa, de unos veintiún minutos, que enseña el dashboard con el pentesting en funcionamiento con el Enjambre de Agentes IA y termina con el Pull Request fusionado. Por si quieres saber qué se ve, y entenderlo bien, tenéis estos momentos minutados:
- Minuto 6:47. El SAST con IA buscando fallos de lógica de negocio, no palabras clave. Interesante, porque es lo que un SAST nunca ha sabido hacer.
- Minuto 9:35. CBOM y AIBOM, la cripto y los modelos. Lo post-cuántico ya está aquí.
- Minuto 12:42. El pentest arranca en un contenedor efímero.
- Minuto 13:15. Los agentes Hunter y el escéptico. Mi favorito.
- Minuto 14:07. Primera víctima: SQL injection con bypass del login.
- Minuto 15:57. Remediación automática y pull request.
- Minuto 19:07. Montando una automatización entera con IA, en directo.
Para terminar, me gustaría dejaros algunos mensajes. El primero es que con la IA Generativa se produce código más rápido de lo que se puede revisar. El segundo, es que se ha multiplicado el trabajo, ya que aparecen centenares de aplicaciones, repositorios, servicios cloud y dependencias, donde priorizar el esfuerzo sin contexto es imposible. Y el tercer mensaje es sobre la regulación, ya que el Cyber Resilience Act ya tiene fechas, con obligaciones de notificación desde el 11 de septiembre de 2026 y el grueso desde el 11 de diciembre de 2027. Saber qué riesgo se validó, quién actuó y qué cambio se revisó va a dejar de ser un lujo.
Figura 13: Únete a Plexicus.ai
Ahora estamos acelerando en Plexicus.ai, así que si quieres saber más de nuestra empresa, nuestras tecnologías, o nuestro futuro, contacta con nosotros. Estamos en una ronda de inversión privada para juntarnos con nuevos socios que quieran construir la plataforma de AI Swarm Pentest definitiva.
Saludos,
No hay comentarios:
Publicar un comentario