Des journaux d'infostealers révèlent des milliers de jetons IA réutilisables capables de contourner la MFA

Un fichier de 7 Go a exposé les données d'authentification de 5 871 systèmes

Les infostealers fournissent de plus en plus aux cybercriminels des éléments plus utiles que des mots de passe : des jetons de session actifs et des clés API pour les services d'intelligence artificielle.

Les dernières découvertes ont attiré l'attention le 9 septembre 2026 et portent sur une archive de journaux d'infostealers de 7 Go publiée sur Telegram le 2 août 2026. Ce jeu de données contenait des informations collectées sur 5 871 machines infectées dans 162 pays.

L'analyse du dump d'infostealer par Okta a identifié 44 791 JSON Web Tokens uniques, ou JWT. Les enquêteurs ont évalué que 555 étaient probablement liés à l'authentification de services d'IA.

L'archive contenait également 2 937 structures JSON Web Encryption, connues sous le nom de JWE. La plupart étaient associées à OpenAI, qui utilise le framework d'authentification NextAuth.js. Bien que ces structures contiennent des JWT chiffrés, le chiffrement n'empêche pas nécessairement un attaquant de les réutiliser.

Le jour de l'apparition de l'archive, 1 843 JWT et JWE n'avaient pas encore expiré. Cela offrait à quiconque ayant accès au dump une fenêtre potentielle pour prendre le contrôle des comptes.

L'analyse par TruffleHog a révélé une autre catégorie d'identifiants exposés : 24 clés API qui restaient valides pour Google Gemini, OpenAI, Groq et OpenRouter. D'autres jetons dans le jeu de données correspondaient à Google, Microsoft, Anthropic, Amazon, Gamma, Notion, Character.ai, Cursor, Poe.com et Pika AI.

Il ne s'agit pas d'une vulnérabilité affectant une version logicielle spécifique. Aucune version de produit vulnérable ou correctif de sécurité n'est concerné. L'exposition résulte de l'extraction de données d'authentification depuis des terminaux compromis, qui sont ensuite réutilisées ailleurs.

Pourquoi un jeton volé peut rendre la MFA obsolète

Un jeton de session valide représente un événement d'authentification qui s'est déjà produit. Lorsqu'un service accepte ce jeton, il peut considérer la personne qui le présente comme un utilisateur authentifié, sans redemander de mot de passe ni d'authentification multifacteur.

Cela modifie l'objectif de l'attaquant. Plutôt que de vaincre la MFA lors de la connexion, l'attaquant vole l'artefact créé une fois que la MFA a réussi.

Les JWT transportent généralement des revendications utilisées par les applications pour identifier les utilisateurs, les sessions, les autorisations, les émetteurs, les audiences et les délais d'expiration. Dans l'archive analysée, 17,7 % des 44 791 JWT contenaient également des informations d'identification personnelle en texte clair, dont des noms, des numéros de téléphone ou des adresses e-mail.

Cela crée deux risques distincts. Un jeton peut autoriser l'accès au compte tant qu'il reste valide, et son contenu lisible peut exposer des données d'identité même après l'expiration du jeton.

Les JWE masquent leurs revendications internes par le chiffrement, mais cela ne les rend pas inoffensifs. Un attaquant n'a pas nécessairement besoin de déchiffrer un JWE volé si le service qui le reçoit peut le faire. Si le jeton reste valide et est accepté en tant que jeton porteur, réutiliser l'objet chiffré permet tout de même de restaurer la session de la victime.

Les clés API posent un problème similaire. Elles autorisent souvent un accès programmatique direct plutôt qu'une connexion interactive via un navigateur. Un attaquant disposant d'une clé valide peut potentiellement consommer les ressources du modèle, invoquer des API ou exécuter des charges de travail automatisées sous le compte et les limites de facturation de la victime.

Les passkeys ne résolvent pas cette étape de l'attaque. L'authentification résistante au hameçonnage peut empêcher de nombreuses compromissions de mots de passe et de connexions par hameçonnage, mais elle n'invalide pas automatiquement les données de session ni les secrets d'API copiés depuis un appareil infecté.

Les navigateurs anti-détection facilitent la réutilisation des sessions volées

La réutilisation d'un jeton de session n'est pas toujours aussi simple que de coller une chaîne de caractères dans un navigateur. Les applications peuvent dépendre de plusieurs cookies, de valeurs de stockage du navigateur et de caractéristiques environnementales qui doivent être reconstituées ensemble.

Les attaquants utilisent des outils tels que le navigateur anti-détection open source Camoufox et le framework d'automatisation de navigateur SeleniumBase pour importer les données sessionStorage et localStorage volées à partir de fichiers. Cela permet de reconstituer suffisamment l'état du navigateur de la victime pour qu'un service reconnaisse la session existante.

L'infrastructure proxy permet de réduire les écarts visibles. Si un jeton volé apparaît soudainement depuis un pays lointain ou un réseau inconnu, les règles de détection de voyage impossible (impossible-travel) et autres contrôles de risques peuvent se déclencher. L'acheminement de la réutilisation via une adresse plus proche de la localisation attendue de la victime peut rendre l'activité moins perceptible.

La détection comportementale reste possible. Les nouveaux appareils, les modèles d'utilisation inhabituels, la consommation anormale du modèle et l'utilisation simultanée du jeton peuvent tous fournir des signaux. Cependant, l'attaquant commence la session avec un artefact valide plutôt qu'avec un mot de passe manifestement incorrect.

Jeremy Kirk, directeur du renseignement sur les menaces chez Okta, a qualifié les jetons de session et les clés API de très prisés, car ils permettent de contourner l'authentification par identifiants. Une fois la réutilisation réussie, l'attaquant est effectivement à l'intérieur du compte LLM sans avoir eu à effectuer de connexion conventionnelle.

