TeamPCP, des attaques contre Redis à la compromission de la chaîne d’approvisionnement

Une activité criminelle remontant au moins à 2020

Une analyse d’Oligo Security, publiée le 7 août 2026, relie TeamPCP à des activités de cybercriminalité ayant débuté au moins en 2020. Le groupe serait donc actif depuis plusieurs années, bien avant les campagnes récentes visant la chaîne d’approvisionnement logicielle.

Cette attribution repose sur le recoupement de domaines, d’infrastructures backend, de chemins de distribution des malwares, de techniques de staging et de modes opératoires. Oligo ne détermine toutefois pas s’il s’agit d’un changement de nom direct, d’un même groupe d’opérateurs ou d’une collaboration entre des acteurs déjà liés.

Les premières activités auraient ciblé des systèmes accessibles depuis Internet reposant sur Redis, Ray, Docker et React. En avril 2020, Trend Micro avait déjà documenté une campagne visant des serveurs Redis exposés, utilisés pour distribuer des malwares et des mineurs de cryptomonnaie.

ShadowRay 2.0 et TA-NATALSTATUS

Au second semestre 2025, deux campagnes attribuées au même écosystème opérationnel ont été observées.

La première, ShadowRay 2.0, également connue sous le nom d’IronErn, a ciblé des infrastructures d’intelligence artificielle afin de les transformer en botnet capable de se propager de manière autonome. La seconde, baptisée TA-NATALSTATUS, a visé des serveurs Redis exposés pour y installer des logiciels de minage.

La corrélation entre les identités GitHub et GitLab associées à IronErn et l’infrastructure ensuite attribuée à TeamPCP renforce ce lien. Oligo a comparé des journaux d’authentification GitLab, des activités de reverse shell, des serveurs de commande et contrôle ainsi que les différentes phases de staging du malware.

L’acteur aurait également exploité des vulnérabilités connues dans React, Docker, Redis et Ray, en combinant automatisation et techniques de propagation de type ver pour accélérer sa diffusion.

De l’exploitation de serveurs à la chaîne d’approvisionnement

Les premières informations publiques concernant cet acteur sont apparues vers la fin de l’année dernière, dans le cadre de l’opération PCPcat. Cette campagne aurait exploité des vulnérabilités dans React Server Components et Next.js afin de dérober des identifiants et des données sensibles.

Au début de l’année, Flare a décrit une campagne de grande ampleur visant des environnements cloud natifs. Les objectifs comprenaient la création d’infrastructures de proxy et de balayage, la compromission de serveurs, l’exfiltration de données, les rançongiciels, l’extorsion et le minage.

TeamPCP aurait ensuite transposé ces mêmes capacités à la chaîne d’approvisionnement logicielle au moyen de :

• la compromission des systèmes des développeurs ;
• l’empoisonnement de bibliothèques open source largement utilisées ;
• l’abus de GitHub Actions ;
• le vol et l’utilisation frauduleuse de jetons ;
• l’exploitation d’infrastructures cloud légitimes.

Cette évolution accroît le risque pour les organisations qui dépendent de pipelines automatisés et de packages tiers.

kube.py et le comportement destructeur sur Kubernetes

Parmi les outils observés figure le script Python kube.py, utilisé après la compromission d’environnements Kubernetes. Les premières versions visaient principalement la propagation et la persistance.

Des variantes détectées jusqu’en mars 2026 intègrent toutefois des fonctions proches de celles d’un wiper. Leur comportement dépend du fuseau horaire configuré sur le système :

• sur les clusters Kubernetes iraniens, le script crée un DaemonSet qui efface chaque nœud à l’aide du wiper Kamikaze ;
• sur les nœuds Kubernetes situés hors d’Iran, il déploie la porte dérobée CanisterWorm ;
• sur les systèmes iraniens qui ne reposent pas sur Kubernetes, il exécute poison_pill(), conçue pour effacer l’intégralité du système de fichiers.

L’impact potentiel comprend donc le vol d’identifiants et de données, le minage, les rançongiciels, l’installation de portes dérobées et la destruction complète de l’infrastructure.

Ce que les organisations doivent vérifier

Aucun correctif spécifique, aucune version corrigée, aucun indicateur de compromission ni aucune règle YARA n’a été communiqué. Les organisations doivent donc concentrer leurs contrôles sur les surfaces identifiées par l’analyse :

• les serveurs Redis, Ray et Docker directement exposés à Internet ;
• les clusters Kubernetes et les activités anormales de DaemonSet ;
• les pipelines GitHub Actions et GitLab ;
• les jetons utilisables par des systèmes automatisés ;
• l’installation ou la modification inattendue de packages open source ;
• les connexions vers des infrastructures de commande et contrôle ;
• les processus de reverse shell et les scripts tels que kube.py ;
• les suppressions anormales de nœuds, de systèmes de fichiers ou de ressources cloud.

Les versions exactes des produits vulnérables et les procédures de remédiation spécifiques ne sont pas connues. Il est donc nécessaire de tenir à jour l’inventaire des actifs, de réduire l’exposition à Internet, de faire tourner les jetons et de surveiller les pipelines de développement.