Se connecter sans avoir à saisir ses identifiants

Introduction

Le prix des tokens d’IA et des abonnements augmente, car les fournisseurs de modèles d’IA cherchent à rentabiliser leurs investissements. Par conséquent, ces comptes deviennent des cibles de plus en plus prisées des attaques d'usurpation de compte. Mettre un terme à cette situation est essentiel pour les entreprises. Le vol d’IA fait grimper la facture des tokens.  Dans trois cas récents, le vol d'une clé API a coûté près de 1 million de dollars à une entreprise, une facture salée de 25 000 $ à un architecte logiciel et 600 000 $ de crédits IA à une organisation de tests d’IA. Certaines entreprises spécialisées dans l’IA détectent ces abus et déconnectent automatiquement les personnes concernées tout en supprimant les cartes de paiement enregistrées afin de limiter les conséquences. Les développeurs de malware et les opérateurs de phishing manifestent un intérêt pour l’application de l’IA à leurs activités, et il a été constaté que des attaquants utilisent des inférences d’IA dérobées.

Notre précédente étude, « Des tokens gratuits à vendre : comment les fausses inscriptions alimentent la fraude à l’IA », analysait des services d’IA à prix cassés qui proposent des tokens d’IA à des tarifs anormalement bas. Ces services enfreignent les conditions d’utilisation des fournisseurs d’IA, ce qui entraîne une perte de revenus.

Dans la seconde partie de notre étude, nous analysons les activités explicitement illégales dans ce domaine, à savoir la disponibilité et la vente de secrets liés à l’authentification qui pourraient être utilisés pour détourner des comptes d’IA. Ce type d'usurpation de compte est rendu possible par la prolifération de malwares spécialisés dans le vol d’informations, appelés infostealers. Les données collectées par les infostealers se retrouvent en vente sur des forums cybercriminels et des plateformes de messagerie, commercialisées sous forme de « logs » ou de lots complets de données liées à l’authentification. 

Pour notre étude, nous nous sommes concentrés spécifiquement sur les tokens de session et les clés API des fournisseurs d’IA. Les tokens de session et les clés API sont particulièrement recherchés par les cybercriminels, car il est souvent possible de rejouer ces secrets pour contourner l’authentification basée sur des identifiants. Une fois le relecture réussie, un cybercriminel est effectivement connecté à un service LLM sans s’être réellement connecté. L’utilisation de ces passe-partout rend la détection de ces abus plus difficile, mais pas impossible.

Recherche dans des dépôts d'identifiants

Les opérateurs et opératrices d’infostealers recueillent un volume de données si important que certains vendeurs du Dark Web en publient une partie gratuitement. Les cadeaux promotionnels servent d’aperçu pour attirer davantage de clients vers des offres d’abonnement hebdomadaires ou mensuelles.

Nous avons analysé un lot de journaux gratuits publiés sur un canal Telegram le 2 août 2026. Cette extraction comprenait 5871 dossiers totalisant 7 Go de données, chaque dossier correspondant à une machine infectée. Comme indiqué ci-dessous, chaque dossier contenait des sous-dossiers et des fichiers comprenant des éléments liés à l’authentification, tels que des identifiants de connexion, des tokens de session, des clés API et d’autres informations.

Google, Microsoft et Amazon utilisent une passerelle d’authentification unique pour l’ensemble de leurs services, de sorte que les chiffres correspondent aux principaux tokens d’authentification définis par ces services. L’ordre dans lequel ces services apparaissent n’a pas pour but de refléter leur popularité, mais plutôt la fréquence de chacun dans cet ensemble de données particulier.

JSON Web Tokens

Certains services web émettent des JSON web tokens (JWT) vers le navigateur de l’utilisateur ou de l’utilisatrice après authentification, afin que différents serveurs puissent confirmer directement les autorisations d’une personne authentifiée sans interroger une base de données de session centralisée à chaque requête. Ces tokens sans état, signés de manière cryptographique, contiennent des données encodées qui décrivent les autorisations de la personne détentrice. Cela contraste avec un token de session, qui est généralement une chaîne utilisée côté serveur pour extraire les autorisations et préférences des utilisateurs et utilisatrices. 

Comme un token de session, un JWT valide peut accorder un accès direct au compte. Accéder à un compte de cette manière contourne l’authentification habituelle par identifiant et mot de passe, ainsi que les vérifications MFA.

