GTIG AI Threat Tracker : d'un prompt à des milliers d'identifiants en six heures

Le Google Threat Intelligence Group a publié l'édition du deuxième trimestre 2026 de son AI Threat Tracker le 8 septembre 2026. Le cas central du rapport peut se résumer simplement : un acteur présumé motivé financièrement s'est emparé d'une ressource cloud appartenant à une victime, a injecté une consigne et un ensemble d'instructions d'agent préécrites dans un chatbot de programmation basé sur l'IA, et a récolté des milliers d'identifiants de tiers en moins de six heures, l'agent gérant seul l'analyse des vulnérabilités, le dépannage et la rotation d'IP. Le même rapport décrit des serveurs MCP troyanisés sur PyPI, un voleur d'identifiants qui s'approprie l'identité du système de build lui-même afin que ses paquets piégés arrivent accompagnés d'attestations SLSA Build 3 valides et signées cryptographiquement, et un texte adversarial conçu pour amener les scanners de sécurité fondés sur des LLM à refuser de lire le code qu'il dissimule. Tout cela est la version de Google concernant sa propre télémétrie. Ce rapport est répertorié, avec son niveau de confiance et ses sources citées, dans l'archive des incidents liés à l'IA, qui rassemble à ses côtés tous les autres incidents documentés de cette série.

Aucune des allégations de fond n’a été vérifiée par une partie qui ne se contente pas de reprendre Google. Help Net Security a couvert le tracker le jour de la publication, la Cloud Security Alliance a publié une note de recherche le lendemain, et Lineaje a publié une analyse DUSTMAKER le 17 septembre ; chacune est un résumé ou une surcouche analytique de la divulgation de Google, et Lineaje le dit elle-même, en notant que GTIG « décrit plusieurs capacités DUSTMAKER connexes plutôt qu’une seule trace d’exécution de bout en bout observée. » La deuxième source citée aux côtés de ce dossier, un élément « threat pulse » de threatops.tech daté du 11 septembre 2026, est une reformulation plutôt qu’un second témoin : elle n’ajoute aucun reportage, ne conteste aucun chiffre et relève l’étiquette de gravité sans expliquer à quoi elle est mesurée. La couverture ne s’accorde même pas pleinement sur le nom de l’édition — Help Net Security l’appelle le tracker du T3 2026 tout en datant son cas principal du T2 2026 — ce qui est une différence de numérotation, non un conflit factuel.

L’archive classe cela comme un rapport plutôt que comme un incident : niveau de confiance A, non contesté, aucune estimation chiffrée du préjudice réel enregistrée à son sujet. Cette notation décrit la qualité de la documentation, non l’ampleur des dégâts. Google compte des identifiants, pas des victimes. Le tracker ne précise pas combien d’organisations ont été prises dans la campagne de six heures, qui elles étaient, quel chatbot a été utilisé, ni si certains des identifiants volés ont ensuite été vendus ou utilisés.

Les six heures que décrit GTIG, et les trois tâches que l’agent a accomplies seul

La séquence décrite dans le rapport va de l'accès au résultat avec très peu d'intervention humaine entre les deux. L'acteur a compromis une ressource cloud, puis a utilisé un chatbot commercial d'IA de programmation avec ce que GTIG appelle « un prompt » et « un ensemble d'instructions d'agent » — les playbooks Markdown qui se trouvent désormais dans les dépôts sous forme de fichiers AGENTS.md — pour planifier, construire et exécuter l'opération. Google qualifie lui-même le résultat de « campagne massive de collecte d'identifiants assistée par agents », menée « en moins de six heures ».

Trois tâches sont qualifiées d’autonomes, et ce sont précisément celles qui, autrement, auraient requis l’attention d’un opérateur :

• Le pipeline d’analyse des vulnérabilités, que les instructions de l’agent permettent à l’IA de « {{1}}gérer de manière autonome,{{/1}} », selon la formulation que Help Net Security cite de GTIG.

• Résolution en temps réel des problèmes révélés par l'analyse, afin qu'une défaillance ne bloque pas l'exécution en attendant une décision.

• Rotation d’IP, de sorte que les tentatives successives provenaient d’adresses différentes sans que personne n’ait émis la commande.

