Claves de Anthropic, OpenAI y Gemini se filtraron sin que nadie lo notara; hackers acceden a la infraestructura de IA de las empresas

Los servicios de IA cada vez con más frecuencia no son solo una herramienta de trabajo, sino un punto de entrada conveniente a la infraestructura interna de las empresas. Especialistas de Microsoft detectaron ataques reales contra LiteLLM, RAGFlow y Kestra, donde los atacantes robaban claves de modelos de IA, accedían a bases de datos y contenedores, se afianzaban en servidores y ejecutaban mineros de criptomonedas.

Las tres plataformas realizan tareas distintas, pero ocupan una posición especialmente ventajosa para los atacantes. LiteLLM actúa como pasarela entre aplicaciones y proveedores de grandes modelos de lenguaje, RAGFlow procesa documentos y organiza la generación con búsqueda en datos externos, y Kestra ejecuta flujos de trabajo automatizados. Sistemas de este tipo a menudo tienen acceso simultáneo a claves API, bases de datos, servicios internos, configuración de contenedores y recursos de cómputo. Si se compromete un componente, eso abre muchas más posibilidades que el ataque a una aplicación web común.

La cadena de ataque más compleja se detectó en LiteLLM. Microsoft considera con alta confianza que los atacantes entraron a través de una pasarela expuesta a Internet. Una vía posible está relacionada con la vulnerabilidad CVE-2026-42271 (8,8), que permitía a un usuario autenticado ejecutar comandos a través de interfaces de prueba del Model Context Protocol (MCP), y la vulnerabilidad CVE-2026-48710 (6,5) en Starlette. En determinadas configuraciones, la combinación de problemas permitía ejecutar código sin credenciales válidas. CVE-2026-42271 (8,8) afectó a LiteLLM desde la versión 1.74.2 hasta la 1.83.7, donde los desarrolladores cerraron el fallo.

Tras penetrar en el sistema, los atacantes buscaron primero secretos. En contenedores donde LiteLLM funciona como proceso con identificador PID 1, el código malicioso leía el archivo /proc/1/environ y buscaba valores que contuvieran palabras como master, API key, token y password. Allí podían estar las claves de proveedores de modelos de IA, la clave maestra de LiteLLM, la dirección de la base de datos, contraseñas del interfaz y otros parámetros sensibles. Los datos recopilados se enviaban hacia el exterior por varios medios mediante Python, curl y wget, de modo que la caída de una herramienta no interrumpiera el robo.

Luego los atacantes cargaron archivos ELF ejecutables y camuflaron procesos como servicios normales del sistema Linux. Los programas maliciosos verificaban privilegios, puertos abiertos, mineros en ejecución y herramientas de acceso remoto. Después instalaron XMRig o componentes similares para la minería de criptomonedas, configuraron la CPU para el algoritmo RandomX y eliminaron mineros competidores ya presentes en el servidor.

La cadena de conexión robada a PostgreSQL permitió pasar de la toma del contenedor a los datos de LiteLLM. En uno de los casos la base estaba en Azure Database for PostgreSQL. Los atacantes se conectaron y exportaron tablas con configuraciones de modelos y claves virtuales de proxy. Esas entradas pueden contener direcciones de proveedores de modelos, claves API y parámetros de enrutamiento de solicitudes. Para afianzarse en el sistema, los atacantes añadían una clave SSH en authorized_keys, modificaban tareas cron, ocultaban archivos en directorios temporales y establecían el atributo inmutable de Linux en archivos maliciosos.

En RAGFlow el escenario fue distinto. Primero Microsoft observó acciones parecidas a reconocimiento mediante Server-Side Request Forgery (SSRF), cuando la aplicación realiza solicitudes a una dirección definida por el atacante. Días después, en el mismo contexto, apareció ejecución de código. Microsoft no pudo identificar una vulnerabilidad concreta, por lo que no vincula el incidente directamente con ningún fallo conocido de RAGFlow.

Como posible contexto técnico, los especialistas enumeraron varios problemas divulgados anteriormente. Entre ellos la inyección de plantillas del lado del servidor CVE-2026-45312 (9,9) en el generador de consultas, una vulnerabilidad similar CVE-2026-28797 (8,7) en componentes Agent, el fallo de bypass de directorios CVE-2026-24770 (9,8) en MinerU Parser, así como CVE-2025-68700 (9,4) y CVE-2025-69286 (9,8). La presencia de estas vulnerabilidades por sí sola no demuestra que los atacantes usaran alguna de ellas en el caso detectado.