Les JWT sont la cible des infostealers. Cependant, tous les JWT ne sont pas liés à l’authentification, et tous ceux présents dans l’ensemble de données n’étaient pas associés à des services d’IA. Sur les 44 791 JWT uniques du jeu de données, 555 JWT ont été identifiés comme probablement liés à l’authentification pour des services d’IA. 

Les JWT peuvent contenir un champ « iat », qui signifie « émis à », ainsi qu’un champ « exp. » qui est une date d’expiration. Les JWT peuvent être valides pendant quelques semaines, plusieurs mois, voire plusieurs années. La plupart des JWT étaient des tokens à durée de vie courte, valides pendant quelques minutes à une heure avant d’expirer. Ces tokens de courte durée sont générés par des tokens d’actualisation à durée de vie plus longue, associés à un attribut HTTPonly afin d’éviter tout vol par un JavaScript malveillant. Cependant, des malwares peuvent toujours dérober ces tokens. Dans le cas des applications monopage (SPA), les JWT sont stockés dans le LocalStorage ou le SessionStorage du navigateur, ce qui peut entraîner un vol de ces données.

Une recherche distincte a permis d’identifier 2937 JWE liés à l’authentification (JSON Web Encryption), qui sont des JWT chiffrés. La plupart de ces éléments ont été définis par OpenAI, qui utilise NextAuth.js. Seule la partie détenant la clé peut déchiffrer et lire ces JWE. Cependant, les tokens pourraient potentiellement être réutilisés par une personne malveillante pour accéder à un compte s’ils n’ont pas expiré. Lorsque l’ensemble de données d’infostealer a été publié le 2 août 2026, 1843 JWT et JWE n’avaient pas encore expiré.

Il existe un inconvénient aux JWT. Les JWT peuvent contenir des informations personnelles, telles que des noms, des adresses e-mail et des numéros de téléphone. Sur les 44 791 JWT, y compris les tokens d’authentification et les autres, identifiés dans l’ensemble de données, 17,7 % contiennent des informations personnelles identifiables (PII) en clair, telles que le nom, le numéro de téléphone ou l’adresse e-mail. Il s’agit d’un autre aspect problématique, car ces informations ne disparaissent pas et n’expirent pas, et elles relient directement un utilisateur à un service spécifique, ce qui pourrait être exploité lors de tentatives de social engineering ou de phishing.

Clés API

Les clés API peuvent être générées depuis les tableaux de bord des fournisseurs d’IA et ajoutées dans un fichier de configuration pour être utilisées par un outil comme OpenClaw. Déposer une clé API en texte brut dans un fichier de configuration ou la définir comme variable d’environnement permet de démarrer rapidement. Mais un flux OAuth 2.0 constitue une méthode plus sécurisée pour procéder ainsi, car l’application cliente ne reçoit que des identifiants d’accès à durée de vie limitée, tandis qu’un token d’actualisation reste stocké en toute sécurité dans le trousseau système ou dans un gestionnaire de mots de passe. De plus, OAuth permet de définir des autorisations d’accès limitées à un périmètre donné.

Les infostealers ciblent les secrets et identifiants en clair précisément parce qu’une clé API LLM volée est facile à monétiser, permettant à un acquéreur d’exécuter des inférences aux frais de quelqu’un d’autre. Certaines variantes recherchent les fichiers de configuration cachés. Les variantes plus récentes d'infostealer intègrent désormais des règles explicites de type regex ou glob pour détecter les clés API au format Anthropic ou OpenAI, ainsi que les chemins de configuration connus des outils d’IA.

TruffleHog a identifié 24 clés API encore valides dans notre ensemble de données, réparties sur quatre services liés à l’IA : Google Gemini, OpenAI, Groq et OpenRouter. Il existe des moyens de limiter les conséquences potentielles d’une clé volée. OpenAI, Anthropic et d’autres fournisseurs permettent aux utilisateurs de définir des plafonds d’utilisation sur les clés. Dans certains cas, les clés API peuvent être limitées par des politiques ou par une autorisation d’adresses IP. Mais sans ces contrôles, les clés pourraient être utilisées et entraîner des factures élevées de tokens d’IA.

Les outils des pratiques douteuses