L’endroit d’où l’opération a été menée est aussi important que sa rapidité d’exécution. En opérant depuis l’infrastructure cloud de la victime elle-même, l’acteur a acheminé le trafic via les plages d’adresses IP légitimes de la victime. Les requêtes qui semblent provenir de l’intérieur d’une organisation sont précisément celles que les défenses fondées sur la réputation sont les moins aptes à remettre en question, et le rapport le consigne comme une conséquence du fait d’avoir opéré depuis le propre environnement de la victime.

Ce que le rapport ne contient pas est aussi révélateur que ce qu’il contient. Il n’y a pas de chronologie étape par étape, de sorte que « moins de six heures » est une mesure unique de l’ensemble de l’exécution et ne peut pas être décomposée en un graphique. Il n’y a pas de nom pour l’acteur au-delà de « soupçonné d’être motivé par des intérêts financiers », pas de victime, et aucune précision sur le modèle ou le fournisseur du chatbot impliqué. Le tracker considère ce cas comme un exemple développé d’une tendance, et il est rédigé à un niveau d’abstraction qui sert cet objectif plutôt qu’à celui qu’un intervenant en réponse à incident souhaiterait.

Un serveur exposé devenu un tableau de bord de 23 800 secrets

Un second constat dans la même section est plus concret, et il s'agit d'un cas distinct. GTIG a découvert un serveur de commande et de contrôle exposé hébergeant un framework automatisé de reconnaissance et de gestion des identifiants, appelé Recon. La liste du répertoire était lisible et révélait la conception : AGENTS.md, KNOWLEDGE.md, agentic_vuln_research.md, ainsi qu'un répertoire modulaire .openclaw/ et un répertoire memory/. Ces noms de fichiers sont la signature d'une pile d'agents plutôt que celle d'un implant sur mesure — des instructions, des connaissances accumulées et un plan de recherche, le tout sur disque, là où les outils de l'opérateur peuvent les lire.

Le même répertoire, plus tard, servait de tableau de bord frontend en direct organisant et validant plus de 23 800 secrets récoltés, y compris des clés API pour des services cloud et d'IA. GTIG qualifie le changement ainsi représenté de passage « d'infostealers passifs, centrés sur les points de terminaison, à une collecte agentique offensive » — c'est-à-dire, d'un logiciel malveillant qui récupère ce qu'il peut sur un seul ordinateur portable à un outillage qui continue d'exploiter les cibles qu'il a déjà atteintes.

Deux mises en garde accompagnent ce chiffre. Vingt-trois mille huit cents est un décompte de secrets, non de personnes ou d’entreprises, et le rapport ne transpose pas l’un en l’autre. Et GTIG ne précise pas si le serveur Recon et la campagne de six heures relèvent de la même opération ; ils sont présentés comme des observations distinctes dans la même section, de sorte que les traiter comme un seul récit serait une inférence que le rapport ne fait pas.

DUSTMAKER et l'attestation qui indique correctement que le paquet est authentique

La partie du traqueur consacrée à la chaîne d'approvisionnement concerne UNC6780, que Google suit également sous le nom de TeamPCP, un groupe à motivation financière qui compromet des infrastructures open source depuis mars 2026 sur PyPI, npm et Docker Hub. Sa méthode avec les outils d'IA est directe : des comptes de développeurs compromis ont été utilisés pour publier des forks troyanisés de serveurs MCP légitimes, avec tiktoken_mcp cité comme exemple sur PyPI, et du code malveillant a été injecté dans des dépôts officiels d'organisations, notamment azure-functions-mcp-extension. GTIG note que les charges utiles et les hooks d'espace de travail malveillants étaient ensuite ingérés automatiquement dès que les actifs étaient téléchargés ou clonés — aucun appât distinct, aucune seconde étape.

