Hack The Box: cómo MCP Inspector convierte las herramientas de IA en un nuevo punto de ataque

La máquina Kobold de Hack The Box Season 10 deja clara una cosa: los nuevos riesgos en torno a la IA no aparecen solo en los modelos, sino también en las herramientas con las que los desarrolladores los operan. En este análisis, el punto de partida del ataque es MCP Inspector, una utilidad de desarrollo para servidores de IA. Después, la cadena sigue un guion conocido en seguridad de infraestructuras: ejecución de código, lectura de archivos locales dentro del contenedor, reutilización de credenciales y escalada de privilegios mediante Docker, hasta tomar el control total del sistema.

Kobold se presenta como una máquina de nivel Easy, pero su valor no está en la dificultad de la explotación, sino en lo realista de la combinación de vulnerabilidades. El autor muestra cómo un servicio de depuración e inspección de componentes MCP puede convertirse de pronto en un perímetro externo. Para los equipos que montan un stack de IA con servidores, conectores y herramientas auxiliares, es un recordatorio incómodo: todo lo que se conecta al modelo y tiene acceso al entorno local pasa a formar parte, automáticamente, de la superficie de ataque. Y esos elementos suelen ser los peor protegidos, porque se consideran internos, temporales o «solo para desarrolladores».

La primera etapa de la cadena es la RCE a través de MCP Inspector. Este paso, por sí solo, cambia el panorama de amenazas: el atacante no necesita romper la aplicación principal si al lado hay una herramienta menos protegida y con capacidades ampliadas.

Tras lograr la ejecución de código dentro del contenedor, el atacante pasa a la LFI, es decir, a la lectura de archivos locales. En la práctica, es una de las fases más productivas de cualquier ataque a servicios en contenedores: configuraciones, variables de entorno, registros, claves, tokens de servicio y artefactos de compilación suelen estar en lugares predecibles. Aunque los secretos no se entreguen directamente, la filtración de la estructura de directorios, los nombres de servicios o las direcciones internas ya acelera el avance.

El siguiente punto clave es la reutilización de credenciales. En los proyectos de IA es un problema especialmente frecuente: los equipos levantan servicios experimentales a toda prisa, copian archivos .env, duplican contraseñas entre contenedores y dejan las mismas credenciales para distintos roles. En el análisis, es precisamente la reutilización de secretos lo que permite pasar del acceso local a componentes más sensibles del sistema y, después, aprovechar errores en la configuración de Docker para escalar privilegios.

El material muestra dos caminos independientes hasta el control total de la máquina, lo que subraya la idea central: si el atacante ya tiene código dentro del contenedor, el socket de Docker, las capabilities sobrantes, los montajes inseguros y un acceso demasiado amplio a los recursos del host convierten rápidamente el contenedor de barrera en un cómodo punto intermedio.

También resulta útil que el autor asocie el ataque con MITRE ATT&CK. Así, la toma paso a paso de la máquina se convierte en material aplicado para los defensores: se ve no solo la secuencia de acciones, sino también las clases de técnicas: ejecución inicial, discovery, collection, credential access, lateral movement y privilege escalation. Esto ayuda a los equipos blue team y DevSecOps a relacionar el escenario de laboratorio con registros, alertas y medidas de detección reales.

La tesis principal va mucho más allá de una sola máquina: el ecosistema MCP, que incluye inspectores, proxies, conectores y puentes locales hacia archivos, red y secretos, se está convirtiendo en una nueva superficie de ataque precisamente porque vive en la intersección de varias zonas de confianza.

¿Qué significa esto en la práctica?

A los equipos que construyen servicios de IA ya no les basta con proteger la API del modelo y la interfaz de usuario. Hay que sacar las herramientas de desarrollo del acceso público, activar la autenticación incluso en utilidades «internas», prohibir la reutilización de secretos, recortar los privilegios de los contenedores, revisar la configuración de Docker y registrar la actividad en torno a los componentes MCP con el mismo cuidado que en los servicios principales de producción.

Kobold funciona bien porque, sin teoría innecesaria, muestra que el próximo incidente grave en un stack de IA puede empezar no por el modelo, sino por una pequeña herramienta de servicio que nadie consideraba crítica.