Des agents d’IA autonomes ont dérobé des milliers d’identifiants en moins de six heures

Google Threat Intelligence Group a documenté une opération motivée par des considérations financières au cours de laquelle des agents d’IA autonomes ont dérobé des milliers d’identifiants appartenant à des tiers à partir d’une infrastructure cloud compromise, en moins de six heures.

Les attaquants ont combiné un chatbot de programmation doté d’IA avec un prompt de contrôle, des rôles d’agents spécialisés et des fichiers d’instructions Markdown réutilisables. Ensemble, ces composants formaient un cadre opérationnel capable d’analyser des systèmes, de collecter des identifiants, de résoudre des problèmes d’exécution et de faire tourner les adresses IP avec une supervision humaine limitée.

L’organisation touchée n’a pas été identifiée et la date de l’intrusion reste inconnue. GTIG n’a pas non plus communiqué la méthode d’accès initiale, le nombre exact d’identifiants compromis, le fournisseur cloud ni les indicateurs techniques associés à l’incident.

Malgré ces zones d’ombre, cette opération marque une évolution concrète dans la manière dont l’IA peut soutenir la cybercriminalité. Le système ne s’est pas contenté de rédiger des messages d’hameçonnage ou de produire des extraits de code isolés. Il a coordonné plusieurs étapes d’une intrusion active.

Un pipeline multi-agents remplace la gestion manuelle des attaques

Le cadre s’appuyait sur des instructions préconfigurées servant de plans d’attaque. Chaque agent pouvait se voir attribuer une fonction opérationnelle, tandis que le système dans son ensemble reliait ces fonctions au sein d’un pipeline automatisé.

Les capacités observées comprenaient notamment :

• L’analyse des vulnérabilités et des services exposés.
• La découverte et la collecte d’identifiants.
• Le dépannage en cas d’échec d’une tâche.
• La rotation des adresses IP pour maintenir l’activité ou compliquer la détection.
• La gestion du processus d’analyse en fonction de l’évolution de la situation.

Cette architecture réduisait la nécessité, pour un opérateur, de superviser manuellement chaque commande. GTIG estime que le cadre pouvait s’adapter en cours d’exécution et résoudre les problèmes en temps réel, permettant à l’attaquant de maintenir son rythme à travers les différentes étapes.

Le résultat était une exécution rapide. Des milliers d’identifiants appartenant à des tiers ont été compromis avant que les défenseurs aient réellement le temps d’enquêter, de contenir l’intrusion cloud et de révoquer les secrets exposés.

On ignore si le système sélectionnait de manière autonome les vulnérabilités, exécutait des exploits ou validait chacun des identifiants dérobés. Aucun identifiant CVE ni aucune version de logiciel touchée n’ont été communiqués. L’incident ne doit donc pas être considéré comme un avis classique sur une vulnérabilité ni comme la preuve qu’un produit d’IA particulier a été compromis.

Il montre en revanche comment des agents peuvent relier la reconnaissance, la collecte, le dépannage et l’évasion au sein d’un flux de travail continu. Les opérateurs humains continuent de définir les objectifs et de fournir les instructions, mais ils n’ont plus besoin de contrôler directement chaque action.

TeamPCP cible la chaîne d’approvisionnement logicielle et les secrets CI/CD

GTIG a également établi un lien entre un ensemble plus vaste de compromissions de la chaîne d’approvisionnement logicielle et TeamPCP, un groupe motivé par des considérations financières également suivi sous les noms Altered Spider et UNC6780. Ses cibles ont notamment inclus les écosystèmes PyPI, npm et Docker Hub.

La compromission de packages pour développeurs, d’images de conteneurs ou de comptes associés peut donner accès à des environnements où se trouvent régulièrement des secrets de grande valeur. Les systèmes de build peuvent contenir des tokens cloud, des identifiants de publication de packages, des clés d’accès au code source, des éléments de signature, des configurations d’assistants IA et des autorisations de déploiement.

Après avoir obtenu un accès, TeamPCP a déployé deux familles de malwares voleurs d’identifiants : SANDCLOCK et DUSTMAKER.

SANDCLOCK a été utilisé en mars et avril 2026 et a été publiquement associé à une activité appelée CanisterWorm. Principalement écrit en Python et ciblant les systèmes Linux, il peut interagir avec Kubernetes, dérober des identifiants cloud et développeur, cibler des portefeuilles de cryptomonnaies et tenter de s’échapper des conteneurs.

