Au cœur de TeamPCP : comment Google a démantelé une campagne de supply chain depuis le chat central des hackers

Google infiltre TeamPCP et révèle une campagne supply chain visant l’open source, le vol d’identifiants, un exploit zero-day et plus de 1 000 entreprises.

Texte généré par intelligence artificielle, publié sans relecture humaine. Transparence IA

Au cœur de TeamPCP : comment Google a démantelé une campagne de supply chain depuis le chat central des hackers
Malware

Image d’illustration générée par IA

Google a surveillé TeamPCP depuis l’intérieur du groupe cybercriminel, alors que celui-ci compromettait des logiciels open source, récupérait les identifiants de développeurs et étendait ses activités à plus d’un millier d’entreprises. Cet accès a permis aux défenseurs de révoquer les éléments d’authentification volés, d’alerter les victimes et d’obtenir le code fonctionnel d’un exploit zero-day assisté par IA.

L’opération a également révélé un écosystème criminel fragmenté. TeamPCP s’est associé à ShinyHunters pour monétiser son accès, avant que le groupe partenaire ne s’approprie les identifiants volés, ne retienne les paiements et ne divulgue les messages internes de TeamPCP.

Deux Australiens, Ruben Ian Thomson et Louis Michael Gaebler, ont par la suite été arrêtés et inculpés. Les autorités les ont présentés comme des membres centraux de TeamPCP, mais cette attribution reste une allégation et le détail des chefs d’accusation n’a pas été rendu public.

Les paquets compromis servaient de passerelles vers les victimes suivantes

TeamPCP semble avoir fait son apparition publiquement à la fin de 2025. Sa campagne reposait sur un modèle de supply chain en cascade, dans lequel chaque intrusion réussie créait de nouvelles possibilités de compromission.

Les attaquants prenaient d’abord le contrôle d’un projet open source ou d’un éditeur de logiciels. Ils inséraient ensuite un malware destiné à dérober des identifiants dans le logiciel concerné, exposant les noms d’utilisateur, les mots de passe et les jetons d’accès des développeurs et des utilisateurs en aval.

TeamPCP pouvait utiliser ces éléments d’authentification pour pénétrer dans un autre projet, un environnement cloud ou une entreprise technologique. Le malware introduit dans le logiciel nouvellement compromis permettait de récupérer une nouvelle série d’identifiants, ce qui prolongeait le cycle.

Selon l’enquête de Google, la campagne a touché des centaines de paquets open source et permis de compromettre plus d’un millier d’entreprises. Parmi les produits et organisations concernés figuraient :

  • Trivy, un scanner de sécurité open source ;
  • LiteLLM, un outil d’API utilisé par des applications d’IA ;
  • l’entreprise de sécurité des applications web Checkmarx ;
  • TanStack, une bibliothèque pour applications web ;
  • Mistral AI et sa plateforme d’IA destinée aux entreprises ;
  • GitHub ;
  • l’entreprise spécialisée dans les contrats de données Mercor ;
  • des appareils appartenant à des employés d’OpenAI ;
  • des appareils appartenant à des employés de la Commission européenne.

D’autres victimes n’ont pas été nommées. Les paquets concernés, les numéros précis des versions malveillantes et les versions logicielles affectées n’ont pas non plus été divulgués, empêchant les organisations de s’appuyer sur une liste définitive des versions exposées.

TeamPCP a complété ces intrusions avec Mini Shai-Hulud, un ver à propagation autonome conçu pour automatiser son expansion dans les environnements de développement. Son nom faisait apparemment référence à Shai-Hulud, un autre ver associé à une technique de supply chain similaire en septembre 2025. Aucun lien entre TeamPCP, les suspects arrêtés et cette campagne antérieure n’a été établi.

Une identité d’infiltration a intégré le cercle fermé de CanisterWorm

Un analyste de Mandiant a approché TeamPCP en utilisant une identité en ligne fictive. Après avoir gagné la confiance d’une personne invitée à rejoindre l’organisation, l’analyste a été admis en mars dans CanisterWorm, un chat central réunissant environ 12 participants.

Austin Larsen, du Google Threat Intelligence Group, qui doit présenter l’enquête lors d’une conférence SentinelOne LABScon, n’était pas l’agent infiltré.

L’analyste a évité de participer aux attaques, de faciliter les intrusions ou d’encourager les membres de TeamPCP. L’identité fictive ne communiquait que lorsque cela était nécessaire pour préserver son accès et observait discrètement l’infrastructure, les discussions, les données volées et les projets futurs du groupe.

