Een nieuwe analyse laat zien dat de dreigingsactor die onder de naam TeamPCP bekendstaat, al jaren eerder actief was dan de campagneperiode waarin de groep voor het eerst publiekelijk werd herkend. Volgens onderzoekers wijst het bewijs erop dat de aanvallen al vanaf 2020 terug te herleiden zijn, met TeamPCP Redis-aanvallen als belangrijk onderdeel van het patroon. Pas later verlegde de actor zijn focus naar cloudnative omgevingen en uiteindelijk naar het misbruiken van de software supply chain.
Onderzoekers van Oligo Security noemen de samenhang tussen campagnes met dezelfde “operationele handelswijze” en technische sporen, waaronder overlapping in domeinen, malware-opbouw, staging-methoden en backend-infrastructuur. Die rode draad maakt het moeilijk om TeamPCP te beschouwen als een volledig nieuw fenomeen; het lijkt eerder een voortzetting van een langer bestaand ecosysteem van aanvallen.
Van 2020 naar TeamPCP: wat de onderzoekers aantreffen
De kern van de bevindingen is dat de actor in eerdere fases internetgerichte infrastructuur compromitteerde. Daarbij gaat het niet om één enkele kwetsbaarheid, maar om een reeks patronen die volgens de onderzoekers steeds terugkomen: misbruik van bekende beveiligingsproblemen in populaire componenten en het vervolgens automatisch uitrollen van payloads.
De analyse beschrijft dat TeamPCP in latere herkenbare fases niet alleen softwaregerichte aanvallen uitvoerde, maar ook direct gericht bleef op exposed services. Dat helpt om te begrijpen hoe de overstap naar meer “supply chain”-achtige besmettingen mogelijk wordt: zodra aanvallers footholds hebben in cloud of ontwikkelomgevingen, kunnen ze hun technieken stap voor stap uitbreiden.
Redis als beginpunt: TA-NATALSTATUS en voorgangers
In de tweede helft van 2025 worden twee campagnes beschreven die binnen het bredere verhaal passen. De eerste campagne heet ShadowRay 2.0 (ook aangeduid als IronErn) en zou AI-infrastructuur zijn “gekaapt” om een zelf-propagerend botnet op te bouwen. De tweede campagne, TA-NATALSTATUS, richt zich expliciet op blootgestelde Redis-servers om crypto-miners te leveren.
Volgens de onderzoekers is TA-NATALSTATUS een evolutie van een campagne die al in april 2020 door Trend Micro werd beschreven. Ook toen zou de actor gericht zijn geweest op Redis-servers om malware te installeren. Dat tijdsverloop ondersteunt de conclusie dat de aanvaller al langere tijd internettoegankelijke systemen als toegangspunt gebruikte, lang voordat de operatie later onder de publieke paraplu “TeamPCP” viel.
React en Next.js: credential- en datadiefstal via webcomponenten
Een stap verder in het verhaal gaat over de eerste zichtbaarheid van de aanvallers. Aan het einde van vorig jaar kwamen ze volgens de analyse in beeld bij activiteiten die verband hielden met het misbruiken van problemen in React Server Components (RSC) en Next.js. Het doel hiervan lag bij het extraheren van credentials en het ophalen van gevoelige data uit omgevingen die al gecompromitteerd waren.
Deze fase kreeg de codenaam Operation PCPcat. In de praktijk laat dit type aanval zien hoe snel een aanvaller van “toegang tot een dienst” kan doorgroeien naar “toegang tot identiteiten en gegevens”, waarmee latere impact groter wordt.
Cloudnative schaal: proxy, scanning, exfiltratie en ransomware
Vroeger dit jaar beschreef Flare een grote operatie waarbij cloudnative omgevingen systematisch werden aangevallen. De onderzoekers noemen als doel het opzetten van een gedistribueerde proxy en scanning-infrastructuur op schaal, gevolgd door het compromitteren van servers om data te exfiltreren, ransomware in te zetten, aan afpersing te doen en ook cryptocurrency te delven.
Wat hierbij opvalt, is het “bouwblok”-denken: eerst infrastructuur om te vinden en te bereiken, daarna stappen richting impact. Dat past bij de observatie dat de actor herhaaldelijk teruggrijpt op geautomatiseerde technieken die zichzelf kunnen uitbreiden.
Waarom supply chain misbruik nu logisch wordt
In latere fases verschuift het beeld naar software supply chain-compromissen. De analyse stelt dat TeamPCP de onderlinge verbinding van moderne software inzet: aanvallers proberen via populaire open-source onderdelen developeromgevingen in massa te infecteren. Dat gebeurt volgens de onderzoekers door het vergiftigen van gebruikte libraries, in combinatie met technieken rond GitHub Actions en het misbruiken van token-diefstal.
Een belangrijke aanwijzing voor de directe link tussen verschillende campagnes is de overlap in identiteiten en infrastructuur. Oligo Security beschrijft dat er een brug zichtbaar wordt tussen de IronErn-fase en de latere TeamPCP-infrastructuur, op basis van verbanden in GitLab-authenticatielogboeken, command-and-control-sporen, reverse-shell-activiteit en malware staging.
Wil je de bredere context van supply chain-problemen en cloud-incidenten gebruiken voor je eigen aanpak? Dan zijn dit soort patronen vaak vergelijkbaar met wat je ziet bij andere gecompromitteerde developer-ecosystemen; onze site heeft bijvoorbeeld ook berichtgeving over hoe supply chain-issues en kwetsbaarheidsmisbruik kunnen doorwerken in omgevingen.
Als je intern beleid wil aanscherpen op basis van concrete aanvalstechnieken, helpt het om daarnaast te kijken naar rapporten over “token”-achtige misbruiken en post-compromis acties. Ter verdieping sluit ons artikel over agent-toolcall flaws die AWS, Google en Vercel raken aan bij het thema hoe moderne automatisering en tooling misbruikt kan worden na eerste toegang.
Keten van kwetsbaarheden: React, Docker, Redis en Ray
De onderzoekers benadrukken dat TeamPCP herhaaldelijk bekende beveiligingsproblemen misbruikt in componenten zoals React, Docker, Redis en Ray. Het gaat daarbij niet alleen om “eenmaal misbruiken”, maar om het kunnen automatiseren en opschalen van exploitatie, zodat aanvallers zichzelf verder kunnen verspreiden.
Die ontwikkeling verklaart waarom de stap naar supply chain-aanvallen niet als sprong voelt. Zodra methoden voor toegang, verplaatsing en payload-distributie bewezen zijn, wordt het hergebruik ervan in een nieuw aanvalslayer — zoals developer tooling — een logische volgende stap.
Nieuwe malware-updates: kube.py en een wiper-achtige variant
Naast de campagnebeschrijvingen wijzen de bevindingen op doorlopende updates aan de malware. Een opvallend onderdeel is een Python-script genaamd kube.py. Dit script zou speciaal gebruikt worden nadat de aanvallers Kubernetes-omgevingen hebben doorbroken.
Volgens de analyse waren eerdere versies vooral gericht op propagatie en het opzetten van persistentie. In nieuwere varianten, die volgens de onderzoekers al in maart 2026 zijn waargenomen, wordt echter ook een destructief pad ingebouwd.
Destructie per regio/configuratie
Het destructieve gedrag wordt gekoppeld aan de systeeminstellingen. De code controleert of een slachtoffer is geconfigureerd voor de Iran timezone. Is dat het geval, dan zou een DaemonSet worden gestart die alle nodes in het cluster wist via een wiper die “Kamikaze” heet.
Als de Kubernetes-nodes buiten die timezone vallen, wordt in plaats daarvan een backdoor ingezet die de naam CanisterWorm draagt. Voor niet-Kubernetes systemen in die timezone zou de malware een routine uitvoeren die is bedoeld om het volledige bestandssysteem te wissen (in de beschrijving “poison_pill()”).
Deze mix van overwegingen (environment checks, clusteractie en backdoor/purge-achtige paden) wijst op een aanvallersmodel waarin niet alleen winst wordt nagestreefd, maar ook disruptie. Tegelijk geven de onderzoekers aan dat ze niet met absolute zekerheid kunnen vaststellen of dit samenhangt met een herbranding, een gedeelde operator of nauwe samenwerking tussen eerder aanverwante actoren.
Wat dit betekent voor beveiligingsteams
De belangrijkste les uit de analyse is dat TeamPCP Redis-aanvallen niet losstaan van later supply chain-incidenten. Integendeel: het lijkt op een keten waarin dezelfde “tradecraft” terugkomt, terwijl de doelomgeving steeds verder verschuift — van direct internetblootgestelde services naar cloudnative platforms en uiteindelijk naar developer tooling.
Voor teams betekent dit praktisch dat je meerdere lagen tegelijk moet aanpakken:
- Reduceer exposure: beheer en beperk internettoegang tot services zoals Redis, en monitorde toegang en misbruikpatronen.
- Bescherm identity en tokens: token-diefstal en misbruik van CI/CD zijn vaak de brug naar supply chain impact.
- Verhard cloudnative omgevingen: controleer Kubernetes-instellingen, rechten en logging, juist om vroegtijdig destructieve payloads of misbruik van workloads te detecteren.
- Beoordeel supply chain risico’s: kijk niet alleen naar dependencies, maar ook naar workflow-risico’s rond automatisering en integraties.
Conclusie: een voortzetting van een bestaand aanvalsecosysteem
De nieuwe bevindingen schetsen een consistent beeld: de dreiging achter TeamPCP lijkt geen plotse start rond 2025, maar een voortzetting van een langer bestaand operatie-ecosysteem. Met Redis-gericht misbruik als vroeg signaal, gevolgd door aanvalstechnieken rondom React/Next.js, cloudnative schaalopbouw en uiteindelijk supply chain-compromissen, ontstaat één verhaallijn.
De extra aandacht voor Kubernetes en de aanwezigheid van destructieve functionaliteit maakt het urgent om zowel detectie als preventie op meerdere niveaus te versterken. Wie supply chain-beveiliging serieus neemt, kan de aanpak daarom niet los zien van het voorkomen van misbruik van exposed services en van het beveiligen van developer en CI/CD-werkomgevingen.
Bron: https://thehackernews.com/2026/08/teampcp-linked-to-redis-attacks-dating.html
