Durante los últimos años nos hemos acostumbrado a una narrativa bastante cómoda: la inteligencia artificial como asistente. Un copiloto dócil, más o menos brillante, que te sugiere comandos, te completa payloads, te escribe un exploit a medias y, en el peor de los casos, te obliga a corregirle como si fuera un junior con prisa. Nada especialmente disruptivo si llevas tiempo en esto. Más productividad, sí. Más velocidad, también. Pero siempre con un humano al volante, tomando decisiones, descartando caminos absurdos y, sobre todo, asumiendo que el criterio sigue siendo un recurso escaso y humano. Eso ha empezado a cambiar. Y no de forma gradual, precisamente.
Lo que estamos viendo en los últimos meses no es solo una mejora en los modelos, sino un cambio de paradigma bastante más incómodo: el paso de copilotos a agentes cada vez más autónomos. Y no agentes en el sentido marketiniano de “hacen varias cosas encadenadas”, sino agentes que reciben un objetivo, tienen acceso a herramientas reales y se les permite iterar sin supervisión constante. Es decir, sistemas que no solo responden, sino que actúan, observan resultados, recalculan y vuelven a actuar. Si esto lo trasladas al mundo ofensivo, la conclusión es bastante obvia: ya no estás automatizando tareas, estás delegando comportamiento.
¿Y hasta dónde pueden llegar estos agentes a la hora de "hackear" ellos solos distintos entornos? Pues con proyectos como BoxPwnr, creado por Francisco Oca, empezamos a ver resultados cada vez más concluyentes. Empezó como un experimento divertido para ver hasta dónde pueden llegar los LLMs resolviendo máquinas HackTheBox por sí solos. Y a día de hoy se ha extendido también a otras plataformas:
| Platform | Solved | Completion | Traces |
|---|---|---|---|
| HTB Starting Point | 25/25 |  | 770 |
| HTB Labs | 268/525 |  | 946 |
| HTB Challenges | 324/818 |  | 735 |
| PortSwigger Labs | 163/270 |  | 377 |
| XBOW Validation Benchmarks | 101/104 |  | 526 |
| Cybench CTF Challenges | 40/40 | | 1222 |
| picoCTF Challenges | 430/509 |  | 1198 |
| TryHackMe Rooms | 147/477 |  | 873 |
| HackBench Benchmarks | 11/16 |  | 34 |
| LevelUpCTF Challenges | 50/255 |  | 166 |
| BSidesSF CTF 2026 | 46/54 |  | 96 |
| Cloud Village CTF 2026 | 12/21 |  | 39 |
| Neurogrid CTF: The ultimate AI security showdown | 17/36 |  | 197 |
Como veis una de las cosas más interesantes de BoxPwnr es que no se queda en el “mira qué guay”. Se ha utilizado como banco de pruebas contra plataformas conocidas —especialmente Hack The Box y la Web Security Academy de PortSwigger— para medir algo tangible: cuántos retos es capaz de resolver, cuánto tarda, cuántas iteraciones necesita y cuánto cuesta en términos de uso de API.
Los números, sin ser apocalípticos, son lo bastante buenos como para incomodar. En escenarios relativamente guiados, como labs de iniciación o máquinas con vectores claros, las tasas de éxito son sorprendentemente altas. En entornos más abiertos o con cadenas de explotación menos evidentes, el rendimiento cae —y cae bastante—, pero no a cero. Siempre hay ejecuciones en las que, tras suficientes iteraciones, el modelo acaba conectando los puntos.
Lo realmente relevante no es el porcentaje exacto, sino la tendencia: conforme mejoras el modelo, ajustas prompts y refinas estrategias, el rendimiento sube. Y lo hace sin necesidad de “enseñar hacking” de forma explícita en cada paso. Es decir, estamos viendo un sistema que, con acceso a herramientas estándar y suficiente contexto, es capaz de aproximarse al comportamiento de un pentester… aunque sea a base de probar más cosas, más rápido y con menos prejuicios.
Dicho de otra forma: no es especialmente listo, pero es incansable. Y eso, en ofensiva, compensa más de lo que nos gustaría admitir.
¿Cómo funciona realmente BosPwnr?
BoxPwnr utiliza diferentes modelos LLM para resolver de forma autónoma las máquinas mediante un proceso iterativo:
1. Entorno: Todos los comandos se ejecutan en un contenedor Docker con Kali Linux.
- El contenedor se crea automáticamente en la primera ejecución (tarda aproximadamente 10 minutos).
- La conexión VPN se establece automáticamente mediante la opción `--vpn`.
2. Bucle de ejecución:
- El LLM recibe una solicitud detallada del sistema que define su tarea y restricciones.
- El LLM sugiere el siguiente comando basándose en los resultados anteriores.
- El comando se ejecuta en el contenedor Docker.
- El resultado se envía al LLM para su análisis.
- El proceso se repite hasta que se encuentra la opción o el LLM necesita ayuda.
3. Automatización de comandos:
- El LLM recibe instrucciones para proporcionar comandos totalmente automatizados sin interacción manual.
- El LLM debe incluir tiempos de espera adecuados y gestionar los retrasos del servicio en los comandos.
- El LLM debe programar todas las interacciones con el servicio (telnet, ssh, etc.) para que no sean interactivas.
4. Resultados:
- La conversación y los comandos se guardan para su análisis.
- Se genera un resumen cuando se encuentra la opción.
- Estadísticas de uso. (tokens, costo) se van loggeando
Un ejemplo inicial
uv y modelos open sin siquiera configurar credenciales externas.Un ejemplo muy básico es tirar contra la máquina inicial Meow de Hack The Box. Básica, sí. Pero para empezar teniendo una superficie simple, vector claro y pocas decisiones donde perderse. El comando de arranque es tal cual:
Sin API keys, sin historias. Y aquí ya hay un matiz importante: el modelo no es especialmente potente. Lo que estás probando no es “la mejor IA posible”, sino si el enfoque funciona incluso con algo relativamente limitado. A partir de aquí, el comportamiento es bastante revelador.
La primera iteración no suele ser brillante. A veces intenta resolver “meow” como hostname, otras lanza directamente un escaneo sin demasiada fineza. Pero tras uno o dos tropiezos iniciales, acaba cayendo en lo obvio:
Resultado:
Y aquí es donde notas la diferencia entre un script tonto y algo con contexto. Porque no se queda en el scan. El modelo “reconoce” que el servicio Telnet puede ser interesante y la siguiente acción suele ser directa: telnet meow.htb
Y aquí pasan varias cosas dependiendo de la ejecución. En algunas, el modelo prueba usuarios genéricos. En otras —y esto es lo interesante— prueba directamente: login: root
Sin password. Y entra.
Una vez dentro, el comportamiento vuelve a ser caótico. Enumera, repite comandos, duda… hasta que en algún momento hace lo obvio: cat /root/flag.txt
Y ahí está. No hay magia. Pero tampoco hay humano.
Y ahora, lo incómodo
Después de ver algo así, es tentador quedarse con la parte tranquilizadora: que comete errores, que no siempre entiende lo que hace, que necesita muchas iteraciones y bastante contexto para acertar. Todo eso es cierto. Pero también lo es esto: hace un año, esto no funcionaba así. Y dentro de un año, probablemente funcionará bastante mejor.
BoxPwnr no es el fin del pentester, ni mucho menos. Pero sí es un aviso bastante claro de hacia dónde se está moviendo esto. Porque cuando combinas modelos cada vez más capaces con acceso a herramientas reales y bucles de decisión autónomos, lo que obtienes no es un asistente más listo, sino algo cualitativamente distinto.
Algo que no solo responde a tus comandos.
Algo que empieza a tener los suyos propios.
Comentarios
Publicar un comentario