De nouvelles analyses mettent en lumière une trajectoire particulièrement longue pour l’acteur de menace associé à TeamPCP. Les chercheurs expliquent que ses activités remonteraient à 2020, bien avant que le groupe ne soit publiquement associé à des attaques ciblant la chaîne logicielle. Cette continuité reposerait sur de nombreux recoupements techniques : domaines, chemins de déploiement des malwares, méthodes de préparation des charges, infrastructures en arrière-plan et habitudes d’exploitation.
Parmi les éléments les plus marquants, les attaques Redis TeamPCP apparaissent comme une brique récurrente d’accès à des environnements exposés sur Internet, au fil des campagnes observées. Et cette progression vers des opérations plus “cascadées” s’appuie sur l’abus de failles connues dans plusieurs technologies cloud natives.
Une activité attribuée à TeamPCP dès 2020
Les chercheurs d’Oligo Security, Avi Lumelsky et Gal Elbaz, soulignent que l’attribution s’appuie sur des liens opérationnels qui ne semblent pas relever du hasard. Ils évoquent notamment l’existence de recouvrements entre des domaines utilisés, des étapes de déploiement, des techniques de staging (préparation et distribution des charges), ainsi que des infrastructures de commande et contrôle.
Selon ces observations, l’acteur aurait compromis des composants “face à Internet” pendant des années, avant de se tourner vers des attaques contre la chaîne d’approvisionnement logicielle. Cette approche illustre une logique d’évolution : d’abord obtenir un accès durable, puis maximiser la portée des infections via l’écosystème de développement.
Des campagnes 2025 centrées sur l’IA et sur Redis
Dans la seconde moitié de 2025, deux campagnes sont mentionnées comme particulièrement révélatrices de l’orientation de l’acteur. La première, ShadowRay 2.0 (aussi désignée IronErn), viserait l’infrastructure liée à l’IA, avec l’objectif d’y intégrer des mécanismes de propagation menant à un botnet auto-diffusant.
La seconde campagne, TA-NATALSTATUS, s’attaque pour sa part à des serveurs Redis exposés. L’objectif rapporté est le déploiement de mineurs de cryptomonnaie sur les systèmes ciblés. Les attaques Redis TeamPCP s’inscrivent ainsi dans un schéma “accès via services exposés, puis monétisation via charges malveillantes”.
Un fil conducteur : l’évolution d’une campagne antérieure
TA-NATALSTATUS serait une évolution d’une campagne plus ancienne décrite par Trend Micro dès avril 2020. Dans ce précédent, l’idée consistait déjà à cibler des Redis accessibles pour y déployer des charges malveillantes. Le rapprochement suggère que l’acteur a exploité, tôt dans son historique, des services Redis et plus largement des briques d’infrastructure accessibles.
Les chercheurs indiquent que cette logique ne se limiterait pas à Redis : les cibles pourraient inclure des éléments autour de Ray, Docker, Redis et React, bien avant l’époque où l’acteur était associé, sous la bannière TeamPCP, à des opérations plus spectaculaires.
React, Next.js et l’opération PCPcat
Les premiers indices reliant l’acteur à ses techniques auraient émergé à la fin de l’année précédente, via des exploitations visant React Server Components (RSC) et Next.js. Le but serait de permettre l’extraction de données sensibles et de crédentiels depuis des environnements compromis.
Cette phase est connue sous le nom Operation PCPcat. L’intérêt ici n’est pas seulement la cible, mais la méthode : s’appuyer sur des composants applicatifs modernes et souvent déployés rapidement pour obtenir des accès et préparer la suite des opérations.
Un passage vers les environnements cloud natifs
Au début de l’année, une campagne plus large a été mise en avant par Flare. Les objectifs décrits consistent à construire une infrastructure distribuée de proxy et de scan, à compromettre des serveurs afin d’en exfiltrer des données, à déployer du ransomware, à pratiquer l’extorsion et à miner de la cryptomonnaie.
Autrement dit, l’acteur ne cherchait pas uniquement un accès isolé : il préparait des mécanismes d’exploration et de compromission à grande échelle, ce qui facilite ensuite la diffusion de charges malveillantes.
De l’accès à la chaîne logistique : l’abus des écosystèmes de développement
La progression vers des compromissions de chaîne logicielle s’explique, selon les analyses, par la capacité de l’acteur à exploiter la nature interconnectée des logiciels modernes. L’idée serait de poisonner des bibliothèques open-source populaires, en combinant l’abus de GitHub Actions et des techniques liées au vol de tokens.
Pour les chercheurs, un lien opérationnel particulièrement solide se trouve dans le recoupement entre des identités GitHub et GitLab observées lors de ShadowRay 2.0 et lors des infrastructures ultérieures associées à TeamPCP. En reliant des éléments comme les journaux d’authentification GitLab, des informations de commande et contrôle, des activités de reverse-shell et la préparation des charges malveillantes, ils concluent à un “pont” opérationnel direct entre les phases.
Exploitation automatisée et propagation
Les conclusions vont plus loin : les chercheurs indiquent que l’acteur aurait abusé à plusieurs reprises de failles connues affectant notamment React, Docker, Redis et Ray. L’objectif serait de s’appuyer sur des techniques automatisées et parfois “wormables” (capables de se propager), favorisant la continuité de la propagation sans intervention manuelle constante.
Dans ce cadre, le passage à des attaques en cascade contre la chaîne d’approvisionnement logicielle apparaît comme une extension logique. L’acteur peut alors profiter d’infrastructures cloud légitimes pour étendre l’impact avec des méthodes éprouvées.
Des variantes de malwares qui s’adaptent, y compris sur Kubernetes
Les analyses décrivent aussi des mises à jour continues de la “boîte à outils” malveillante. Un script Python nommé kube.py est notamment mentionné. Il serait utilisé après intrusion dans des environnements Kubernetes.
Les versions initiales du script auraient davantage mis l’accent sur la propagation et la persistance. En revanche, des variantes observées dès mars 2026 intégreraient des fonctions rapprochant le code de scénarios destructifs.
Fonction de type “wiper” et comportement conditionnel
Dans cette logique, une branche du code vérifierait si le système victime est configuré pour le fuseau horaire de l’Iran. Si c’est le cas, le malware déclencherait un DaemonSet (via une entité baptisée Kamikaze) pour effacer chaque nœud du cluster.
Sur des nœuds Kubernetes situés en dehors de ce fuseau, la charge déploierait un backdoor nommé CanisterWorm. Enfin, pour des systèmes non Kubernetes situés dans ce contexte, le malware exécuterait une routine baptisée poison_pill() destinée à supprimer l’ensemble du système de fichiers.
Une requalification possible, mais une continuité surtout démontrée
Les chercheurs prudencent l’interprétation : il est difficile d’affirmer avec certitude si ces changements reflètent un simple changement de marque, un ensemble d’opérateurs partagé, ou une collaboration entre acteurs historiquement liés. Oligo indique toutefois que les preuves montrent avant tout une continuité d’écosystème opérationnel.
Autrement dit, TeamPCP ne serait pas seulement un “nouvel acteur apparu fin 2025”. Les indices plaident plutôt pour l’idée d’une activité déjà en place depuis des années, avec des évolutions progressives et des moyens adaptés à différents environnements, y compris là où les attaques Redis TeamPCP permettent de démarrer des compromissions.
Ce que cela implique pour la sécurité
Pour les organisations, ces constats renforcent une réalité : la sécurité ne doit pas se limiter à “patcher quand une alerte sort”. Elle doit couvrir la réduction de surface d’exposition (services accessibles sur Internet), la surveillance des comportements de staging et de propagation, ainsi que des contrôles de sécurité autour des environnements cloud natifs.
Comme les campagnes combinent des failles applicatives (React/Next.js), des composants d’infrastructure (Redis, Docker, Ray) et des mécanismes plus avancés (Kubernetes et, plus tard, des vecteurs liés au développement), une défense en couches reste la meilleure approche.
En conclusion : l’historique attribué à TeamPCP suggère une opération qui s’étend bien au-delà d’une seule période. Les attaques Redis TeamPCP s’inscrivent dans un fil conducteur débutant dès 2020, avant une expansion vers des campagnes plus complexes, jusqu’aux compromis de chaîne logistique et à des charges destructrices.
Source: https://thehackernews.com/2026/08/teampcp-linked-to-redis-attacks-dating.html
