Google et Mandiant décrivent le LLMJacking : des jetons cloud et clés d'API volés transforment l'accès aux modèles en factures de plus de 100 000 dollars par jour dans certains incidents
Le 2 novembre 2026, Google Threat Intelligence Group et Mandiant ont publié un rapport sur le LLMJacking, par lequel des attaquants détournent l'accès d'entreprises aux modèles de langage via des jetons d'identité cloud exposés ou volés et des clés d'API divulguées ; des incidents individuels ont dépassé 100 000 dollars en une journée et certaines organisations ont atteint 1 million de dollars cumulés. Il décrit aussi la faille CVE-2026-40217 d'une passerelle LiteLLM, les LLM Mixers qui revendent l'accès volé, et des défenses comme la gestion des secrets, le moindre privilège, les plafonds de budget et la correction des passerelles. Les chiffres viennent d'incidents choisis, et l'avis de GTIG selon lequel Jet Night s'appuie sur des clés volées est une inférence.
Le 2 novembre 2026, Google Threat Intelligence Group et Mandiant ont publié un rapport sur le LLMJacking, le détournement de l'accès d'une organisation aux grands modèles de langage. Le rapport indique que Mandiant est intervenu en 2026 sur plusieurs incidents où des acteurs malveillants ont pris le contrôle de l'accès d'entreprises à des modèles, chez divers fournisseurs de cloud et de modèles. Les victimes se trouvaient en Amérique du Nord, en Amérique du Sud et en Asie-Pacifique, dans la finance, le commerce de détail, la technologie et les transports. Les auteurs décrivent un schéma, pas une campagne unique, construit à partir de plusieurs enquêtes distinctes.
L'argent est le point central. Contrairement à l'utilisation lente des ressources du cryptojacking, le LLMJacking peut provoquer en quelques heures un pic de frais frauduleux dans le cloud. Le rapport dit que, dans des incidents individuels, les frais frauduleux ont dépassé 100 000 dollars en une seule journée, et que, dans certaines organisations, les frais cumulés ont atteint 1 million de dollars avant la révocation de l'accès. Ce sont des chiffres tirés d'incidents choisis traités par Mandiant, pas une moyenne ni un total pour le secteur.
Pour l'accès initial, le rapport explique que les attaquants contournent les interfaces de conversation et visent directement les ressources de modèles en arrière-plan. Ils cherchent des points d'accès de modèles exposés publiquement ou des clés d'API valides. Dans plusieurs enquêtes, la voie dominante était des jetons d'identité cloud exposés ou volés, notamment des identifiants IAM, des clés de compte de service, des jetons d'accès personnels GitHub et des jetons de session actifs. Un groupe suivi sous le nom UNC6993 a utilisé mi-2026 une clé de compte de service mal configurée et a aussi hébergé un faux portail qui demandait de coller une charge JSON brute contenant un jeton d'accès actif, ce qui permettait de contourner mots de passe et authentification multifacteur. Un autre acteur a récolté des clés d'API de modèles d'entreprise dans des dépôts GitHub publics et les a vérifiées avec des requêtes d'un seul jeton, avec max_tokens fixé à 1, afin que la détection sur les points de terminaison et les alertes de volume ne se déclenchent pas.
Une fois à l'intérieur, les acteurs ont cherché à étendre et à conserver l'accès. Le rapport décrit la création de comptes IAM et de comptes de service non autorisés, l'attachement de politiques d'administration et l'injection de clés SSH dans des instances de calcul. Il décrit aussi une attaque contre un logiciel de routage de modèles. Après avoir obtenu des clés virtuelles déjà validées, un groupe suivant a exploité une faille de rattachement d'identifiant utilisateur dans le point de terminaison /key/regenerate d'une passerelle LiteLLM, référencée CVE-2026-40217, pour transformer de simples clés virtuelles en identifiants d'administrateur complets du proxy. Le rapport traite la passerelle elle-même comme un système privilégié à corriger comme les autres.
La phase d'abus consiste à transformer l'accès en argent. Les acteurs ont activé des services d'IA générative gérés qui n'étaient pas activés au moment de la compromission, ont créé d'autres clés d'API et, dans un cas, ont abonné des comptes victimes à des forfaits à l'usage pour lancer une inférence à gros volume selon un schéma de brûler et renouveler des comptes de service éphémères. Le rapport décrit aussi les LLM Mixers, des passerelles illicites qui regroupent, mesurent et revendent l'accès volé à des abonnés clandestins. Un service, Jet Night, a généré plus de 500 000 appels d'API en moins de huit heures et a répercuté près de 1 million de dollars de frais de jetons sur une victime. GTIG estime qu'il s'appuie sur des clés volées, car il annonce un forfait illimité d'environ 60 dollars par mois pour des modèles qui coûteraient normalement 100 à 250 dollars, et publie des pannes qui suivent probablement des révocations de clés. Ce sont des inférences de GTIG, pas des faits prouvés.
Pour les défenseurs, le rapport donne des conseils en couches. Traitez toute activation non autorisée d'un service de modèle comme un événement de sécurité critique, car dans plusieurs incidents le service était désactivé au moment de la compromission. Utilisez une gestion centralisée des secrets et une analyse automatique des secrets, le moindre privilège avec refus d'accès aux services de modèles sauf besoin, une authentification multifacteur résistante à l'hameçonnage, des listes d'autorisation réseau, une limitation de débit, des quotas d'API fins et des plafonds de dépenses, ainsi que des portées de clés séparant les modèles utilitaires bon marché des modèles de pointe coûteux. Surveillez dans les journaux de passerelle et d'API les requêtes de validation minuscules, corrigez vite les passerelles de modèles et limitez les récupérations de modèles à des registres approuvés. Le rapport liste aussi des noms de règles de Google Security Operations, comme la création de clés de compte et les modifications de clés SSH de projet, qui détectent une partie de l'activité.
Il faut lire les chiffres avec prudence. Les incidents forment un ensemble choisi vu par un seul intervenant, et plusieurs attributions sont des évaluations des auteurs. La perspective, selon laquelle GTIG s'attend à ce que le LLMJacking soit privilégié par rapport au cryptojacking, est une prévision. La mesure pratique est peu coûteuse : confirmez dès aujourd'hui quels comptes cloud peuvent activer des services de modèles, fixez un plafond de budget strict, alertez sur toute nouvelle activation de modèle et renouvelez toute clé d'API qui est un jour apparue dans un dépôt.
Sources
FAQ
En quoi le LLMJacking diffère-t-il du cryptojacking ?
Le cryptojacking utilise lentement du calcul volé, alors que le LLMJacking détourne l'accès d'une organisation aux modèles de langage et peut faire grimper les frais frauduleux en quelques heures. Le rapport dit que des incidents individuels ont dépassé 100 000 dollars en une journée et que certaines organisations ont atteint 1 million de dollars cumulés. Ce sont des incidents choisis, pas des moyennes du secteur.
Comment les attaquants obtiennent-ils surtout l'accès initial ?
Le rapport dit que la voie dominante était des jetons d'identité cloud exposés ou volés, dont des identifiants IAM, des clés de compte de service, des jetons d'accès personnels GitHub et des jetons de session. Certains ont aussi récolté des clés d'API dans des dépôts publics et les ont vérifiées discrètement avec max_tokens à 1. Les points d'accès de modèles exposés publiquement sont une autre cible.
Que doit faire une organisation en premier ?
Confirmer quels comptes cloud peuvent activer des services de modèles, fixer des plafonds de budget stricts et des quotas d'usage, et alerter sur toute nouvelle activation de modèle. Ajouter ensuite l'authentification multifacteur résistante à l'hameçonnage, l'analyse des secrets et le moindre privilège, renouveler toute clé d'API apparue dans un dépôt, surveiller les requêtes de validation minuscules et corriger vite les passerelles de modèles.