DUSTMAKER a été utilisé à partir d’avril 2026. Cette charge utile JavaScript multiplateforme est optimisée pour les environnements d’intégration et de déploiement continus. Elle ne dispose pas de la capacité d’évasion des conteneurs de SANDCLOCK, mais se concentre sur le vol d’identifiants susceptibles de faciliter l’extorsion. Certaines variantes ciblent également les portefeuilles de cryptomonnaies.

DUSTMAKER ajoute une dimension spécifiquement orientée vers l’IA. Il peut contaminer les espaces de travail d’assistants IA et utiliser l’injection de prompt pour contourner les contrôles de défense. Ces techniques n’étaient pas présentes dans les premières variantes de SANDCLOCK décrites par GTIG.

La contamination des espaces de travail est particulièrement dangereuse lorsque les développeurs autorisent les agents de programmation à lire la documentation des dépôts, les fichiers Markdown, les artefacts de configuration ou les instructions propres aux projets. Une instruction malveillante intégrée à un contenu d’espace de travail en apparence fiable peut influencer le comportement de l’assistant, désactiver les avertissements, exposer des secrets ou lui demander d’exécuter des actions dangereuses.

TeamPCP monétise les accès dérobés par des ventes directes et grâce à ses relations avec des groupes de ransomware et d’extorsion fondée sur le vol de données. Une compromission de la chaîne d’approvisionnement peut donc servir de point d’entrée à plusieurs attaquants en aval.

Les modèles d’IA, les prompts et la recherche deviennent à leur tour des cibles

Les attaquants n’utilisent pas l’IA uniquement comme outil offensif. Ils ciblent également les infrastructures et la propriété intellectuelle qui sous-tendent les systèmes d’IA des entreprises.

GTIG a observé des opérations visant des organisations du secteur de la santé, des administrations et des entreprises de médias, avec des tentatives de vol de modèles propriétaires, de prompts, de compétences d’IA, de code source, de travaux de recherche et d’identifiants d’API. Des acteurs malveillants ont également cherché à accéder à des systèmes de développement IA et ont réutilisé des environnements cloud compromis pour exécuter des charges de travail non autorisées.

Les conséquences potentielles dépassent le cadre d’une fuite de données classique. Des clés d’API dérobées peuvent permettre aux attaquants de consommer des services payants sous l’identité de la victime. Des comptes cloud compromis peuvent héberger des charges d’inférence coûteuses, tandis que des modèles et des travaux de recherche volés peuvent servir à l’espionnage, à l’extorsion, à la reproduction concurrentielle ou à la revente.

Google a également observé des attaques par distillation ciblant la compréhension visuelle et audio, la génération d’images et la génération de vidéos. Dans ce type d’activité, un attaquant interroge de manière répétée un modèle protégé et utilise ses résultats pour entraîner ou améliorer un autre système, afin d’en reproduire les capacités sans acquérir directement le modèle d’origine.

Les voleurs d’informations courants alimentent le marché des accès. Lumma Stealer, Vidar et ACR Stealer sont identifiés comme des sources probables d’identifiants pour les services d’IA et les environnements de développement. Leurs cibles de collecte se sont étendues aux fichiers de configuration des développeurs IA, aux tokens et à d’autres artefacts associés aux assistants de programmation et aux API de LLM.

Une fois dérobés, ces éléments peuvent exposer bien davantage qu’un compte de chatbot. Ils peuvent donner accès aux dépôts de code source, aux déploiements cloud, à l’historique des projets, aux prompts propriétaires, aux outils connectés et aux systèmes d’automatisation privilégiés.

Les modèles locaux réduisent la visibilité des fournisseurs

Un acteur lié à la Chine, suivi sous le nom UNC6508, est soupçonné d’avoir compromis des environnements cloud et d’y avoir installé une infrastructure LLM locale. Plutôt que de s’appuyer sur l’API d’un modèle commercial de pointe, l’acteur a utilisé un modèle à poids ouverts au sein de l’environnement de la victime.

Ce choix supprime une couche importante de surveillance. Les fournisseurs d’API peuvent examiner les habitudes d’utilisation, appliquer des contrôles contre les abus, suspendre des comptes et enquêter sur les prompts malveillants. Un modèle exploité localement ne génère pas une télémétrie externe équivalente.

L’attaquant peut également utiliser les ressources de calcul de la victime pour maintenir des charges d’inférence. Une utilisation inattendue des GPU, l’apparition de nouveaux fichiers de modèles, des déploiements de conteneurs, des services en écoute et de fortes variations de la consommation cloud peuvent donc révéler à la fois un vol de ressources et une activité malveillante liée à l’IA.

