Microsoft Threat Intelligence propose une analyse approfondie d’attaques visant trois environnements liés à l’exploitation de l’intelligence artificielle : la passerelle LiteLLM, la plateforme RAGFlow de traitement des documents et de génération augmentée par récupération, ainsi que l’environnement Kestra d’orchestration des workflows. Malgré des vecteurs de compromission différents, les objectifs étaient presque toujours les mêmes : voler des clés d’authentification, installer des mécanismes d’accès persistant et accéder aux ressources informatiques pour les utiliser dans le minage de cryptomonnaies.
L’importance de ces trois cas tient au fait que les attaquants n’ont pas seulement considéré ces outils comme des applications distinctes, mais les ont ciblés en tant que points de contrôle regroupant des identifiants, des connexions avec les fournisseurs de modèles, des capacités d’exécution de commandes et un accès aux bases de données ou aux conteneurs. Selon Microsoft, cette concentration fait des passerelles d’IA ainsi que des plateformes de gestion et d’orchestration des cibles de grande valeur au sein des environnements d’entreprise.
Trois vecteurs de compromission, un même schéma de résultats
Dans le cas de LiteLLM, Microsoft estime avec un niveau de confiance élevé que l’accès initial a été obtenu en exploitant une interface exposée de la passerelle. L’article mentionne des vecteurs associés à des vulnérabilités publiques, notamment CVE-2026-42271, liée à l’exécution authentifiée de commandes dans les points de test LiteLLM MCP stdio, ainsi qu’un vecteur de recherche la reliant à CVE-2026-48710, une vulnérabilité permettant de contourner la validation de l’en-tête Host dans Starlette. Dans certaines configurations concernées, cette combinaison pourrait rendre l’exécution de commandes à distance possible sans identifiants valides.
Après la compromission, la charge malveillante a lu l’environnement du processus principal à l’intérieur du conteneur, notamment /proc/1/environ, à la recherche de clés de fournisseurs de modèles, de la clé principale LiteLLM, de chaînes de connexion à des bases de données, de mots de passe et de jetons. Des fichiers exécutables déguisés en services Linux ont ensuite été téléchargés, tandis que l’hôte, les ports et les processus étaient examinés et que le minage reposant sur XMRig ou RandomX était préparé. Une chaîne de connexion PostgreSQL a également été utilisée pour accéder aux tables LiteLLM susceptibles de contenir les paramètres des modèles, les clés des fournisseurs et les clés virtuelles émises par le proxy. Les mécanismes de persistance comprenaient la modification du fichier authorized_keys d’un compte de service, la modification de tâches cron, ainsi que l’utilisation de fichiers cachés et de noms de services déguisés.
Dans le cas de RAGFlow, l’activité observée était principalement axée sur l’interception des identifiants des modèles de langage ajoutés ou modifiés par les locataires. Microsoft a d’abord détecté un comportement semblable à des requêtes SSRF, puis l’exécution de commandes dans le contexte d’un service Flask et la modification du chemin de démarrage de l’application afin de charger un hook caché. Ce hook capturait le type de fournisseur, le nom du modèle, la valeur de la clé API et les données du point de terminaison, puis les envoyait vers l’extérieur. L’article précise que Microsoft n’identifie pas avec un niveau de confiance élevé la vulnérabilité à l’origine de l’exécution ; il cite CVE-2026-45312, CVE-2026-28797, CVE-2026-24770 et CVE-2025-68700 comme contexte technique potentiel, et non comme cause confirmée de ce cas.
Dans Kestra, Microsoft estime avec un niveau de confiance élevé que l’exploitation était liée à la vulnérabilité critique CVE-2026-49869, qui pourrait permettre de contourner l’authentification, de définir un workflow malveillant utilisant le Process runner, puis d’exécuter des commandes shell sur le worker. Ce vecteur a été utilisé pour accéder à un socket Docker, examiner l’environnement des conteneurs, déployer un mineur et exécuter des opérations destinées à dissimuler les fichiers. Les workflows ont ensuite servi à récupérer des scripts à distance et à les exécuter directement, puis à stocker les sorties chiffrées via l’interface de valeurs clés propre à Kestra.
Qu’est-ce qui change concrètement pour les équipes de défense ?
La conclusion la plus importante est que l’évaluation des risques doit partir de la fonction de l’environnement d’IA au sein de l’entreprise. La passerelle peut constituer un dépôt de clés de fournisseurs de modèles et une base de données de clés virtuelles, tandis qu’une plateforme RAG peut contenir les paramètres des locataires et qu’un moteur de workflow peut disposer de l’autorisation d’exécuter des commandes et d’interagir avec des services externes. Il ne suffit donc pas d’appliquer des indicateurs de détection propres à chaque produit indépendamment des autres.
Microsoft recommande de traiter les passerelles d’IA comme des dépôts de secrets de premier niveau, de mettre à jour LiteLLM et les outils similaires, d’imposer l’authentification sur les API et les interfaces d’administration, ainsi que de restreindre les ports d’administration et de ne pas les exposer directement à Internet. L’entreprise recommande également d’utiliser des clés virtuelles distinctes pour chaque équipe avec des limites de dépenses, de stocker les clés des fournisseurs dans un gestionnaire de secrets administré plutôt que dans les variables d’environnement du processus, et de faire tourner les clés susceptibles d’avoir été exposées.
Les autres mesures comprennent l’application du principe du moindre privilège à la passerelle et à la base de données, le placement de la base de données derrière un point de terminaison privé et un pare-feu restrictif, ainsi que l’imposition de règles de sortie réseau qui refusent les connexions par défaut et n’autorisent que les points de terminaison requis. Il convient de surveiller l’accès à /proc/1/environ, le lancement de shell, de Python ou d’outils de téléchargement par un processus de passerelle, la modification de cron ou de fichiers SSH, l’utilisation d’un socket Docker et l’exécution depuis des chemins temporaires accessibles en écriture.
Limites des conclusions et questions d’audit
Les trois cas ne prouvent pas que tous les déploiements de LiteLLM, RAGFlow ou Kestra sont exposés de la même manière. Microsoft distingue également clairement les vulnérabilités confirmées dans certains vecteurs des vulnérabilités potentielles dans le cas de RAGFlow. De même, la présence, dans certaines charges malveillantes, de caractéristiques suggérant l’utilisation d’outils d’assistance ou génératifs ne constitue pas une preuve de leur origine ni de l’identité de leurs développeurs. Ces résultats doivent donc servir à élaborer des hypothèses de détection et à examiner les configurations, et non à attribuer une attaque à un acteur précis.
Microsoft fournit des requêtes Advanced hunting pour détecter des séquences comportementales, telles que le lancement d’interpréteurs ou d’outils de téléchargement par la passerelle, la lecture des variables d’environnement du processus principal, l’accès aux tables LiteLLM, les tentatives de chargement d’un module MSR avec l’écriture activée, ainsi que la modification de clés SSH ou de tâches cron. La valeur pratique de ces requêtes apparaît lorsqu’elles sont reliées au sein d’une même chronologie : un processus shell isolé peut relever de l’administration, mais son association avec la lecture de secrets, une connexion externe et l’exécution d’un fichier depuis un chemin temporaire augmente fortement le niveau de suspicion.