Selon Microsoft Threat Intelligence, des agents utilisant le cadre d’IA ARTEX ont recherché des identifiants exposés dans des dépôts GitHub publics avant d’employer des identifiants d’application valides pour accéder à des environnements cloud. Microsoft situe ces recherches à partir d’août 2026 et rapporte un cas où cinq minutes ont suffi pour passer de l’analyse de dépôts à l’exfiltration de données depuis Azure Key Vault. Le rapport de Microsoft a été publié le 5 novembre.
Un secret publié doit être révoqué ou renouvelé : supprimer le fichier ne rend pas l’identifiant inutilisable.
Ce que Microsoft rapporte sur ARTEX
Les agents auraient combiné des noms d’organisations avec des termes liés aux secrets, au cloud et aux fournisseurs d’IA pour chercher des identifiants dans les dépôts publics. Microsoft décrit ARTEX comme un cadre capable d’analyser les résultats et d’enchaîner des actions à partir des identifiants trouvés. Le délai de cinq minutes concerne un seul cas observé par Microsoft, pas une durée générale.
Microsoft a également rapporté des connexions liées à l’activité à partir du 28 octobre 2026, via des principaux de service, c’est-à-dire des identités utilisées par des applications pour s’authentifier. L’activité concernait des dizaines d’applications associées et plusieurs locataires. Dans certains cas, une identité d’application multitenant compromise chez son fournisseur aurait permis des connexions à des locataires en aval.
Des identifiants aux services cloud
Les ressources et données concernées dans le récit de Microsoft comprennent des clés de comptes de stockage, des paramètres et identifiants d’App Service, des chaînes de connexion, des connexions et entrepôts de données d’IA ou d’apprentissage automatique, ainsi que des identifiants utilisateur d’Azure Kubernetes Service.
Microsoft rapporte aussi des accès à Azure Key Vault, aux comptes de stockage, aux services Azure AI, à Azure DevOps, à SharePoint et à OneDrive. Dans certains environnements, des applications compromises auraient téléchargé des fichiers SharePoint et OneDrive ou accédé à des éléments de boîtes aux lettres. Des requêtes Microsoft Graph recherchaient notamment du contenu pertinent, tandis que des sessions authentifiées sur Azure DevOps servaient à rechercher des secrets.
Pour replacer ce cas dans le débat plus large sur les systèmes capables d’agir avec des outils et des autorisations, nous avions aussi consacré un article aux risques des agents IA autonomes.
Trois reprises distinctes d’API Azure
Microsoft décrit trois séquences séparées : chaque requête initiale a renvoyé une erreur HTTP 400, puis une requête modifiée a obtenu une réponse HTTP 200. Les délais indiqués correspondent à chaque séquence, pas à une attente cumulée.
| Requête | Délai approximatif avant la reprise | Résultat initial | Résultat après modification |
| Métadonnées d’Azure Key Vault | 28 secondes | HTTP 400 | HTTP 200 |
| Règles de pare-feu Azure SQL | 60 secondes | HTTP 400 | HTTP 200 |
| Requête Application Insights | 80 secondes | HTTP 400 | HTTP 200 |
Pour Key Vault, Microsoft précise que la première requête utilisait une version d’API du plan de données sur un point de terminaison ARM du plan de contrôle ; la reprise a utilisé la version ARM 2023-07-01.
Les mesures de défense recommandées par Microsoft
Si un identifiant apparaît publiquement, Microsoft recommande de le révoquer ou de le renouveler immédiatement, puis d’examiner son utilisation passée. Supprimer le fichier exposé ne suffit pas à invalider l’identifiant. Les équipes doivent aussi rechercher d’éventuels secrets, certificats ou identifiants fédérés ajoutés aux applications, renouveler les secrets des coffres Key Vault accessibles aux applications concernées et limiter les droits des principaux de service au strict nécessaire.
Pour repérer les accès suspects, Microsoft recommande de consulter les journaux de connexion des principaux de service, Azure Activity, les journaux de diagnostic de Key Vault et du stockage, ainsi que les journaux d’audit Entra, Azure DevOps et Microsoft 365. Parmi les comportements à examiner : une même adresse IP qui s’authentifie auprès d’au moins trois principaux de service avec des succès et des échecs, ou une application qui demande rapidement des jetons pour plusieurs services cloud. Les codes d’erreur AADSTS7000215 et AADSTS7000222 peuvent aussi signaler qu’un tiers détient un identifiant d’application ; ils ne suffisent pas, à eux seuls, à établir une activité malveillante. Microsoft souligne que les adresses IP et les empreintes de navigateur peuvent changer.
La règle d’accès conditionnel que Microsoft propose pour bloquer l’adresse 199.19.77[.]84/32 nécessite Workload ID Premium et ne concerne que les applications à locataire unique enregistrées dans le locataire. Microsoft recommande de bloquer cette adresse précise plutôt que tout son système autonome. Après la suppression d’un identifiant, les jetons déjà émis restent valides jusqu’à leur expiration.
Un cas distinct : les paramètres locaux de Claude Code
Dans une vidéo en anglais publiée le 7 novembre, SavvyNik relate un rapport distinct d’Apiiro sur Claude Code. Selon cette présentation, l’option « Don’t Ask Again » pouvait enregistrer dans des fichiers de configuration JSON locaux des commandes contenant des mots de passe ou des clés d’API ; la publication de ces fichiers dans des dépôts GitHub publics exposait ensuite ces secrets.
SavvyNik attribue à Apiiro la découverte de plus de 1 100 copies publiques de ces fichiers contenant au moins un secret, et de 2 539 secrets réels dans environ 2 000 dépôts publics. Ce mécanisme de publication accidentelle d’une configuration locale est différent des recherches de secrets déjà exposés décrites par Microsoft.
