TeamPCP, dagli attacchi a Redis alla compromissione della supply chain

Un’attività criminale che risale almeno al 2020

Un’analisi di Oligo Security, rilevata il 7 agosto 2026, collega TeamPCP ad attività di cybercrime iniziate almeno nel 2020. Il gruppo sarebbe quindi operativo da anni prima delle campagne più recenti contro la software supply chain.

Il collegamento emerge dalla sovrapposizione di domini, infrastrutture backend, percorsi di distribuzione del malware, tecniche di staging e modalità operative. Oligo non stabilisce però se si tratti di un rebranding diretto, di un gruppo comune di operatori o della collaborazione tra attori già collegati.

Le prime attività avrebbero preso di mira sistemi accessibili da Internet basati su Redis, Ray, Docker e React. Nell’aprile 2020 Trend Micro aveva già documentato una campagna contro server Redis esposti, utilizzati per distribuire malware e miner di criptovaluta.

ShadowRay 2.0 e TA-NATALSTATUS

Nella seconda metà del 2025 sono state osservate due campagne riconducibili allo stesso ecosistema operativo.

La prima, ShadowRay 2.0, conosciuta anche come IronErn, ha colpito infrastrutture per l’intelligenza artificiale trasformandole in una botnet capace di propagarsi autonomamente. La seconda, denominata TA-NATALSTATUS, ha preso di mira server Redis esposti per installare software di mining.

La correlazione tra identità GitHub e GitLab associate a IronErn e l’infrastruttura attribuita successivamente a TeamPCP rafforza il collegamento. Oligo ha confrontato log di autenticazione GitLab, attività di reverse shell, server command-and-control e fasi di staging del malware.

L’attore avrebbe inoltre sfruttato vulnerabilità note in React, Docker, Redis e Ray, combinando automazione e tecniche wormable per accelerare la propagazione.

Dallo sfruttamento dei server alla supply chain

Le prime informazioni pubbliche sull’attore sono emerse verso la fine dell’anno scorso, in relazione a Operation PCPcat. In quella campagna sarebbero state sfruttate vulnerabilità in React Server Components e Next.js per sottrarre credenziali e dati sensibili.

All’inizio dell’anno, Flare ha descritto una campagna estesa contro ambienti cloud-native. Gli obiettivi comprendevano la creazione di infrastrutture per proxy e scansione, la compromissione di server, l’esfiltrazione, il ransomware, l’estorsione e il mining.

Successivamente TeamPCP avrebbe portato le stesse capacità nella supply chain software attraverso:

• compromissione dei sistemi degli sviluppatori;
• avvelenamento di librerie open source diffuse;
• abuso di GitHub Actions;
• furto e utilizzo fraudolento di token;
• sfruttamento di infrastrutture cloud legittime.

Questa evoluzione aumenta il rischio per organizzazioni che dipendono da pipeline automatizzate e pacchetti di terze parti.

kube.py e il comportamento distruttivo su Kubernetes

Tra gli strumenti osservati figura lo script Python kube.py, impiegato dopo la compromissione di ambienti Kubernetes. Le prime versioni puntavano soprattutto a propagazione e persistenza.

Varianti rilevate ancora nel marzo 2026 includono invece funzioni simili a quelle di un wiper. Il comportamento dipende dal fuso orario configurato sul sistema:

• sui cluster Kubernetes iraniani, crea una DaemonSet che cancella ogni nodo usando il wiper Kamikaze;
• sui nodi Kubernetes fuori dall’Iran, distribuisce la backdoor CanisterWorm;
• sui sistemi iraniani non basati su Kubernetes, esegue poison_pill(), progettata per cancellare l’intero filesystem.

L’impatto potenziale comprende quindi furto di credenziali e dati, mining, ransomware, backdoor e distruzione completa dell’infrastruttura.

Cosa devono verificare le organizzazioni

Non sono state rese note patch specifiche, versioni corrette, indicatori di compromissione o regole YARA. Le organizzazioni dovrebbero quindi concentrare i controlli sulle superfici indicate dall’analisi:

• server Redis, Ray e Docker esposti direttamente a Internet;
• cluster Kubernetes e attività anomale di DaemonSet;
• pipeline GitHub Actions e GitLab;
• token utilizzabili da sistemi automatizzati;
• installazione o modifica inattesa di pacchetti open source;
• connessioni verso infrastrutture di comando e controllo;
• processi di reverse shell e script come kube.py;
• cancellazioni anomale di nodi, filesystem o risorse cloud.

Le versioni esatte dei prodotti vulnerabili e le procedure di remediation specifiche non sono note. Servono quindi inventario degli asset, riduzione dell’esposizione Internet, rotazione dei token e monitoraggio delle pipeline di sviluppo.