son voleur d’identifiants, DUSTMAKER, que réside le point technique le plus utile du rapport. La chaîne est courte. Le voleur détecte qu’il s’exécute dans un environnement CI/CD ; GTIG écrit que « si cela est confirmé », il extrait des jetons OIDC de la mémoire du processus d’un runner GitHub Actions. Il utilise ces jetons pour s’autoriser en tant qu’éditeur de confiance. Il publie ensuite des versions compromises de paquets portant des attestations SLSA Build 3 valides et signées cryptographiquement. Rien dans cette chaîne n’est falsifié. L’attestation est réelle, délivrée à une identité réelle, pour une compilation qui a réellement eu lieu — de code écrit par l’attaquant. La conclusion de GTIG est la phrase qui compte pour quiconque se fie à la provenance : « Les paquets publiés avec des jetons valides passeront les contrôles automatisés de confiance des agents de codage IA. »

Le reste du comportement de DUSTMAKER cible des endroits que les défenseurs ne surveillent pas. Il dépose et modifie des fichiers dans les répertoires d'espace de travail des assistants de codage IA et des IDE — .claude/, .vscode/, .cursor/ — où il se fond dans le bruit des développeurs et évite les emplacements réellement surveillés par la détection des points de terminaison, comme les clés du Registre Windows ou /etc/cron.*. Il écrit une configuration qui amène l'IDE ou l'extension IA à exécuter un script tel que setup.mjs à l'ouverture de l'espace de travail, ce qui transforme l'ouverture d'un dossier en exécution de code. Il crée des tâches de pipeline aux noms inspirés de l'IA, comme "Copilot Setup" pour chasser des jetons, et émet des appels API pour supprimer les journaux d'exécution des workflows afin que l'exécution n'apparaisse pas dans l'interface GitHub.

Le malware qui demande au scanner de regarder ailleurs

Le dernier mécanisme est le moins vérifié des trois. Les scripts de chargement JavaScript de DUSTMAKER commencent par un texte de prompt adversarial intégré en commentaires — dans _index.js entre autres — faisant référence à des armes biologiques et nucléaires, et incluant une demande de spécification pour un dispositif à fission de type implosion de 20 kilotonnes. L'évaluation de GTIG est que cela était « probablement destiné à faire échouer les scanners de sécurité des LLM ou à leur faire ignorer l'analyse du code JavaScript malveillant sous-jacent, en raison de refus liés à la sécurité ou aux politiques ».

L'étiquette attachée à cette phrase n'est pas anodine. Il s'agit d'une affirmation sur l'intention, déduite du texte que porte le loader, et non de la démonstration qu'un scanner quelconque aurait réellement refusé le fichier. Le rapport ne nomme aucun scanner ayant ignoré le fichier, ne rapporte aucun taux de contournement et ne dit pas que la technique a fonctionné. Ce qui est établi, c'est que quelqu'un a écrit l'appât et l'a expédié au sein d'un voleur d'identifiants — ce qui constitue en soi une preuve que les attaquants s'attendent à ce qu'un triage fondé sur les LLM intervienne dans la chaîne.

UNC6508, MIDNIGHT NEPTUNE et CALANQUE ION figurent dans le même rapport.

Les éléments du traqueur liés à un État sont plus vastes que ses éléments criminels, et généralement moins automatisés. UNC6508, un groupe lié à la RPC, mène depuis plusieurs années une campagne d’espionnage contre la recherche universitaire, médicale et militaire nord-américaine et cible désormais spécifiquement la recherche propriétaire en IA ; GTIG soupçonne le groupe de compromettre des environnements cloud afin de déployer des modèles locaux à poids ouverts, ce qui évite la surveillance des API commerciales et met à contribution la puissance de calcul de la victime.

