Microsoft Threat Intelligence ofrece un análisis amplio de ataques dirigidos contra tres entornos relacionados con la operación de la inteligencia artificial: la puerta de enlace LiteLLM, la plataforma RAGFlow para el procesamiento de documentos y la generación aumentada mediante recuperación, y el entorno Kestra para la orquestación de flujos de trabajo. Aunque las rutas de intrusión fueron diferentes, los objetivos se repitieron prácticamente: robar claves de autenticación, instalar mecanismos de acceso persistente y acceder a recursos informáticos para utilizarlos en la minería de criptomonedas.
La importancia de los tres casos reside en que los atacantes no trataron estas herramientas únicamente como aplicaciones independientes, sino que las atacaron como puntos de control donde se concentran credenciales, conexiones con proveedores de modelos, capacidades de ejecución de comandos y acceso a bases de datos o contenedores. Según Microsoft, este enfoque convierte a las puertas de enlace de IA y a las plataformas de administración y orquestación en objetivos de alto valor dentro de los entornos empresariales.
Tres rutas de intrusión y un mismo patrón de resultados
En el caso de LiteLLM, Microsoft considera con un alto grado de confianza que el acceso inicial se produjo mediante la explotación de una interfaz expuesta de la puerta de enlace. El material señala rutas asociadas a vulnerabilidades públicas, entre ellas CVE-2026-42271, relacionada con la ejecución autenticada de comandos en los puntos de prueba de LiteLLM MCP stdio, y una ruta de investigación que la vincula con CVE-2026-48710, una vulnerabilidad para eludir la validación de la cabecera de host en Starlette. Esta combinación podría, en configuraciones afectadas, permitir la ejecución remota de comandos sin credenciales válidas.
Tras la intrusión, la carga maliciosa leyó el entorno del proceso principal dentro del contenedor, incluido /proc/1/environ, en busca de claves de proveedores de modelos, la clave maestra de LiteLLM, cadenas de conexión de bases de datos, contraseñas y tokens. Después se descargaron archivos ejecutables disfrazados de servicios de Linux, se analizaron el host, los puertos y los procesos, y se preparó una operación de minería basada en XMRig o RandomX. También se utilizó la cadena de conexión de PostgreSQL para acceder a las tablas de LiteLLM, que podían contener configuraciones de modelos, claves de proveedores y claves virtuales emitidas por el proxy. Los mecanismos de persistencia incluyeron la modificación del archivo authorized_keys de una cuenta de servicio, el cambio de tareas cron y el uso de archivos ocultos y nombres de servicios encubiertos.
En cuanto a RAGFlow, la actividad observada se centró en interceptar las credenciales de los modelos de lenguaje que los inquilinos añadían o modificaban. Microsoft detectó primero un comportamiento similar a solicitudes SSRF y, posteriormente, la ejecución de comandos dentro del contexto del servicio Flask y la modificación de la ruta de inicio de la aplicación para cargar un gancho oculto. El gancho capturaba el tipo de proveedor, el nombre del modelo, el material de la clave de API y los datos del punto de conexión, y los enviaba al exterior. El material confirma que Microsoft no identifica con un alto grado de confianza la vulnerabilidad que provocó la ejecución; menciona CVE-2026-45312, CVE-2026-28797, CVE-2026-24770 y CVE-2025-68700 como posible contexto técnico, no como causa confirmada de este caso.
En Kestra, Microsoft considera con un alto grado de confianza que la explotación estuvo relacionada con la vulnerabilidad crítica CVE-2026-49869, que podría permitir eludir la autenticación, definir un flujo de trabajo malicioso que utilizara Process runner y, posteriormente, ejecutar comandos de shell en el trabajador. Esta ruta se utilizó para acceder a un socket de Docker, analizar el entorno de los contenedores, desplegar un minero y ejecutar operaciones para ocultar archivos. Más tarde, los flujos de trabajo también se utilizaron para obtener scripts remotos y ejecutarlos directamente, y después almacenar las salidas cifradas mediante la interfaz de valores clave propia de Kestra.
¿Qué cambia en la práctica para los equipos de defensa?
La conclusión más importante es que la evaluación de riesgos debe partir de la función que desempeña el entorno de IA dentro de la organización. La puerta de enlace puede ser un almacén de claves de proveedores de modelos y una base de datos de claves virtuales, mientras que una plataforma RAG puede contener configuraciones de los inquilinos y un motor de flujos de trabajo puede tener permisos para ejecutar comandos e interactuar con servicios externos. Por ello, no basta con aplicar indicadores de detección específicos de cada producto de forma aislada.
Microsoft recomienda tratar las puertas de enlace de IA como almacenes de secretos de máxima importancia, actualizar LiteLLM y herramientas similares, exigir autenticación en las interfaces de API y administración, restringir los puertos de administración y no exponerlos directamente a Internet. También recomienda utilizar claves virtuales independientes para cada equipo con límites de gasto, almacenar las claves de los proveedores en un almacén de secretos administrado en lugar de en variables de entorno del proceso y rotar las claves que pudieran haberse expuesto.
Otros controles incluyen aplicar el principio de mínimo privilegio a la puerta de enlace y a la base de datos, colocar la base de datos detrás de un punto de conexión privado y un cortafuegos restringido, y aplicar reglas de salida de red que denieguen las conexiones de forma predeterminada y permitan únicamente los puntos de conexión necesarios. Debe supervisarse el acceso a /proc/1/environ, la ejecución de shell, Python o herramientas de descarga desde un proceso de la puerta de enlace, la modificación de cron o de archivos SSH, el uso de un socket de Docker y la ejecución desde rutas temporales con permisos de escritura.
Límites de las conclusiones y preguntas de revisión
Los tres casos no demuestran que todas las implementaciones de LiteLLM, RAGFlow o Kestra estén expuestas de la misma manera, y Microsoft distingue claramente entre las vulnerabilidades confirmadas en algunas rutas y las vulnerabilidades posibles en el caso de RAGFlow. Asimismo, la presencia de características en algunas cargas que sugieren el uso de herramientas auxiliares o generativas no constituye una prueba de su origen ni de la identidad de sus desarrolladores. Por tanto, estos resultados deben utilizarse para formular hipótesis de detección y revisar configuraciones, no para atribuir un ataque a un actor específico.
Microsoft proporciona consultas de Advanced hunting para detectar cadenas de comportamiento, como la ejecución por parte de la puerta de enlace de intérpretes o herramientas de descarga, la lectura de variables del entorno del proceso principal, el acceso a tablas de LiteLLM, los intentos de cargar un módulo MSR con la escritura habilitada y la modificación de claves SSH o cron. El valor práctico de estas consultas aparece al relacionarlas en una única línea temporal: un proceso de shell aislado puede ser administrativo, pero su combinación con la lectura de secretos, una conexión externa y la ejecución de un archivo desde una ruta temporal eleva considerablemente el nivel de sospecha.