Avec des sites web conçus par l’IA à l’apparence professionnelle, les fournisseurs d’IA du marché gris, dont les services enfreignent parfois simplement les conditions d’utilisation, peuvent sembler légitimes. Certains utilisateurs peuvent ne pas s’en rendre compte immédiatement. Cependant, de nombreux acteurs impliqués dans le vol et la revente de secrets d’authentification liés à l’IA ne cherchent pas à dissimuler leurs activités, comme le montre la capture d’écran ci-dessous.

Cependant, plusieurs facteurs peuvent influencer la capacité d’un cybercriminel à accéder effectivement à un compte en rejouant les informations de session après leur vol par un infostealer. Par exemple, une entreprise peut surveiller les dumps d’infostealers et, dès qu’elle détecte des identifiants ou des secrets appartenant à une personne utilisatrice, déclencher le verrouillage ou la réinitialisation du mot de passe des comptes compromis. Si une entreprise utilise la mise sur liste autorisée d’adresses IP, qui limite l’activité aux plages connues, un cybercriminel ne pourrait pas rejouer une session valide.

Nous n’avons pas constaté de preuve de vol de sessions Okta dans cette fuite de données. Mais il serait possible de détecter le détournement d’une session SSO Okta avec Identity Threat Protection (ITP) d’Okta. La fonctionnalité Session Protection d’ITP surveille en continu les sessions actives après l’authentification afin de détecter et d’empêcher le détournement de session. Elle réévalue les politiques chaque fois qu’un changement de contexte critique survient, comme un changement d’adresse IP ou d’appareil, ou lorsqu’elle reçoit des données de télémétrie sur les risques provenant d’outils de sécurité tiers via le Shared Signals Framework (SSF). Si une session semble risquée et a probablement été détournée, les administrateurs peuvent utiliser Universal Logout pour mettre fin aux sessions actives sur différentes applications SaaS. 

Des efforts ont été déployés pour empêcher les infostealers de dérober des données d’authentification à grande échelle. Le chiffrement lié à l’application (ABE) de Google, lancé en 2024, chiffre les données sensibles du navigateur, mais les développeurs de logiciels malveillants spécialisés dans le vol d’informations ont rapidement mis au point des solutions de contournement. Les identifiants de session liés à l’appareil (DBSC) associent de manière cryptographique un token de session à un appareil, afin que ce token ne puisse pas être utilisé sur d’autres appareils. DBSC n’en est toutefois qu’à ses débuts, car les services et sites web doivent mettre en place la compatibilité DBSC côté serveur. Certains navigateurs, comme Chrome 145 pour Windows, lancé en mars 2026, peuvent prendre en charge DBSC.

Conclusion

À mesure que l’accès aux modèles de pointe devient plus coûteux, la tentation de les dérober plutôt que de payer pour y accéder augmente également. Notre analyse d’un seul dump relativement modeste de données issues d’infostealers a révélé la présence de tokens de session liés à l’IA sur la majorité des machines infectées, dont beaucoup restaient valides plusieurs mois après leur collecte, ainsi que des clés API actives exposées en clair. Aucune compétence avancée n’a été nécessaire pour recueillir ces informations, qui sont accessibles gratuitement ou à l’achat.

L’authentification renforcée et l’utilisation de technologies résistantes au phishing, comme les passkeys, compliquent la prise de contrôle des identifiants et mots de passe, mais elles n’empêchent pas l’exploitation d’un token de session ou d’une clé API volés. Les personnes chargées de la défense doivent surveiller la réutilisation des tokens de session, limiter et définir le périmètre des clés API, et, lorsque cela est possible, utiliser des workflows OAuth 2.0 avec des tokens à durée de vie courte qui expirent rapidement en cas de vol. Aucun de ces contrôles n’est inhabituel, mais ils exigent que les entreprises et les utilisateurs traitent les tokens et les clés avec autant, voire plus d’attention, que les mots de passe des utilisateurs.

Avec le temps, une adoption plus large de DBSC aura un impact mesurable sur cet écosystème dynamique de l’accès. Pour l’instant, les entreprises doivent tout mettre en œuvre pour empêcher la réutilisation de ces passe-partout par un marché criminel qui ne cesse de perfectionner ses méthodes de vol et de revente.

Recommandations