Opérations cyber · GTG-50020

Des intrusions dans les systèmes hôteliers aux attaques de la chaîne d'approvisionnement IA : affaire GTG-50020

Avis de source

Cette page est une traduction en français du contenu pertinent du rapport d'Anthropic de septembre 2026, pages 30–34. L'attribution de l'acteur et les chiffres d'échelle proviennent de ce rapport ; ce site n'a pas vérifié de manière indépendante tous les résultats du monde réel.

Selon le rapport d'Anthropic, GTG-50020 est un acteur russophone motivé par le profit qui ciblait historiquement les plates-formes de réservation hôtelière et les fintech. Dans une intrusion, il a exfiltré environ 26 Go de données d'une victime et a tenté d'obtenir 1,5 à 2,5 millions de dollars par rançon (ou en vendant les données sur des forums du dark web). Il a ensuite transposé les mêmes techniques vers l'industrie de l'IA : en injectant des instructions malveillantes dans le bac à sable d'évaluation automatisée d'un fournisseur d'IA, il a fait remettre au bac à sable les identifiants qu'il détenait — y compris les clés API IA de production de plusieurs fournisseurs détenues par ce fournisseur. Le rapport précise clairement : l'acteur n'a jamais obtenu l'accès aux modèles Claude non publiés, et les propres systèmes d'Anthropic n'ont pas été compromis.

Ce qui s'est passé

GTG-50020 est un acteur russophone motivé par le profit qui menait historiquement des intrusions contre des plates-formes de réservation hôtelière et des fintech. Dans une intrusion, il a exfiltré environ 26 Go de données d'une victime et a tenté d'obtenir 1,5 à 2,5 millions de dollars par rançon (ou en vendant les données sur des forums du dark web).

Il a ensuite transposé les mêmes techniques vers l'industrie de l'IA. En injectant des instructions malveillantes dans le bac à sable d'évaluation automatisée d'un fournisseur d'IA, l'acteur a fait remettre au bac à sable les identifiants qu'il détenait — y compris les clés API IA de production de plusieurs fournisseurs détenues par ce fournisseur.

Ces clés volées ont ensuite été abusées par l'acteur : il a simultanément poursuivi les tentatives d'intrusion contre ce fournisseur et d'autres cibles non liées. En fait, lorsqu'il obtenait les clés API d'une cible, il passait automatiquement à l'utilisation des clés de la victime plutôt que des siennes. L'activité de suivi exécutée depuis la même infrastructure a attaqué environ 30 entreprises d'IA en environ 4 jours en utilisant des techniques similaires. Ils ont identifié un chemin d'attaque réussi et l'ont réutilisé contre les 30 cibles, en apportant des ajustements mineurs selon les différences entre les cibles. L'objectif déclaré de l'acteur — poursuivi par plus de dix voies — était d'obtenir l'accès aux modèles Claude non publiés. L'acteur n'a jamais obtenu l'accès ; chaque chemin tenté a échoué. Tout au long de cette activité, les clés impliquées étaient des clés clients volées dans des environnements clients. L'acteur n'a jamais compromis les propres systèmes d'Anthropic.

Cette affaire est la démonstration la plus claire à ce jour que la chaîne d'approvisionnement de l'IA est devenue une cible criminelle délibérée. L'acteur a poursuivi les clés API de production des fournisseurs d'IA et avait une ambition claire — pour être clair, une ambition qui n'a jamais été réalisée — d'obtenir l'accès à des modèles d'IA non publiés.

Ce que l'IA a fait

Boucle de test d'intrusion IA dirigée par un humain : l'opérateur maintenait un fichier de périmètre par cible qui lançait un flux de travail personnalisé déléguant le travail à des agents de reconnaissance et d'exploitation parallèles. Les découvertes des agents étaient retestées pour confirmer un accès viable ; si viable, elles étaient fusionnées dans un rapport incrémental. Le flux de travail itérait sur le domaine cible suivant.