Tras acceder a RAGFlow, los atacantes crearon un módulo Python oculto dentro del directorio de la aplicación y modificaron el mecanismo de arranque para que el código malicioso se cargara junto con el servicio. El objetivo principal no fue tanto los recursos de cómputo como las credenciales nuevas. El módulo malicioso interceptaba las configuraciones cuando el usuario añadía o cambiaba una conexión a un modelo de lenguaje. En manos de los atacantes quedaban el nombre del proveedor, el modelo, la clave API y la dirección del servicio. Microsoft observó este mecanismo para credenciales de OpenAI, Azure, Anthropic y Gemini.

La información interceptada se enviaba discretamente a un servidor externo, y el código malicioso suprimía errores de transmisión para que RAGFlow siguiera funcionando aparentemente con normalidad. Microsoft no detectó mineros ni una shell inversa interactiva en este incidente. También se escribió una clave SSH en el contenedor, aunque si sobreviviría a un reinicio dependía de la configuración del sistema de archivos, de los privilegios del contenedor y de la configuración del límite entre el contenedor y el host.

En el caso de Kestra, los especialistas relacionan con alta confianza el acceso inicial con la crítica CVE-2026-49869 (10,0). Un fallo en el filtro de autenticación permitía a un usuario remoto sin contraseña crear y ejecutar sus propios flujos de trabajo. Dado que Kestra puede ejecutar por defecto scripts Shell, Python y otros, la vulnerabilidad se convertía en ejecución remota de comandos. El problema afectó a versiones hasta la 1.3.20 inclusive; los desarrolladores lo corrigieron en 1.0.45 y 1.3.21.

Tras tomar control mediante Kestra, los atacantes accedieron al socket de Docker y empezaron a revisar parámetros de otros contenedores. Las variables de entorno con frecuencia contienen claves de servicios de nube, contraseñas de bases de datos, tokens API y direcciones internas. A continuación subieron XMRig, renombraron el binario, iniciaron la minería de Monero y ajustaron RandomX para aumentar el rendimiento del procesador. En otra parte del ataque, un script remoto recopilaba información del sistema, codificaba el resultado y almacenaba los datos mediante el propio almacén de claves y valores de Kestra.

Microsoft también notó una estructura inusualmente ordenada en algunos programas maliciosos. El código contenía importaciones organizadas, manejo de excepciones, métodos alternativos para cargar dependencias, timeouts y comentarios explicativos. Esas señales pueden aparecer en programas creados o mejorados con ayuda de IA. Los especialistas subrayan que estas características no bastan para probar el uso de un modelo generativo ni para atribuir la autoría del código malicioso.

Los tres incidentes muestran un cambio general en los intereses de los atacantes. Las pasarelas y plataformas para IA se van convirtiendo en una nueva capa de control de la infraestructura corporativa. Un servicio de este tipo puede almacenar simultáneamente claves de modelos, conectarse a una base de datos, ejecutar scripts y gestionar contenedores. Por eso ya no es necesario atacar directamente el modelo de IA: resulta mucho más rentable capturar el componente por el que pasan solicitudes, secretos y comandos.

Microsoft aconseja no publicar interfaces administrativas de esos sistemas directamente en Internet, instalar actualizaciones con regularidad, separar las claves de usuario de las claves maestras de los proveedores de modelos y guardar los secretos en almacenes especializados en lugar de en variables de entorno. La compañía también recomienda limitar los permisos de cuentas de servicio y de bases de datos, cerrar el tráfico saliente innecesario y vigilar de cerca los casos en que el proceso de la pasarela de IA lance de forma súbita bash, Python, curl o wget. Hay que prestar especial atención cuando alguien lea /proc/1/environ, acceda al socket de Docker, ejecute programas desde /tmp, cambie claves SSH y cron, o haya conexiones inesperadas con servidores de pools de minería.

Según Microsoft, ahora es necesario proteger la infraestructura de IA al mismo nivel que otras sistemas críticos de control de la empresa. Cuantas más facultades adquieren las pasarelas, las plataformas de búsqueda y los sistemas de automatización, más atractivo resulta el punto único por el que un atacante puede robar secretos, acceder a datos y convertir los servidores de la empresa en recursos de cómputo propios.