Ailleurs, le schéma est celui de modèles prêts à l'emploi effectuant un travail ordinaire à grande échelle. Le groupe nord-coréen MIDNIGHT NEPTUNE, anciennement UNC1069, a utilisé DeepSeek-Coder pour écrire des chevaux de Troie d'accès à distance en Python avec persistance multiplateforme et injection de processus, a utilisé des LLM pour des scripts Bash de déplacement latéral, animé des profils d'ingénierie sociale et des leurres techniques, empoisonné des configurations de dépôts internes, modifié les hooks de Claude CLI et déployé la porte dérobée SOMBERMEME lorsqu'un développeur interagissait avec le dépôt. Le groupe iranien CALANQUE ION, anciennement APT42, a utilisé des modèles pour identifier des adresses e-mail cibles, exécuter de l'OSINT, localiser des leurres, résumer des données exfiltrées et tenter une ingénierie inverse du code de licence. Le groupe lié à la RPC BASIN CASTLE a utilisé Gemini pour le profilage de cibles, la traduction de documents chinois en rapports politiques en anglais formel et le dépannage PowerShell ; RAVINE CASTLE a étudié avec lui les contournements SAML de VMware vCenter et la post-exploitation d'Active Directory ; le groupe russe SANDWORM RELIC a fait écrire par Gemini son code de pulvérisation de mots de passe. Le groupe à motivation financière UNC6240, également suivi sous le nom de ShinyHunters, a utilisé des prompts de Claude Code pour écrire du code obfusqué, contourner Cloudflare et analyser des répertoires exfiltrés via des outils MCP personnalisés.

Un cas dans cette section va plus loin que les autres. Un groupe lié à la RPC a utilisé Gemini pour concevoir un cadre automatisé dynamique de test d'intrusion destiné à observer l'état d'une cible, à raisonner sur la suite à donner et à effectuer des scans de ports et l'analyse des services. Google indique avoir pris des mesures plus larges contre les campagnes qu'il a identifiées, en désactivant les actifs, projets et comptes associés. Par ailleurs, en juin 2026, Google a démantelé "Outsider Enterprise," un service de cybercriminalité basé en Chine qui fournissait des kits d'hameçonnage, et a décrit cela comme la première fois qu'il engageait des poursuites judiciaires pour un usage abusif de Gemini. Ce sont deux déclarations distinctes, et un résumé qui les fusionnerait dirait plus que le rapport : le cadre de test d'intrusion relève du langage sur la perturbation des actifs, l'action en justice relève d'Outsider Enterprise.

LLMJacking, et combien coûte désormais un compte d’IA volé

Le tracker établit également les prix du marché des accès volés à l’IA. La demande souterraine s’est concentrée sur les identifiants Claude et Gemini, ainsi que sur les IDE de codage autonomes Cursor Pro et Devin, ce dernier étant développé par Cognition, et les prix moyens par compte sur les places de marché ont plus que doublé au cours de 2026. Les infostealers chargés de la collecte — LUMMAC.V2, STEALC.V2, VIDAR et ACRSTEALER — ont été mis à jour pour cibler la configuration des développeurs d’IA. En mai 2026, les contrôleurs d’ACRSTEALER ont déployé des règles de capture de fichiers pour le fichier de configuration de Cline, secrets.json et celui de Continue AI, config.yaml, qui peuvent tous deux contenir des clés API en clair et des points de terminaison personnalisés de routage de modèles.

Une intrusion décrite par GTIG montre ce que vaut un compte d'IA une fois qu'il est compromis. En avril 2026, un jeton d'accès personnel GitHub exposé a suffi à activer Gemini Enterprise, à provisionner des ressources de calcul hautes performances, à créer des dépôts Docker pour un déploiement d'API LiteLLM et le framework d'agents Manus, et à déployer des services Cloud Run exposés à allUsers via une liaison d'invocateur IAM. La même session a créé un compte de service frauduleux disposant de privilèges Editor et exporté ses clés, interrogé BigQuery pour obtenir des variables d'environnement et des identifiants, tenté de transférer la propriété du projet à une adresse externe, et utilisé l'API Cloud Quotas pour demander de la capacité NVIDIA RTX 6000 et des instances supplémentaires de 48 vCPU.

Le tableau de l’extraction de modèles relève de la même logique économique, à plus grande échelle. GTIG indique que les campagnes de distillation sont désormais régulières, « certaines dépassant 100 millions de prompts », les requêtes étant réparties en rotation entre des milliers de comptes compromis et frauduleux et acheminées via une infrastructure de proxy, et que Google a déployé des contre-mesures susceptibles de dégrader les performances d’un modèle étudiant ainsi que des méthodes permettant d’identifier les modèles distillés de Gemini par leur provenance.

Ce qui est établi, ce qui relève de l’évaluation, et ce que GTIG dit ne pas avoir vu

