Une facture d'un million de dollars pour des requêtes jamais commandées
Le cas documenté par le Google Threat Intelligence Group (GTIG) et sa filiale Mandiant, dans une enquête publiée le 2 novembre, résume à lui seul la mécanique du LLMJacking. Un acteur malveillant a utilisé des clés API tierces volées pour alimenter Jet Night, un service de routage de jetons, en envoyant plus de 500 000 appels d'API en moins de huit heures. Résultat : près d'un million de dollars de consommation facturée à une organisation qui n'avait rien demandé. L'entreprise n'a découvert la compromission qu'une fois la facture arrivée.
Ce n'est pas un cas isolé. GTIG a relevé plusieurs incidents où les charges frauduleuses ont dépassé 100 000 dollars en une seule journée, avant même que les accès compromis ne soient révoqués. Les victimes viennent de secteurs variés : finance, commerce de détail, technologie, transport, réparties entre l'Amérique du Nord, l'Amérique du Sud et l'Asie-Pacifique. Rien n'indique que les entreprises françaises soient épargnées : le vecteur d'attaque, à savoir des clés API mal protégées, ne connaît pas de frontière.
Comment les pirates mettent la main sur les clés API
Le LLMJacking repose presque toujours sur le même principe : s'emparer d'un identifiant qui autorise déjà un accès légitime à un modèle d'IA, puis l'exploiter en silence le plus longtemps possible. Les sources documentent plusieurs points d'entrée récurrents.
- Des clés API exposées par erreur dans des dépôts GitHub publics.
- Des identifiants cloud compromis : clés de compte de service mal configurées, identités IAM d'employés, jetons de fédération.
- Des jetons d'accès personnels (PAT) GitHub volés, donnant accès à des dépôts de code privés.
- Des jetons de session actifs détournés, qui permettent de contourner l'authentification multifacteur sans jamais toucher au mot de passe.
- Des points d'accès de modèles exposés publiquement, y compris des instances Ollama laissées ouvertes.
Un groupe identifié sous le nom UNC6993 a par exemple compromis une instance cloud via une clé de compte de service mal configurée, avant d'héberger une fausse page de portail applicatif invitant la victime à coller le contenu JSON brut d'un jeton d'accès actif. Une fois ce jeton récupéré, mot de passe et double authentification deviennent inutiles.
Avant de lancer des requêtes massives, les attaquants prennent souvent soin de vérifier discrètement la validité d'une clé. Ils envoient une requête limitée à un seul jeton de réponse (paramètre max_tokens=1), suffisante pour confirmer que l'accès fonctionne, mais trop faible pour déclencher les alertes de consommation des outils EDR ou SIEM. C'est précisément cette discrétion initiale qui rend la détection difficile : la facture explose seulement après, quand l'accès est déjà revendu.
Le marché clandestin des « LLM Mixers »
Une fois l'accès obtenu, deux logiques de monétisation coexistent. Certains acteurs exploitent directement les clés pour leurs propres usages, en provisionnant par exemple des machines équipées de GPU puissants. D'autres, plus nombreux, alimentent des plateformes appelées « LLM Mixers ». Ces passerelles de routage clandestines regroupent les identifiants volés à plusieurs entreprises et revendent l'accès sous forme d'abonnement à des clients qui ignorent tout de l'origine des clés.
Le fonctionnement est simple : le client paie un abonnement mensuel, sa requête transite par l'infrastructure du Mixer, qui la relaie vers le modèle visé à l'aide d'une clé API compromise. Le client reçoit sa réponse, les pirates encaissent l'abonnement, et l'entreprise dont la clé a été volée supporte seule le coût de la consommation auprès du fournisseur d'IA.
Jet Night, le service cité plus haut, annonçait un forfait présenté comme illimité autour de 60 dollars par mois, avec un accès revendiqué à des modèles de pointe, alors qu'un service grand public équivalent coûte, selon les sources consultées, entre 100 et 250 dollars. Le service a connu plusieurs pannes signalées sur son canal Telegram public, que GTIG attribue vraisemblablement à des révocations de clés par les victimes découvrant la fraude.
| Élément | Accès légitime (prix catalogue) | Accès via un LLM Mixer |
|---|---|---|
| Coût mensuel pour l'utilisateur final | 100 à 250 dollars selon le fournisseur | Environ 60 dollars, forfait présenté comme illimité |
| Qui supporte le coût réel de l'inférence | L'abonné lui-même | L'entreprise dont la clé API a été volée |
| Traçabilité pour la victime | Facturation directe et maîtrisée | Consommation anormale détectée a posteriori |
GTIG signale aussi une division du travail entre groupes criminels : l'un compromet les infrastructures et récupère les identifiants, l'autre se charge exclusivement de la revente. Cette spécialisation pourrait rendre le LLMJacking plus lucratif que le cryptojacking traditionnel, qui exploite les ressources d'une victime de façon progressive. Le LLMJacking, lui, provoque des pics de facturation en quelques heures seulement, ce qui rend la détection tardive d'autant plus coûteuse.
Des passerelles de modèles elles-mêmes vulnérables
Le risque ne se limite pas aux clés API individuelles. Les entreprises qui utilisent une passerelle de routage pour gérer plusieurs modèles d'IA, pratique courante dans les architectures multi-fournisseurs, doivent aussi surveiller les failles de cette couche intermédiaire. Un acteur a ainsi exploité une vulnérabilité de réaffectation d'identifiant utilisateur sur le point d'accès /key/regenerate d'une passerelle LiteLLM, référencée CVE-2026-40217, pour transformer des clés virtuelles standard en identifiants d'administration complets (PROXY_ADMIN). Une clé censée n'autoriser qu'un usage limité devenait alors un accès total à l'infrastructure.
Mandiant relève un signal particulièrement simple à surveiller : dans plusieurs incidents, les services d'IA concernés (Bedrock, API Gemini) n'étaient pas activés au moment de la compromission. Ce sont les clés détournées qui ont servi à les activer. Toute activation non autorisée d'un service d'IA auquel l'entreprise n'avait pas souscrit doit donc être traitée comme un événement de sécurité critique, et non comme une anomalie de facturation ordinaire.
Auditer ses clés API : la checklist pour les DSI
Les recommandations qui ressortent de l'enquête convergent vers un principe simple : une clé émise pour un usage précis ne doit jamais devenir un laissez-passer réutilisable pour d'autres modèles ou d'autres charges de travail.
| Point de contrôle | Action d'audit recommandée |
|---|---|
| Dépôts de code | Scanner systématiquement les dépôts GitHub, y compris privés, à la recherche de clés API ou de secrets en dur dans le code ou les fichiers de configuration. |
| Permissions des clés | Appliquer le principe de moindre privilège et des périmètres de clés granulaires, limités aux modèles et points de terminaison réellement utilisés. |
| Rotation | Mettre en place une rotation régulière des clés API et des jetons de session, au lieu de clés statiques valables sans limite de temps. |
| Surveillance du volume | Détecter les requêtes suspectes de très faible volume, y compris celles limitées à un seul jeton de réponse, qui peuvent signaler un test de validité par un attaquant. |
| Activation de services | Alerter automatiquement sur toute activation d'un service d'IA auquel l'organisation n'a pas souscrit. |
| Plafonds de dépense | Fixer des limites de consommation sur chaque clé et chaque projet cloud, pour contenir un pic de facturation avant qu'il n'atteigne des montants à six chiffres. |
| Passerelles de routage | Tenir à jour les logiciels de routage multi-modèles (type LiteLLM) et vérifier l'absence de vulnérabilités connues sur les points de terminaison de gestion des clés. |
Sur ce dernier point, les architectures qui reposent sur un abonnement à siège fixe plutôt que sur une facturation au jeton changent la nature du risque financier, sans pour autant garantir une absence de faille : une entreprise qui paie un tarif mensuel connu par utilisateur, par exemple via une offre regroupant plusieurs modèles sous un même abonnement comme le propose Moon AI avec ses formules à partir de 9,90 euros TTC par siège, n'est pas exposée à une facture au jeton qui s'envole en quelques heures. Elle reste en revanche soumise aux mêmes exigences d'hygiène sur la gestion des identifiants d'accès à la plateforme elle-même.
Questions fréquentes
Comment savoir si mon entreprise est déjà victime de LLMJacking ?
Le signal le plus fiable, selon Mandiant, est l'activation d'un service d'IA auquel l'organisation n'avait pas souscrit, ou une hausse soudaine de la facturation sur un modèle peu utilisé habituellement. Les requêtes de validation envoyées par les attaquants, souvent limitées à un seul jeton de réponse, passent rarement les seuils d'alerte classiques fondés sur le volume : il faut donc surveiller aussi les créations de comptes de service inhabituelles et les changements d'autorisation non planifiés.
Les attaques visent-elles uniquement les grandes entreprises ?
Les sources mentionnent des victimes dans la finance, le commerce de détail, la technologie et le transport, réparties entre plusieurs continents. Aucun chiffre ne permet d'affirmer que seules les grandes structures sont concernées : une simple clé API exposée dans un dépôt public, quelle que soit la taille de l'entreprise qui l'a émise, constitue une cible exploitable.
Changer de fournisseur de modèle suffit-il à éliminer le risque ?
Non. L'enquête montre que les attaques ne se limitent ni à un fournisseur de cloud ni à un éditeur de modèles : elles touchent plusieurs d'entre eux selon la configuration de l'entreprise visée. Le risque tient à la façon dont les identifiants sont stockés, diffusés et surveillés, pas au choix d'un modèle en particulier.
Une passerelle multi-modèles protège-t-elle automatiquement contre le LLMJacking ?
Pas nécessairement. L'une des affaires documentées montre qu'une passerelle de routage de modèles (LiteLLM) a elle-même été compromise via une vulnérabilité référencée CVE-2026-40217, qui a permis de transformer des clés d'usage limité en identifiants d'administration complets. Une passerelle doit donc être maintenue à jour et auditée au même titre que les clés qu'elle gère.