Cette position lui a donné accès à un serveur contenant des identifiants dérobés aux victimes. La collecte comprenait des mots de passe, des noms d’utilisateur et des jetons d’accès capturés lors des compromissions logicielles du groupe, ainsi que des éléments apparemment préparés en vue d’une extorsion.

Google s’est retrouvé face à un problème de confinement : contacter individuellement chaque propriétaire d’identifiants aurait laissé davantage de temps aux attaquants pour exploiter les accès volés. Les enquêteurs se sont donc tournés vers les fournisseurs capables d’invalider un grand nombre d’identifiants, notamment Amazon Web Services et Microsoft.

Le GTIG a envoyé des centaines d’avis aux fournisseurs et aux organisations touchées. Nombre de destinataires ont réagi immédiatement, ce qui a permis de révoquer les identifiants et les jetons avant qu’ils ne puissent servir à d’autres intrusions.

Cette stratégie donnant la priorité aux fournisseurs s’attaquait à une caractéristique fondamentale des incidents de supply chain. Un seul jeton de développeur volé peut affecter les dépôts, les publications de paquets, les systèmes de build et les ressources cloud de plusieurs organisations. Sa révocation au niveau du service permet donc de fermer plusieurs voies d’attaque simultanément.

L’IA a contribué à produire un contournement fonctionnel de l’authentification à deux facteurs

La surveillance interne a révélé qu’un autre membre de TeamPCP développait un exploit zero-day contre un produit de connexion largement déployé. L’attaquant utilisait un outil d’IA pour l’aider à créer du code capable de contourner le mécanisme d’authentification à deux facteurs du produit.

Google a obtenu l’exploit et l’a testé. Bien que les chercheurs aient dû apporter plusieurs modifications, le code a finalement fonctionné, démontrant une tentative d’exploitation assistée par IA contre une vulnérabilité inconnue jusque-là, dans le cadre d’une opération criminelle en cours.

Le développeur concerné a été informé et a corrigé la faille. Google a évoqué l’épisode dans une étude de cas publiée en mai, sans toutefois identifier TeamPCP ni révéler que ses enquêteurs avaient récupéré le code dans les communications du groupe.

Le nom du produit, le fournisseur, l’identifiant de la vulnérabilité et la version corrigée restent inconnus. Il n’existe donc aucun CVE public permettant aux organisations de suivre leur exposition, et aucune information publiée ne permet d’établir si la faille figure dans le catalogue Known Exploited Vulnerabilities de la CISA.

Ces omissions limitent la vérification indépendante et la remédiation ciblée. Les administrateurs ne peuvent pas déterminer, à partir des informations disponibles, s’ils utilisent la technologie de connexion concernée ni si une version précise installée contient le code corrigé.

L’incident illustre néanmoins un usage concret de l’IA dans le développement offensif. L’outil n’a pas supprimé la nécessité d’une intervention humaine, mais il a contribué à produire du code destiné à neutraliser une protection d’authentification critique.

ShinyHunters a retourné contre TeamPCP les accès volés par le groupe

Bien qu’il ait détenu, selon les allégations, les identifiants associés à plus d’un demi-million d’utilisateurs, TeamPCP peinait à transformer ses accès en revenus. Larsen estime que le groupe n’a tiré que quelques dizaines de milliers de dollars de ses activités d’extorsion, très loin des millions obtenus par des organisations criminelles plus expérimentées.

TeamPCP a donc proposé à d’autres groupes un accès à sa collecte d’identifiants, en échange d’une part des paiements d’extorsion générés. ShinyHunters, une organisation spécialisée dans le vol de données et l’extorsion particulièrement active, comptait parmi ses partenaires.

Vers le mois d’avril, quelques semaines après le début de l’accord, ShinyHunters a commencé à utiliser de manière indépendante les identifiants de TeamPCP et n’a pas versé la part convenue des recettes. Le groupe a également envoyé à Larsen une copie complète des messages stockés sur le serveur de TeamPCP, apparemment sans savoir que Google y avait déjà accès grâce à l’identité utilisée par Mandiant.

ShinyHunters s’est publiquement moqué de TeamPCP sur X. TeamPCP a réagi en limitant les adhésions, en transférant les informations volées vers un autre serveur et en excluant ShinyHunters ainsi que plusieurs autres participants de CanisterWorm.

L’identité infiltrée de Google a elle aussi été exclue. Les dirigeants de TeamPCP ont demandé aux membres restants de ne plus partager d’informations avec ShinyHunters.

Le conflit n’a pas mis fin à l’enquête de Google. Il a contraint l’opération à passer de l’observation directe à l’analyse de l’infrastructure, des archives de forums et des éléments d’attribution numérique.