GTIG a souligné la disponibilité de variantes de modèles « abliterated », ou autrement dépourvues de garde-fous, comme un facteur de risque supplémentaire. Ces modèles peuvent être exploités sans mécanisme centralisé d’application des règles de sécurité pour mener des opérations de reconnaissance, d’hameçonnage, de génération de scripts malveillants ou d’orchestration d’outils.

Le problème ne se résume pas à l’accessibilité des modèles ouverts. Les défenseurs doivent également prendre en compte les charges de travail IA exécutées entièrement au sein d’une infrastructure compromise.

Les États et les groupes criminels intensifient leur recours à l’IA

Cette tendance se retrouve dans l’espionnage, la fraude, les opérations d’influence et l’extorsion.

Basin Castle, également connu sous le nom Mustang Panda, a utilisé Claude, Gemini et Codex pour créer des scripts d’exploitation, mener des campagnes de spear-phishing, effectuer des recherches sur des cibles et résoudre des problèmes au cours d’intrusions. Ravine Castle, également suivi sous les noms APT24, COULEE et Pitty Tiger, a utilisé Gemini pour recueillir des renseignements, développer ses capacités et mener des activités d’influence.

Sandworm, également connu sous les noms APT44 et Sandworm Relic, a utilisé Gemini dans des opérations contre l’Ukraine pour recueillir des renseignements, mener des opérations d’ingénierie sociale et automatiser des flux de travail. Calanque Ion, un groupe lié à l’Iran également appelé APT42, a appliqué l’IA générative à la reconnaissance et à l’ingénierie sociale ciblée.

Des acteurs liés à la Corée du Nord ont utilisé l’IA pour mener des fraudes impliquant des informaticiens, inscrire massivement des comptes d’API de LLM au moyen d’identités détournées, manipuler la chaîne d’approvisionnement, mener des opérations d’ingénierie sociale et développer automatiquement des portes dérobées. UNC6240, également connu sous le nom ShinyHunters, a utilisé Claude Code pour contourner les contrôles de Cloudflare et analyser des répertoires volés à des fins d’extorsion.

Un groupe d’espionnage aligné sur la Chine a également utilisé Gemini lors du développement d’un cadre automatisé de tests d’intrusion conçu pour observer les cibles, évaluer les actions possibles, analyser les ports, interpréter les services et fonctionner dans des environnements changeants.

Ces exemples montrent que l’IA agentique devient une couche opérationnelle. Elle peut aider les attaquants à prendre des décisions et à coordonner des outils, et pas seulement à générer du contenu.

Les défenseurs doivent considérer les instructions destinées aux agents comme un risque d’exécution

Les organisations doivent commencer par faire tourner et révoquer tous les identifiants cloud, développeur, CI/CD, LLM API et de portefeuilles de cryptomonnaies exposés. Elles doivent ensuite rechercher une utilisation inhabituelle des tokens, des accès massifs aux identifiants, des créations inattendues de comptes d’API, une rotation rapide des adresses IP, des analyses automatisées et une consommation cloud ou GPU inexpliquée.

Les principales mesures de défense sont les suivantes :

• Isoler les runners de build et limiter leur accès aux secrets de production.
• Garantir l’intégrité des packages, figer les dépendances, vérifier leur provenance et contrôler les publications.
• Examiner les fichiers Markdown et autres fichiers d’instructions utilisés par les agents de programmation.
• Surveiller les dépôts et les espaces de travail afin d’y détecter des contenus d’injection de prompt.
• Centraliser la journalisation des actions des assistants IA, des appels d’API, de l’exécution des outils et des modifications administratives.
• Détecter les fichiers de modèles, serveurs d’inférence, conteneurs et services d’IA locaux non autorisés.
• Segmenter les environnements de développement, le cloud de production et les espaces d’expérimentation IA.
• Restreindre les outils d’IA non approuvés sans faire de ces restrictions l’unique mesure de contrôle.
• Protéger les modèles, les prompts, les travaux de recherche et le code source en tant que propriété intellectuelle de grande valeur.

Aucun indicateur public de compromission n’a été fourni pour l’opération de vol d’identifiants menée en six heures. Les défenseurs doivent donc se concentrer sur les éléments comportementaux plutôt que sur une liste figée de signatures.

Le risque central est déjà concret : les agents d’IA peuvent raccourcir la durée d’une intrusion en coordonnant des tâches qui exigeaient auparavant l’attention constante d’un opérateur. Lorsque les identifiants, les systèmes de build et les ressources cloud sont interconnectés, six heures peuvent suffire à transformer un environnement compromis en point d’accès à de nombreux autres.