Les chercheurs de Flare ont identifié un acteur malveillant connu sous le nom de « TeamPCP », à l’origine d’une campagne à grande échelle visant les infrastructures cloud natives en exploitant des interfaces d’orchestration et de gestion exposées.
Observée pour la première fois fin 2025, l’activité témoigne d’un mouvement plus large délaissant les attaques visant les terminaux au profit de l’exploitation systématique des plans de contrôle cloud.
« Cette campagne est le sombre reflet des marchés légitimes. De même que les entreprises modernes peuvent passer à l’échelle à partir d’une seule personne épaulée par l’IA et l’automatisation, les acteurs malveillants motivés par l’appât du gain adoptent des modèles opérationnels similaires », a déclaré Assaf Morag, chercheur en cybersécurité chez Flare, dans un e-mail adressé à eSecurityPlanet.
Il a ajouté : « En s’appuyant sur l’IA, ils combinent des vulnérabilités récemment divulguées (react2shell) avec des méthodes d’accès initial éprouvées, fondées sur des erreurs de configuration cloud native, et transforment rapidement les accès compromis en produits commercialisés sur les marchés clandestins. »
La campagne TeamPCP
La campagne TeamPCP montre comment des services cloud mal configurés peuvent être transformés en plateformes d’attaque capables de s’auto-propager.
Plutôt que de s’appuyer sur l’hameçonnage ou sur des zero-day exploits, le groupe cible systématiquement les API Docker exposées, les clusters Kubernetes, les tableaux de bord Ray, les serveurs Redis et les applications web vulnérables à CVE-2025-29927.
Une fois l’accès initial obtenu, les charges de travail compromises sont reconverties en scanners, nœuds proxy, infrastructures de cryptominage et points d’exfiltration de données, ce qui permet à l’opération de prendre rapidement de l’ampleur.
Les chercheurs ont observé la première opération identifiée du groupe — suivie sous le nom de campagne PCPcat — qui a atteint son pic vers le 25 déc. 2025.
Au moins 185 serveurs ont été confirmés comme compromis durant cette phase, d’autres indicateurs laissant penser que l’exposition réelle dépassait largement les hôtes observés.
Le calendrier et l’ampleur de l’activité indiquent une campagne coordonnée et automatisée plutôt qu’une exploitation opportuniste isolée.
Au cœur de la chaîne d’attaque de TeamPCP se trouve un haut degré d’automatisation fondé sur des techniques connues plutôt que sur un logiciel malveillant inédit.
Le groupe exploite des plans de contrôle cloud non authentifiés ou faiblement protégés pour déployer des charges utiles standardisées, notamment un script shell appelé proxy.sh.
Ce script installe des utilitaires de tunneling et de proxy, déploie des composants de scan supplémentaires et assure la persistance en enregistrant des services système, transformant ainsi chaque serveur compromis en participant actif de l’opération globale.
Lorsque le logiciel malveillant détecte un environnement Kubernetes, il suit un chemin d’exécution propre au cluster en déployant une charge utile secondaire, kube.py.
Ce composant répertorie les pods et les espaces de noms, exécute des commandes sur les charges de travail accessibles et installe un DaemonSet privilégié qui permet de conserver un contrôle persistant sur l’ensemble du cluster.
Ainsi, un simple point d’ancrage peut servir à convertir un cluster Kubernetes entier en botnet distribué utilisé pour le scan et la poursuite de l’exploitation.
TeamPCP exploite également les vulnérabilités React2Shell des applications React et Next.js pour obtenir l’exécution de code à distance, dérober des identifiants et des données sensibles, puis déployer des charges utiles supplémentaires afin de maintenir l’accès.
Réduire les risques dans les environnements cloud
Des campagnes comme celle de TeamPCP montrent à quelle vitesse des environnements cloud mal configurés peuvent être exploités lorsque les plans de contrôle sont exposés ou insuffisamment surveillés.
Comme ces attaques reposent sur l’automatisation et les déplacements latéraux plutôt que sur des exploits inédits, une défense efficace exige une approche multicouche, adaptée au cloud natif.
- Sécurisez les plans de contrôle cloud en limitant l’accès à Docker, Kubernetes, Redis et Ray API grâce à l’authentification, à la segmentation réseau et à des règles de pare-feu.
- Appliquez le principe du moindre privilège à toutes les identités cloud, aux comptes de service et aux pipelines CI/CD, et empêchez l’intégration de secrets dans les images ou les fichiers d’environnement.
- Limitez les déplacements latéraux et le rayon d’impact en segmentant les environnements cloud et en appliquant des règles strictes d’admission et d’exécution aux conteneurs et aux charges de travail.
- Surveillez l’activité du plan de contrôle et le comportement, ainsi que le trafic réseau sortant afin de détecter les déploiements non autorisés, le scan, le cryptominage et les activités de commande et de contrôle.
- Renforcez la sécurité de la chaîne d’approvisionnement des conteneurs en imposant la signature des images, le recours à des registres de confiance et le scan continu des images et de l’infrastructure sous forme de code.
- Identifiez de manière proactive les expositions en analysant en continu les environnements cloud à la recherche d’interfaces d’orchestration accessibles au public et de services mal configurés.
- Testez et améliorez les plans de réponse aux incidents au moyen d’exercices réguliers sur table afin de garantir l’isolation rapide, la rotation des identifiants et la reconstruction des environnements après une compromission du plan de contrôle.
Collectivement, ces mesures contribuent à réduire les risques liés aux attaques visant les plans de contrôle.
La campagne TeamPCP montre que les menaces ciblant le cloud reposent de plus en plus sur l’ampleur, l’automatisation et les erreurs de configuration courantes plutôt que sur des logiciels malveillants inédits.
Les plans de contrôle exposés restant un point d’entrée fréquent, les organisations ont intérêt à privilégier une visibilité continue, des contrôles d’accès robustes et des processus de réponse bien rodés dans l’ensemble de leurs environnements cloud.
Pour faire face à ces risques, les équipes de sécurité se tournent vers des solutions zero trust qui limitent l’accès par défaut et valident en continu l’activité sur les plans de contrôle.