TeamPCP: Von Redis-Angriffen zur Kompromittierung der Software-Lieferkette

Eine kriminelle Aktivität, die mindestens bis ins Jahr 2020 zurückreicht

Eine am 7. August 2026 veröffentlichte Analyse von Oligo Security bringt TeamPCP mit Cybercrime-Aktivitäten in Verbindung, die mindestens im Jahr 2020 begonnen haben. Die Gruppe wäre damit bereits seit Jahren aktiv, bevor die jüngsten Kampagnen gegen die Software-Lieferkette einsetzten.

Die Verbindung ergibt sich aus Überschneidungen bei Domains, Backend-Infrastrukturen, Malware-Verbreitungswegen, Staging-Techniken und Vorgehensweisen. Oligo kann jedoch nicht feststellen, ob es sich um ein direktes Rebranding, eine gemeinsame Gruppe von Akteuren oder eine Zusammenarbeit bereits verbundener Angreifer handelt.

Die ersten Aktivitäten sollen sich gegen aus dem Internet erreichbare Systeme mit Redis, Ray, Docker und React gerichtet haben. Bereits im April 2020 dokumentierte Trend Micro eine Kampagne gegen exponierte Redis-Server, die zur Verbreitung von Malware und Krypto-Minern genutzt wurden.

ShadowRay 2.0 und TA-NATALSTATUS

In der zweiten Hälfte des Jahres 2025 wurden zwei Kampagnen beobachtet, die demselben operativen Ökosystem zugerechnet werden.

Die erste Kampagne, ShadowRay 2.0, auch als IronErn bekannt, griff Infrastrukturen für künstliche Intelligenz an und verwandelte sie in ein sich selbstständig ausbreitendes Botnetz. Die zweite Kampagne mit der Bezeichnung TA-NATALSTATUS zielte auf exponierte Redis-Server, um Mining-Software zu installieren.

Die Überschneidungen zwischen den mit IronErn verbundenen GitHub- und GitLab-Identitäten und der später TeamPCP zugeschriebenen Infrastruktur erhärten den Zusammenhang. Oligo verglich GitLab-Authentifizierungsprotokolle, Reverse-Shell-Aktivitäten, Command-and-Control-Server sowie die Staging-Phasen der Malware.

Der Akteur soll zudem bekannte Schwachstellen in React, Docker, Redis und Ray ausgenutzt und Automatisierung mit wurmartigen Techniken kombiniert haben, um die Ausbreitung zu beschleunigen.

Von der Serverausnutzung zur Software-Lieferkette

Die ersten öffentlichen Informationen über den Akteur wurden gegen Ende des vergangenen Jahres im Zusammenhang mit der Operation PCPcat bekannt. Im Rahmen dieser Kampagne sollen Schwachstellen in React Server Components und Next.js ausgenutzt worden sein, um Zugangsdaten und sensible Daten zu stehlen.

Zu Beginn dieses Jahres beschrieb Flare eine umfangreiche Kampagne gegen cloudnative Umgebungen. Zu den Zielen gehörten der Aufbau von Proxy- und Scan-Infrastrukturen, die Kompromittierung von Servern, Datenexfiltration, Ransomware, Erpressung und Mining.

Anschließend soll TeamPCP dieselben Fähigkeiten auf die Software-Lieferkette ausgeweitet haben durch:

• die Kompromittierung von Entwickler-Systemen;
• die Vergiftung weit verbreiteter Open-Source-Bibliotheken;
• den Missbrauch von GitHub Actions;
• den Diebstahl und die missbräuchliche Nutzung von Tokens;
• die Ausnutzung legitimer Cloud-Infrastrukturen.

Diese Entwicklung erhöht das Risiko für Organisationen, die auf automatisierte Pipelines und Pakete von Drittanbietern angewiesen sind.

kube.py und destruktives Verhalten in Kubernetes

Zu den beobachteten Werkzeugen gehört das Python-Skript kube.py, das nach der Kompromittierung von Kubernetes-Umgebungen eingesetzt wird. Frühere Versionen dienten vor allem der Verbreitung und Persistenz.

Noch im März 2026 beobachtete Varianten enthalten dagegen Funktionen, die denen eines Wipers ähneln. Das Verhalten hängt von der auf dem System konfigurierten Zeitzone ab:

• In iranischen Kubernetes-Clustern erstellt das Skript eine DaemonSet, die mithilfe des Wipers Kamikaze jeden Knoten löscht;
• auf Kubernetes-Knoten außerhalb des Iran verteilt es die Backdoor CanisterWorm;
• auf iranischen Systemen ohne Kubernetes führt es poison_pill() aus, eine Funktion, die das gesamte Dateisystem löschen soll.

Zu den möglichen Auswirkungen zählen daher der Diebstahl von Zugangsdaten und Daten, Mining, Ransomware, Backdoors und die vollständige Zerstörung der Infrastruktur.

Was Organisationen überprüfen sollten

Es wurden keine konkreten Patches, korrigierten Versionen, Indicators of Compromise oder YARA-Regeln veröffentlicht. Organisationen sollten ihre Prüfungen daher auf die in der Analyse genannten Angriffsflächen konzentrieren:

• direkt aus dem Internet erreichbare Redis-, Ray- und Docker-Server;
• Kubernetes-Cluster und ungewöhnliche DaemonSet-Aktivitäten;
• GitHub-Actions- und GitLab-Pipelines;
• von automatisierten Systemen verwendbare Tokens;
• unerwartete Installation oder Änderung von Open-Source-Paketen;
• Verbindungen zu Command-and-Control-Infrastrukturen;
• Reverse-Shell-Prozesse und Skripte wie kube.py;
• ungewöhnliche Löschvorgänge an Knoten, Dateisystemen oder Cloud-Ressourcen.

Die genauen Versionen der verwundbaren Produkte und spezifische Remediation-Verfahren sind nicht bekannt. Daher sind eine vollständige Asset-Inventarisierung, die Reduzierung der Internet-Exposition, die Rotation von Tokens und die Überwachung der Entwicklungspipelines erforderlich.