Établi, au sens où Google décrit sa propre télémétrie de première partie et ses propres actions sur les comptes : le rapport et sa date ; les artefacts qu’il dit avoir observés, y compris les noms de paquets, les noms de fichiers du loader, les noms de répertoires et le tableau de bord des 23 800 secrets ; et les mesures de perturbation que Google dit avoir prises, qu’il peut attester car désactiver un compte est quelque chose qu’il fait plutôt que quelque chose qu’il déduit. Help Net Security, la Cloud Security Alliance et Lineaje rapportent tous ces éléments sans contradiction, bien qu’aucun d’entre eux n’apporte de preuve indépendante qui lui soit propre.

Évaluation, au sens où il s’agit d’un jugement que Google porte : chaque attribution à un État-nation dans le rapport ; l’interprétation de la provocation au refus comme délibérée ; et l’affirmation selon laquelle les jetons volés passeront « les contrôles de confiance automatisés des agents de codage IA », qui est une déclaration sur la manière dont ces contrôles sont généralement conçus plutôt qu’une mesure d’un produit spécifique échouant à l’un d’eux.

Non établi : l'identité de l'acteur des six heures, les victimes et leur nombre, le chatbot et le modèle impliqués, et si le serveur Recon est lié de quelque manière que ce soit à cette campagne.

Et le plafond du rapport lui-même est plus bas que son titre ne le suggère. Le GTIG déclare qu'il n'a pas encore observé de pipelines d'exploitation entièrement autonomes dans la nature, et estime que l'usage qu'en font les adversaires « pourrait évoluer vers ce cas d'usage ». La fracture se situe à l'intérieur de l'attaque plutôt qu'autour d'elle : des êtres humains fournissent l'objectif, le prompt et le fichier d'instructions ; l'agent fournit l'analyse des scans, le dépannage et la rotation, et ne s'arrête pas pour demander la permission. À y regarder de près, la campagne de six heures ne prouve pas que l'autonomie est advenue. Elle prouve que la part humaine du travail s'est réduite à la partie qui exige un humain — décider quoi faire — tandis que tout ce qui sépare la décision du résultat s'exécutait tout seul.

Ce que Google dit avoir modifié, et le contrôle que le rapport désigne réellement

La réponse officielle de Google s'articule autour de deux axes. En matière d'abus, elle indique que les activités « ont déclenché les réponses de sécurité de Gemini », qu'elle a pris des « mesures supplémentaires et plus larges » contre les campagnes en raison des défaillances de sécurité opérationnelle des acteurs, qu'elle a désactivé les ressources, projets et comptes associés, et que Google DeepMind a utilisé les conclusions pour renforcer ses classificateurs et le modèle lui-même afin qu'il refuse ces demandes. En matière de défense, elle a déployé Google AI Threat Defense, qui associe Gemini et des modèles de pointe à la priorisation des risques de Wiz, à la remédiation par Gemini et CodeMender et au renseignement de Mandiant, en utilisant des modèles plus légers pour l'analyse continue et des modèles de pointe pour les constats à haut risque ; elle a également introduit Gemini 3.8 Flash Cyber pour la détection des vulnérabilités et l'application automatisée de correctifs, et publié des recommandations pour renforcer la chaîne d'approvisionnement open source.

Le correctif précis que le cas DUSTMAKER appelle est plus étroit que cet empilement, et les analyses externes convergent sur ce point. Une attestation SLSA répond à la question de savoir si un paquet a été construit par l’identité qu’il revendique. Elle ne répond pas à la question de savoir si cette identité appartient toujours à la partie à laquelle vous vouliez faire confiance, et toute la méthode de DUSTMAKER consiste à emprunter une identité plutôt qu’à en fabriquer une. Le résumé de Lineaje du changement sous-jacent en est l’énoncé le plus clair : « Le contenu du dépôt devient une autorité d’exécution. » Les noms de paquets, les noms de serveurs MCP, les badges d’attestation et les fichiers d’instructions à l’intérieur d’un dépôt s’accompagnent désormais tous d’une prétention à l’obéissance, et c’est le jeton OIDC volé qui fait paraître cette prétention vérifiée.