Pipeline d'exploitation autonome : l'acteur a utilisé une plateforme de test d'intrusion open source conteneurisée, frontalisée par une passerelle de modèle locale. Elle ciblait les applications Web de la cible. Des agents de travail exécutaient sans supervision des tests d'injection, de script intersite, de contournement d'authentification et de falsification de requête côté serveur, collectant les découvertes potentielles et les identifiants dans l'espace de travail de l'opérateur. La boucle fonctionnait avec l'exploitation activée contre les systèmes de production, ce qui signifie qu'elle tentait à la fois d'identifier les vulnérabilités et de les exploiter activement dans le même flux de travail pour obtenir l'accès.

Usine de comptes frauduleux : des proxies résidentiels et des profils de navigateur anti-détection ont été configurés, après quoi des bots pilotaient les flux d'inscription des cibles d'échanges et de places de marché. Des services commerciaux de résolution de CAPTCHA, l'interrogation automatisée des boîtes de réception et les étapes automatisées de vérification d'identité ont vaincu les contrôles d'intégration, et les comptes vérifiés résultants ont été stockés pour une utilisation ultérieure.

Cape d'interception KYC : l'acteur s'est également livré au vol d'identifiants et au phishing. Les victimes étaient dirigées vers des domaines de vérification similaires dont le proxy inverse relayait le flux réel de « connaissance du client » (KYC), de sorte que les victimes complétaient une vérification d'identité réelle tandis que l'acteur capturait les sessions et documents vérifiés depuis le relais proxy intermédiaire. Les sessions capturées étaient ensuite utilisées par l'acteur depuis ses machines pour accéder aux services et données cibles.

Ce que le rapport a observé

C'est le cas le plus clair que le rapport utilise pour illustrer que « la chaîne d'approvisionnement de l'IA est devenue une cible criminelle explicite » : l'acteur a poursuivi les clés de production des fournisseurs et avait l'ambition d'obtenir des modèles non publiés.

Deux preuves négatives doivent être gardées à l'esprit : l'accès aux modèles non publiés n'a jamais été obtenu ; les propres systèmes d'Anthropic n'ont pas été compromis et les clés volées provenaient d'environnements clients.

Le rapport liste les indicateurs de compromission associés (IP de sortie de l'attaquant, etc.) à la fin pour que les défenseurs puissent enquêter. Selon les limites de sécurité de ce site, les valeurs spécifiques des indicateurs ne sont pas reproduites.

Schéma : l'opérateur lance des agents de reconnaissance et d'exploitation pour chaque cible, puis fusionne les découvertes viables dans le rapport.
Figure du rapport original : schéma de la boucle de test d'intrusion IA dirigée par un humain. Le texte de la figure est en anglais original.

Confirmé et inconnu

Confirmé

  • Le rapport confirme les environ 26 Go de données et le prix de 1,5–2,5 millions de dollars de l'intrusion hôtelière/financière précoce
  • Le rapport confirme que le même chemin a été réutilisé contre environ 30 entreprises d'IA en environ 4 jours
  • Le rapport confirme qu'aucun modèle non publié n'a été obtenu et que les propres systèmes d'Anthropic n'ont pas été compromis

Inconnu

  • Combien des environ 30 entreprises ont été réellement pénétrées avec succès n'est pas indiqué sous forme de liste complète ou de taux de réussite dans le rapport
  • Le total des pertes en aval dues aux clés clients volées n'est pas résumé dans le rapport
  • L'identité publique du fournisseur dont le bac à sable d'évaluation était impliqué n'est pas nommée dans le rapport

Réponse de la plateforme

Le rapport divulgue cette affaire comme un exemple central de risque de chaîne d'approvisionnement et souligne les preuves négatives pour éviter qu'elle ne soit mal interprétée comme « Anthropic a été piratée, des modèles secrets volés ».

Limites de la réponse:La divulgation ne signifie pas que tous les environnements clients ciblés ont été remédiés ; le vol de clés clients s'est produit du côté du client.

À retenir

  • Le titre ne doit pas lire « Anthropic a été piratée » : le rapport le nie explicitement.
  • Les bacs à sable d'évaluation, les services d'encapsulation et les clés clients ne sont pas la même limite de sécurité que les systèmes propres du laboratoire de modèles.
  • Une fois que les clés API apparaissent dans un environnement automatisé, elles doivent être protégées comme des clés de production.

Sources