Les familles de malwares mentionnées en lien avec cette activité incluent Lumma Stealer et Vidar. Les informations disponibles n'identifient pas quelle famille a infecté chacune des 5 871 machines, ne révèlent aucune victime individuelle et ne fournissent aucun indicateur public concernant les terminaux concernés.

L'accès volé à l'IA est devenu un produit commercial

Les journaux d'infostealers sont vendus sur des forums clandestins et des plateformes de messagerie, mais le marché se spécialise. Certains services criminels regroupent désormais des jetons volés avec des profils de navigateur ou des configurations anti-détection visant à simplifier l'accès aux comptes.

Okta a identifié un vendeur sur Telegram faisant la promotion d'un accès à prix réduit à Claude, Cursor, ChatGPT et Gemini. Le vendeur mettait en avant un support continu et des garanties de remboursement, un vocabulaire conçu pour faire ressembler l'accès illicite à un service d'abonnement classique.

Une autre opération se faisant appeler « Poison Claude » prétend vendre un accès aux modèles d'Anthropic identifiés sous les noms d'Opus 4.8, Opus 4.7, Opus 4.6 et Sonnet 4.6. Il s'agit d'affirmations de la part du vendeur, et aucune validation indépendante de l'accès annoncé n'a été divulguée.

Le Google Threat Intelligence Group a observé un nombre croissant d'acheteurs et de vendeurs échangeant des comptes liés à l'IA au sein des communautés cybercriminelles. La demande porte sur les identifiants de Claude et Gemini, ainsi que sur des environnements de codage autonomes tels que Cursor Pro et Devin.

L'utilisation potentielle va au-delà d'un accès peu coûteux à un chatbot. Les comptes volés peuvent exposer des conversations privées, des documents téléchargés, du code généré, des requêtes propriétaires et d'autres informations conservées sur les plateformes d'IA.

L'abus d'API permet également le vol de ressources, parfois décrit sous le nom de LLMjacking. Le modèle s'apparente au minage illicite de cryptomonnaies : les attaquants exécutent une activité gourmande en calculs tout en reportant les frais d'infrastructure ou d'utilisation sur la victime.

Mandiant a rencontré une version plus vaste de ce problème lors d'une mission de réponse aux incidents. Un acteur de la menace est entré dans l'environnement cloud d'une victime en utilisant un GitHub Personal Access Token exposé, puis a déployé une infrastructure d'IA non autorisée et a augmenté les ressources de calcul à haute performance.

Des conséquences allant de la fraude à la facturation à l'espionnage d'entreprise

Pour les particuliers, la prise de contrôle de compte peut exposer les conversations personnelles et les informations d'identité. Les données d'identification personnelle en texte clair trouvées dans certains JWT peuvent également faciliter des campagnes de hameçonnage ciblé, d'usurpation d'identité et d'ingénierie sociale.

Les conséquences pour les entreprises sont plus vastes. Un attaquant pourrait accéder à des requêtes sensibles, des documents internes, du code source, du matériel client ou des recherches soumises à un service d'IA. Les comptes compromis pourraient également être revendus ou utilisés comme point d'ancrage pour l'extorsion et l'espionnage.

L'impact financier peut s'accumuler rapidement lorsque des clés API volées permettent des requêtes automatisées. Même si l'attaquant ne peut pas accéder aux données stockées, la consommation du budget de jetons ou de l'allocation de calcul cloud de la victime engendre un coût direct.

La présence de données d'authentification provenant de 162 pays montre que le phénomène n'est pas limité à une région ou à un service. Cependant, le nombre de jetons réutilisés avec succès n'est pas connu. Il est également impossible de savoir combien de comptes exposés étaient des abonnements personnels, des comptes de développeurs ou des identités gérées par l'entreprise.

Les défenses doivent protéger les sessions autant que les connexions

Les organisations doivent surveiller l'apparition d'un même jeton de session depuis des adresses IP, des appareils ou des emplacements inattendus. Une utilisation simultanée depuis différents environnements, des changements brusques dans les caractéristiques du navigateur et une consommation d'IA inhabituelle peuvent également indiquer une réutilisation.

L'utilisation de listes d'autorisation IP peut restreindre l'accès aux réseaux approuvés, en particulier pour les fonctions administratives ou d'API. Ce n'est pas une défense complète, car les attaquants peuvent utiliser des proxies ou compromettre une infrastructure se trouvant dans une plage autorisée.

Les clés API doivent disposer d'autorisations strictement définies, de quotas d'utilisation et d'une surveillance continue de la consommation. Les clés suspectes doivent être révoquées et remplacées, tandis que les sessions de navigateur concernées doivent être terminées pour invalider les données volées.

Les déploiements OAuth 2.0 devraient privilégier des jetons d'accès à courte durée de vie, réduisant ainsi la période pendant laquelle un jeton copié reste utile. Les identifiants à longue durée de vie créent une fenêtre de réutilisation plus large après la compromission d'un terminal.

Les Device Bound Session Credentials de Chrome offrent une contre-mesure plus directe. La technologie DBSC lie cryptographiquement les identifiants de session à un appareil, empêchant un jeton exporté d'être accepté sur un autre système.

La sécurité des terminaux reste centrale, car le vol commence sur la machine de l'utilisateur. Les passkeys peuvent renforcer la connexion, mais les entreprises qui adoptent des services d'IA doivent également inventorier les secrets d'API, contrôler les sessions de navigateur et considérer les infections par des infostealers comme une compromission potentielle de chaque compte cloud et d'IA actif sur l'appareil.