D’anciennes archives de forums ont relié un pseudonyme à Ruben Ian Thomson

Des données divulguées provenant de comptes BreachForums ont associé l’une des identités les plus actives de CanisterWorm à l’adresse Gmail [email protected].

Google a consulté d’anciennes archives de forums et identifié un différend datant de 2019, opposant le pseudonyme « sheepstealing » à un vendeur de clés Microsoft Office piratées. Au cours du conflit, l’utilisateur a demandé un remboursement vers un compte PayPal associé à [email protected].

Les enquêteurs ont trouvé un autre lien après le déplacement du dépôt d’identifiants de TeamPCP. Des informations obtenues par l’intermédiaire d’un partenaire de confiance ont montré que le nouveau serveur était sauvegardé sur un compte Google Drive associé à [email protected].

Google a transmis les informations permettant d’identifier l’utilisateur au FBI. Larsen a indiqué qu’un agent avait répondu en quelques minutes. Environ un mois plus tard, les autorités américaines ont achevé la procédure judiciaire nécessaire pour obtenir auprès de Google les données du compte de Thomson.

La police australienne a ensuite arrêté Thomson à son domicile, dans une banlieue résidentielle. Louis Michael Gaebler a été arrêté dans le cadre de la même enquête. Les deux hommes étaient âgés d’une vingtaine d’années et la police fédérale australienne les a présentés comme des membres centraux de TeamPCP.

L’AFP ne les a pas identifiés dans son communiqué public, en raison des règles australiennes relatives à la vie privée. Aucun des deux hommes n’a souhaité faire de commentaire et le détail des chefs d’accusation n’a pas été communiqué. Le journaliste et enquêteur en cybersécurité Brian Krebs a également pu identifier Thomson de manière indépendante avant les arrestations.

Les défenseurs doivent considérer les identifiants de développeurs comme une exposition touchant l’ensemble de l’incident

Les organisations potentiellement touchées par TeamPCP ne peuvent pas compter sur une liste complète des paquets ou des versions concernées. Les efforts de défense doivent donc se concentrer sur les identifiants, l’intégrité des publications et les systèmes utilisés pour compiler et publier les logiciels.

Les mots de passe, clés d’API, jetons de dépôt et identifiants cloud exposés sur les postes de travail des développeurs doivent être renouvelés immédiatement. La révocation est préférable à un simple changement de mot de passe, car les jetons à longue durée de validité peuvent continuer à fonctionner indépendamment du mot de passe de l’utilisateur.

Les équipes de sécurité doivent également examiner :

  • les dépôts de code source, à la recherche de commits, de mainteneurs ou d’artefacts de publication non autorisés ;
  • les plateformes CI/CD, afin de détecter des workflows modifiés et des accès inconnus aux secrets ;
  • les registres de paquets, pour repérer les versions créées en dehors des procédures habituelles de publication ;
  • les terminaux des développeurs, à la recherche de vols d’identifiants et d’une activité liée à Mini Shai-Hulud ;
  • les environnements AWS et Microsoft, afin d’identifier les sessions créées avec des identifiants exposés ;
  • le stockage cloud, pour détecter les sauvegardes suspectes ou la synchronisation d’informations volées.

Les comptes de développeurs compromis doivent être désactivés jusqu’à ce que leur activité, leurs facteurs d’authentification et leurs jetons associés aient été examinés. Les organisations qui utilisent Trivy, LiteLLM, TanStack et les autres technologies citées doivent vérifier la provenance des paquets. Toutefois, en l’absence de versions divulguées, leur simple présence ne suffit pas à prouver une compromission.

Les actions de Google s’inscrivent dans une évolution plus large vers la perturbation directe des opérations, menée par sa Cyber Disruption Unit. Plutôt que de se limiter à publier des renseignements, l’entreprise a utilisé son accès pour invalider les ressources des attaquants, avertir les fournisseurs, protéger les victimes, sécuriser un correctif zero-day et faciliter l’attribution judiciaire.

L’enquête sous couverture sur TeamPCP montre à quel point une seule identité de développeur volée peut se propager dans les circuits modernes de distribution logicielle. Dans cette campagne, les paquets de confiance n’étaient pas de simples cibles : ils constituaient le moyen d’atteindre l’organisation suivante.

À lire aussi

Sources

Cet article est une réécriture originale fondée sur les sources ci-dessous.

Sujets liésTeamPCPsupply chaincybersécuritéGoogle Threat Intelligencelogiciels open sourcevol d’identifiantsexploit zero-day
Retour à l'accueil