TeamPCP gilt vielen als eine Bedrohung, die besonders im Kontext von späteren Supply-Chain-Angriffen auffiel. Neue Untersuchungen zeigen jedoch: TeamPCP Redis-Angriffe lassen sich deutlich weiter zurückverfolgen – bis in das Jahr 2020. Damit wird sichtbar, dass die Angreifer schon Jahre lang öffentlich erreichbare Systeme kompromittierten, bevor sie gezielt die Softwarelieferkette in den Fokus nahmen.
Die Analyse von Oligo Security beschreibt dabei eine Verbindung über mehrere technische und operative Merkmale. Dazu zählen überlappende Domain-Nutzung, Muster bei Malware-Deployment und Staging sowie wiedererkennbare Abläufe im Hintergrundbetrieb.
Frühe Aktivität: TeamPCP schon ab 2020
Nach den vorliegenden Erkenntnissen war der Bedrohungsakteur, der später mit TeamPCP assoziiert wird, bereits seit 2020 aktiv. Diese Einordnung ist relevant, weil sie den Eindruck einer plötzlichen „Neuerfindung“ widerlegt: Statt eines späteren Starts handelt es sich offenbar um eine fortlaufende Entwicklung innerhalb eines etablierten Angriffsökosystems.
Die Forscher nennen als unterstützende Indikatoren unter anderem Überschneidungen bei Domains, die Wege, über die Schadcode abgelegt wurde, sowie typische Techniken zur Vorbereitung im Verlauf eines Angriffs. Zusammen ergeben diese Merkmale ein konsistentes Bild über mehrere Phasen hinweg.
Redis als wiederkehrender Einstiegspunkt
Ein zentraler Teil der neuen Bewertung betrifft Angriffe auf Redis. Für eine Kampagne mit der Bezeichnung TA-NATALSTATUS wird beschrieben, dass sie exponierte Redis-Server angegriffen hat, um Kryptowährungs-Miner bereitzustellen. Damit fügt sich Redis als wiederkehrender Bestandteil in ein Muster ein: Angreifer suchen gezielt nach öffentlich zugänglicher Infrastruktur, die mit bekannten Schwachstellen oder Fehlkonfigurationen angreifbar ist.
Die Einschätzung lautet außerdem, dass TA-NATALSTATUS sich als Weiterentwicklung einer früheren Kampagne interpretieren lässt. Ein Bericht von Trend Micro aus April 2020 hatte damals ebenfalls das Ziel „Redis“ beschrieben, inklusive dem Einsatz, um Malware auf kompromittierten Systemen zu platzieren. Das deutet darauf hin, dass die Taktik zur Ausnutzung von Redis-Umgebungen nicht erst später entstand, sondern bereits früh Teil des Werkzeugkastens war.
Von Web-Technologien zu Cloud-nativen Zielen
Als die ersten Details zu den Tätern im vergangenen Jahr publik wurden, standen zunächst auch Angriffe im Web-Kontext im Vordergrund. Laut Bericht ging es um die Ausnutzung von Sicherheitslücken rund um React Server Components (RSC) sowie Next.js. Ziel war demnach, aus kompromittierten Umgebungen Zugangsdaten und sensible Informationen zu extrahieren.
Diese Aktivität wurde unter dem Namen Operation PCPcat beobachtet. Das zeigt, dass die Angreifer nicht nur nach „einfach erreichbaren“ Diensten wie Redis suchten, sondern auch gezielt Komponenten aus dem modernen Web-Ökosystem angriffen.
In einem weiteren Schritt wird außerdem beschrieben, dass später eine größere Kampagne in Cloud-native Umgebungen erfolgte. Die damaligen Ziele umfassten den Aufbau einer verteilten Proxy- und Scanning-Infrastruktur, gefolgt von der Kompromittierung von Servern zum Exfiltrieren von Daten. Zusätzlich wurden weitere Ziele genannt, darunter Ransomware, Erpressung und das Mining von Kryptowährungen.
ShadowRay 2.0 und der Brückenschlag in die spätere Infrastruktur
Besonders aufschlussreich sind Verknüpfungen zwischen mehreren Kampagnen. Für ShadowRay 2.0 (auch als IronErn bezeichnet) wird beschrieben, dass dabei KI-Infrastruktur in eine sich selbst ausbreitende Botnet-Struktur integriert werden sollte. Parallel dazu wird für die später als TeamPCP bekannte Infrastruktur eine Verbindung über identifizierbare operative Spuren beschrieben.
Die Forscher betonen insbesondere einen starken Link: Es sollen überlappende Identitäten bei GitHub und GitLab beobachtet worden sein. Durch die Korrelation von GitLab-Authentifizierungslogs, Command-and-Control-Strukturen, Reverse-Shell-Aktivität und Malware-Staging wird ein direkter „Operational Bridge“ zwischen ShadowRay 2.0 und dem später öffentlich auftretenden Betrieb unter TeamPCP abgeleitet.
Wichtig ist dabei die Stoßrichtung: Die Analyse stellt nicht nur fest, dass mehrere Kampagnen irgendwie zeitlich oder thematisch zusammenhängen, sondern ordnet konkrete Verhaltensmuster und technische Spuren als wiederkehrende Arbeitsweise ein.
Wiederholte Ausnutzung bekannter Schwächen
Ein weiterer Aspekt der neuen Erkenntnisse ist der wiederholte Einsatz von bekannten Sicherheitsproblemen in mehreren Technologien. Genannt werden Bereiche rund um React, Docker, Redis und Ray. Das spricht für einen Angriffsstil, der stark auf automatisierte und teils „wormable“ (also sich selbst weiterverbreitende) Mechanismen setzt.
So entsteht ein Bild, in dem die Angreifer nicht ausschließlich auf menschliches Handeln oder einmalige Einschläge vertrauen. Stattdessen bauen sie Zugriffe und Ausbreitung so, dass kompromittierte Umgebungen weitere Ziele erreichen können. Das erleichtert Skalierung und erhöht die Wahrscheinlichkeit, dass aus einem Einstieg bald ein breiterer Fußabdruck wird.
Die Entwicklung hin zu Supply-Chain-Angriffen
Aus Sicht der Analyse ist der Schritt in Richtung Softwarekette eine logische Weiterentwicklung. Nachdem sich die Angreifer bereits mit Cloud- und Internet-Exposition auskannten, nutzen sie die Verwobenheit moderner Software aus. Konkret wird beschrieben, dass beliebte Open-Source-Bibliotheken über Manipulationen in automatisierten Workflows kompromittiert werden konnten.
Dabei werden als technische Bausteine GitHub Actions und das Missbrauchen von Token beschrieben. Solche Angriffe können Entwicklerumgebungen in großem Maßstab erfassen, weil die Kompromittierung nicht nur einen Server betrifft, sondern Bestandteil des Build- und Integrationsprozesses wird.
Diese Strategie ergänzt ältere Muster: Die Angreifer greifen weiterhin auf bewährte Zugriffswege zurück, nur verschieben sie den „Hebel“ zunehmend in die Lieferkette, wo Änderungen besonders weitreichend sind.
Malware-Aktualisierungen: kube.py und zerstörerische Funktionen
Die Analyse verweist auch auf kontinuierliche Weiterentwicklungen im Schadcode. Dazu gehört ein Python-Skript namens kube.py, das laut Bericht speziell nach dem Eindringen in Kubernetes-Umgebungen eingesetzt wird.
Frühere Varianten hätten sich vor allem auf Verbreitung und Persistenz konzentriert. In neueren Versionen, die noch bis März 2026 beobachtet wurden, kamen jedoch zusätzlich Funktionen hinzu, die eine zerstörende Wirkung entfalten können.
Als Beispiel wird beschrieben, dass ein Pfad zur „Wiper“-ähnlichen Zerstörung prüft, ob das betroffene System für die Zeitzone „Iran“ konfiguriert ist. Falls das zutrifft, wird ein DaemonSet ausgelöst, das jeden Node im Cluster mit einer Komponente namens Kamikaze bereinigt.
Für Kubernetes-Nodes, die außerhalb dieser Zeitzone liegen, wird dagegen ein Backdoor mit dem Namen CanisterWorm eingesetzt. Befindet sich das Ziel außerhalb von Kubernetes und gehört zu iranischen Systemen, soll das Schadprogramm eine Routine poison_pill() ausführen, um das gesamte Dateisystem zu löschen.
Keine 100-prozentige Gewissheit über Rebrand oder Kollaboration
Die Forscher weisen zugleich darauf hin, dass sich nicht mit vollständiger Sicherheit bestimmen lässt, ob es sich um ein direktes Rebranding handelt, um einen gemeinsamen Operator-Set oder um enge Zusammenarbeit zwischen historisch verwandten Akteuren. Dafür gibt es laut Oligo keine absolute Beweissicherheit.
Was die Evidenz jedoch nahelegt: TeamPCP sollte eher als Fortsetzung eines bestehenden Angriffsökosystems verstanden werden – nicht als völlig neuer Bedrohungsakteur, der erst im Spätjahr 2025 „neu“ auftauchte.
Warum das wichtig ist: Frühwarnung statt Überraschung
Wenn TeamPCP Redis-Angriffe bis 2020 zurückreichen, bedeutet das für Organisationen vor allem eines: Sicherheitsmaßnahmen dürfen sich nicht nur auf „aktuelle“ Kampagnen konzentrieren. Stattdessen sollten Teams die grundlegenden Muster ernst nehmen, die sich über Jahre ziehen: die Ausnutzung öffentlich erreichbarer Dienste, die bevorzugte Arbeit mit Cloud- und Container-Umgebungen sowie die Nutzung automatisierter Mechanismen zur Ausweitung von Zugriffen.
Gerade bei Technologien wie Redis, Docker, Kubernetes und modernen Frameworks (etwa React/Next.js) lohnt es sich, den Fokus auf Patch-Management, Angriffserkennung und die Härtung von Workflows zu legen. Denn je schneller bekannte Angriffsflächen geschlossen werden, desto geringer wird die Angriffsfläche für Einsteige und Folgeschritte.
Fazit
Die neue Analyse zeichnet eine zusammenhängende Linie: Der mit TeamPCP verbundene Bedrohungsakteur war offenbar bereits seit 2020 aktiv. Redis und andere internet-exponierte Systeme dienten dabei als Einstiegspunkte, während sich die Angriffsstrategie im Zeitverlauf Richtung Cloud-native Ziele und später Richtung Softwarekette weiterentwickelte.
Damit wird klar, dass die spätere Aufmerksamkeit für Supply-Chain-Manipulationen Teil einer längeren Entwicklung ist. Für Verteidiger bedeutet das: Prävention, Härtung und konsequente Aktualität bei Schwachstellenbekämpfung bleiben entscheidend, um ähnliche Kampagnen nicht erst bei ihrem „öffentlichen Durchbruch“ zu stoppen.
Quelle: https://thehackernews.com/2026/08/teampcp-linked-to-redis-attacks-dating.html
