Le 27 août 2026, l’Autorité fédérale de police australienne (AFP) a annoncé l’inculpation de deux hommes d’Australie-Occidentale pour leur rôle présumé dans TeamPCP chaîne d’attaque, un groupe de cybercriminalité soupçonné d’avoir orchestré de vastes compromissions de type supply chain. Les investigations ont mené à des perquisitions et à la saisie d’équipements informatiques pour analyse forensique.
Selon les autorités, le schéma viserait notamment des projets de sécurité open source, avec à la clé la récupération de jetons et d’identifiants utilisés pour pousser des versions « empoisonnées » via les canaux de publication. L’impact allégué s’étendrait à plus d’un millier d’organisations à travers plusieurs écosystèmes de distribution.
Qui est inculpé et sur quels fondements ?
D’après le communiqué de l’AFP, deux individus ont comparu devant le tribunal des magistrats de Perth, le 27 août, soit un jour après l’exécution de mandats de perquisition dans plusieurs localités, dont Cottesloe, Hamilton Hill et Mandurah. Les enquêteurs indiquent avoir saisi des dispositifs électroniques en vue de leur analyse.
Louis Michael Gaebler, 23 ans, et Ruben Ian Thomson, 21 ans, font face à quatorze infractions au total, réparties entre les deux accusés. Les autorités allèguent qu’ils occupaient des rôles centraux dans le groupe et qu’ils auraient été rémunérés en cryptomonnaies, dont la valeur exacte est encore en cours de vérification.
Parmi les chefs retenus, plusieurs portent sur la possession de données dans l’intention de commettre une infraction informatique, ainsi que sur des modifications non autorisées de données avec une intention criminelle. L’un des suspects est aussi visé par une infraction liée au non-respect d’une ordonnance, tandis qu’un chef d’accusation concerne l’« utilisation ou gestion » de produits de la criminalité au-delà d’un certain seuil.
Une chaîne d’attaque via des projets open source
Au cœur des accusations, on retrouve un mécanisme de compromission en cascade : le groupe aurait volé des identifiants de publication associés à des projets open source réputés, puis aurait diffusé des versions manipulées via leurs propres canaux de release. Autrement dit, l’attaque exploiterait la confiance inhérente au processus de publication des mainteneurs.
Le dispositif s’étendrait sur cinq écosystèmes de distribution : GitHub Actions, Docker Hub, npm, PyPI et OpenVSX. Une particularité décrite dans les éléments de l’enquête est la réutilisation d’accès : la compromission d’un projet aurait fourni les identifiants nécessaires pour passer au suivant.
Par exemple, les informations de publication obtenues lors d’une atteinte à un scanner auraient ensuite été utilisées dans des étapes ultérieures contre un autre composant, avec une temporisation rapprochée entre les phases.
Trivy, Checkmarx KICS et LiteLLM : la logique du « maillon suivant »
Les autorités et avis techniques pointent plusieurs briques mentionnées dans la campagne. D’un côté, des scanners de sécurité et de l’autre, une brique d’interface pour l’IA.
Dans la description fournie par l’enquête, un pipeline de construction associé à LiteLLM aurait installé un scanner de sécurité sans le « verrouiller » sur une version vérifiée. Une fois le scanner compromis, les jetons de publication du projet auraient pu être récupérés. Le groupe aurait ensuite utilisé ces jetons pour publier des versions altérées de LiteLLM à la fin du mois de mars.
LiteLLM, tel que présenté dans les éléments communiqués, oriente les requêtes entre fournisseurs de modèles de langage, et se situe là où les clés d’accès au fournisseur peuvent être consolidées. Cette position « sensible » augmente le risque, car l’outil peut servir de pivot lors de l’exploitation.
Pourquoi les données volées restent dangereuses
Un avis partagé par la division cyber du FBI insiste sur un point : même après l’identification initiale d’une compromission, les données extraites et les identifiants ne doivent pas être considérés comme « neutralisés ». Les acteurs associés pourraient les exploiter longtemps après l’accès initial.
La recommandation met l’accent sur plusieurs actions de durcissement, notamment le renouvellement des secrets CI/CD, la rotation des jetons exposés et la mise à jour des identifiants cloud accessibles pendant les fenêtres d’exposition. L’idée est de réduire la probabilité qu’un jeton réutilisé permette d’installer, d’actualiser ou de déclencher à nouveau des charges malveillantes.
Dans le même esprit, il est conseillé de traiter les flux d’intégration et de livraison continue comme des surfaces d’attaque critiques, en contrôlant soigneusement les droits d’accès et en limitant les expositions prolongées.
Volumes d’impact : chiffres annoncés et incertitudes
Les éléments d’enquête citent un impact potentiel très important. L’AFP affirme que le code malveillant aurait potentiellement compromis plus de 1 000 organisations à l’échelle mondiale. Elle mentionne également la perspective du vol de plus de 500 000 identifiants et l’exfiltration d’au moins 300 Go de données.
Ces estimations sont toutefois présentées avec prudence : d’autres analyses mentionnées dans le dossier, publiées plus tôt, parlent de ce que l’acteur aurait pu exfiltrer. Par ailleurs, des chiffres plus détaillés sont également évoqués par des acteurs de la sécurité, avec des reconstructions basées sur des jeux de données et des approches d’identification.
En résumé, la campagne serait associée à un grand nombre de pipelines et de domaines d’entreprises, mais le nombre exact de victimes confirmées dépend des méthodes de vérification et de la capacité à relier chaque exposition à une compromission effective.
GitHub Actions, Docker Hub, npm… comment la compromission se propage
L’affaire décrit une stratégie où les modifications malveillantes passent par les mécanismes habituels de publication. Concrètement, cela signifie que des systèmes automatisés — comme ceux qui récupèrent des images, des paquets ou des workflows — peuvent exécuter du contenu injecté si les contrôles ne détectent pas l’altération.
Le FBI conseille notamment de verrouiller les workflows GitHub Actions en s’appuyant sur des identifiants de commits vérifiés plutôt que sur des tags de version « flottants ». Cette différence peut sembler technique, mais elle devient cruciale lorsque l’attaquant a la capacité d’influencer les artefacts distribués.
Au-delà des plateformes, la logique reste la même : l’attaquant vise le moment où l’écosystème de déploiement fait confiance à un artefact publié.
État des paquets et traçabilité après retrait
Le 27 août 2026, des vérifications rapportées indiquent que les deux versions malveillantes de LiteLLM ne figurent plus dans l’historique de releases sur PyPI. Toutefois, un point particulier ressort : malgré leur retrait de l’index, des requêtes vers leurs adresses directes au réseau de diffusion de contenu (CDN) continueraient à répondre avec un code HTTP 200 après suppression.
Cette situation illustre un enjeu récurrent en incident response : retirer un paquet ne suffit pas forcément à neutraliser immédiatement toutes les traces d’accès ou toutes les capacités de récupération depuis des emplacements indirects (par exemple via un CDN). Les équipes doivent donc évaluer les risques non seulement au moment du retrait, mais aussi pendant la période où l’artefact reste accessible.
Des liens historiques et des signaux de réutilisation
Le dossier mentionne également des éléments de continuité : selon un rapport publié le 5 août, l’infrastructure attribuée à TeamPCP remonterait à 2020. Les analyses établissent des correspondances avec d’autres activités déjà observées, notamment via des domaines se chevauchant, des chemins de déploiement et des techniques de staging.
Pour autant, les auteurs du rapport soulignent qu’il n’est pas possible de déterminer avec une certitude absolue s’il s’agit d’un changement de nom, d’un ensemble d’opérateurs partagé ou d’une collaboration étroite entre acteurs historiquement liés.
Dans la même période, il est indiqué que le groupe aurait publié sur GitHub un framework de type « worm » associé à une campagne précédemment connue. Plus récemment, une vague sur npm utilisant un toolkit similaire aurait visé des paquets particuliers, sans retrouver certains marqueurs permettant une identification directe.
Ce que les organisations peuvent retenir
Au-delà de l’actualité judiciaire, cette affaire met en évidence un enseignement majeur pour les équipes sécurité et engineering : lorsqu’un attaquant obtient des identifiants de publication, la chaîne automatisée de déploiement devient un vecteur de diffusion, et la compromission peut se propager en plusieurs étapes.
Pour réduire les risques, les recommandations techniques évoquées dans les avis insistent sur la rotation des secrets exposés, la limitation des fenêtres d’accès, et le verrouillage de la provenance des artefacts (notamment les références de workflows). Ajoutez à cela une surveillance attentive des pipelines CI/CD et la capacité à investiguer rapidement l’usage d’identifiants suspects.
Conclusion
Les inculpations annoncées par l’AFP confirment que TeamPCP chaîne d’attaque n’est pas uniquement une affaire d’artefacts techniques : c’est aussi une opération criminelle supposée, structurée autour de la confiance dans les flux open source et de la capacité à publier du code altéré. Les autorités décrivent une campagne en plusieurs maillons, soutenue par des identifiants volés et une diffusion à travers des écosystèmes populaires.
Pour les organisations concernées ou potentiellement exposées, le message est clair : il faut agir sur la durée, traiter les identifiants et données extraits comme un risque persistant, et renforcer la chaîne CI/CD pour empêcher qu’une compromission initiale ne devienne une propagation durable.
Source: https://thehackernews.com/2026/08/alleged-teampcp-hackers-charged-in.html
