TeamPCP worm cloud-native: quando la tua infrastruttura diventa un data center criminale

Il TeamPCP worm cloud-native non è l’ennesimo cryptominer opportunistico che sfrutta un container mal configurato per rubare cicli di CPU. È qualcosa di strutturalmente diverso, e comprenderne la natura è urgente per chiunque gestisca infrastruttura cloud in produzione.

Il 5 febbraio 2026, il ricercatore Assaf Morag di Flare ha pubblicato un’analisi dettagliata di una campagna massiva osservata a partire dal 25 dicembre 2025: un’operazione worm-driven che ha compromesso sistematicamente API Docker esposte, cluster Kubernetes, dashboard Ray, server Redis e applicazioni vulnerabili a due distinte falle nei framework React e Next.js. L’obiettivo non era semplicemente infettare singoli host, ma costruire un’intera piattaforma criminale distribuita all’interno di ambienti cloud legittimi – una piattaforma capace di autopropagarsi, esfiltrare dati, distribuire ransomware, fare mining di criptovalute e fungere da trampolino per attacchi successivi.

La notizia ha raggiunto la comunità di sicurezza il 9 febbraio 2026 tramite The Hacker News, ma le implicazioni strategiche di TeamPCP vanno ben oltre la singola campagna. Questo articolo le analizza in profondità.

Chi è TeamPCP: identikit di un ecosistema criminale cloud-native

TeamPCP – noto anche come DeadCatx3, PCPcat, PersyPCP e ShellForce – non è un singolo individuo né una gang ransomware tradizionale. È un’operazione ibrida che combina le funzioni di botnet, access broker, data-leak crew e piattaforma di exploitation cloud. Secondo il report di Flare, l’attività del gruppo è tracciabile almeno da novembre 2025, con il primo messaggio registrato sul canale Telegram TeamPCP datato 17 novembre 2025. Il canale Telegram principale conta oltre 700 membri e viene utilizzato per pubblicare dati rubati, costruire reputazione e fare pressione sulle vittime. Il gruppo ha dichiarato pubblicamente di aver effettuato un rebranding a fine 2025, il che suggerisce attività precedente sotto altri nomi prima di consolidarsi come TeamPCP.

Un dettaglio investigativo rilevante riguarda il collegamento con il Kenya. Il 17 novembre 2025 – la stessa data del primo messaggio Telegram – un gruppo denominato “PCP@Kenya” ha condotto un attacco coordinato contro i siti web del governo keniota, inclusi quelli della Presidenza e dei ministeri dell’Interno, della Sanità, dell’Istruzione e dell’Energia. Il sottosegretario all’Interno Raymond Omollo ha attribuito l’attacco al gruppo PCP@Kenya. La coincidenza temporale e l’uso della sigla “PCP” suggeriscono un possibile legame con TeamPCP, sebbene l’attribuzione definitiva resti aperta.

Il dato più significativo, però, è un altro. La forza di TeamPCP non risiede in exploit innovativi o malware originale, ma nell’automazione su larga scala e nell’integrazione di tecniche d’attacco ben note. Come evidenziato nel report Flare, gran parte del codice dei payload è copiato e leggermente modificato – probabilmente con assistenza AI – piuttosto che sviluppato da zero. Il gruppo industrializza vulnerabilità esistenti, misconfigurazioni diffuse e strumenti open-source riadattati in una piattaforma di exploitation cloud-native che trasforma l’infrastruttura esposta in un ecosistema criminale autoproliferante.

In altre parole: TeamPCP è lo specchio oscuro del modello DevOps. Usa le stesse API, gli stessi pattern di automazione, la stessa logica di scalabilità che le organizzazioni impiegano per costruire le proprie infrastrutture. Solo che li usa per demolirle.

La catena d’attacco: dall’API esposta al cluster compromesso

Accesso iniziale: cinque porte aperte sul mondo

Il playbook di TeamPCP è opportunistico per design. Il gruppo esegue scansioni massicce su ampi range IP alla ricerca di servizi cloud-native esposti senza autenticazione o con credenziali deboli. I vettori di ingresso principali sono cinque:

1. API Docker esposte su Internet senza autenticazione, che consentono a chiunque di gestire container da remoto.
2. API Kubernetes accessibili con autenticazione anonima o credenziali deboli.
3. Dashboard Ray non protette – piattaforme di orchestrazione per workload di machine learning e AI.
4. Istanze Redis prive di password o raggiungibili dall’Internet pubblico.
5. Applicazioni React/Next.js vulnerabili a due falle critiche distinte: CVE-2025-55182 (React2Shell), la vulnerabilità di deserializzazione insicura nel protocollo “Flight” dei React Server Components con CVSS 10.0, divulgata il 3 dicembre 2025; e CVE-2025-29927, una falla nel middleware di Next.js divulgata il 21 marzo 2025 (CVSS 9.1) che consente il bypass dell’autenticazione tramite manipolazione dell’header.

Nessuna di queste è una vulnerabilità sofisticata. Sono porte lasciate aperte – e TeamPCP ha costruito un sistema automatizzato per trovarle e attraversarle tutte. Secondo un’analisi di Cyberpress basata sull’endpoint / stats del server C2, ogni macchina infetta richiede 2.000 nuovi target dal server C2 ogni 45 minuti circa, creando un ciclo d’attacco autosostenibile.

Fase 2: il bootstrap – proxy.sh come spina dorsale operativa

Una volta ottenuto l’accesso, TeamPCP distribuisce payload di secondo stadio da server esterni: script Shell e Python progettati per espandere l’infezione e stabilire persistenza. Il componente centrale è proxy.sh, uno script che funge da spina dorsale operativa dell’intera campagna.

Proxy.sh esegue tre funzioni critiche in sequenza. Prima, installa utility di tunneling e proxy (FRPS, gost) per stabilire connettività crittata verso l’infrastruttura di comando e controllo. Poi, distribuisce scanner multipli che cercano continuamente su Internet nuovi server vulnerabili o mal configurati. Infine, registra servizi di sistema persistenti per garantire la sopravvivenza al riavvio del server.

L’aspetto più rilevante è che proxy.sh esegue un fingerprinting dell’ambiente al momento dell’esecuzione. Se rileva di trovarsi all’interno di un cluster Kubernetes, cambia percorso di esecuzione e scarica un payload dedicato: kube.py.

Fase 3: la colonizzazione del cluster Kubernetes

Kube.py rappresenta il vero salto qualitativo della campagna. Le sue funzionalità includono la raccolta di credenziali del cluster, l’enumerazione di pod e namespace attraverso le API Kubernetes, la propagazione dello script proxy.sh in tutti i pod accessibili e il deploy di DaemonSet privilegiati che montano il filesystem dell’host e persistono su ogni nodo.

L’effetto è trasformativo. Un singolo punto d’ingresso – un’API Docker esposta, un endpoint Kubernetes non autenticato – diventa la porta d’accesso all’intero ambiente cloud. Ogni workload compromesso diventa a sua volta uno scanner che cerca altri servizi vulnerabili, generando una crescita esponenziale. Come sintetizzato nel report Flare, i cluster Kubernetes non vengono semplicemente violati: vengono convertiti in botnet distribuite.

Fase 4: monetizzazione multipla

TeamPCP monetizza ogni sistema compromesso attraverso molteplici flussi di ricavo simultanei. Ogni server infetto diventa contemporaneamente uno scanner (per trovare nuovi bersagli), un proxy (per anonimizzare operazioni), un miner di criptovalute (XMRig per Monero), un nodo di esfiltrazione dati e un trampolino di lancio per ransomware e attacchi successivi.

Sul fronte del furto dati, il gruppo pubblica documenti d’identità, record aziendali e database di curriculum vitae attraverso il canale Telegram ShellForce. Un caso documentato coinvolge JobsGO, piattaforma di recruiting vietnamita: 2.325.285 record di candidati contenenti informazioni personali e professionali sono stati esfiltrati e pubblicati l’8 gennaio 2026.

Il framework di comando e controllo utilizzato è Sliver, un C2 open-source originariamente sviluppato come strumento di red team e oggi ampiamente adottato da operatori criminali.

Perché TeamPCP è strutturalmente diverso: il paradigma del worm cloud-native

Non è un attacco: è una piattaforma

La differenza tra TeamPCP e le campagne di cryptojacking che colpiscono container Docker da anni non è quantitativa: è qualitativa. I miner opportunistici cercano risorse di calcolo. TeamPCP cerca infrastruttura – e la converte in un’estensione della propria operazione criminale.

Secondo l’analisi di Dark Reading, i dati di Flare indicano che il 61% degli attacchi analizzati ha coinvolto infrastruttura ospitata su Microsoft Azure, il 36% su Amazon Web Services – il 97% del totale concentrato su due soli provider. Sono stati osservati attacchi anche contro ambienti Google Cloud. L’operazione non discrimina: qualsiasi workload cloud esposto che soddisfa le condizioni viene assorbito nella catena d’infezione.

Quanto alla scala dell’operazione, Flare ha direttamente identificato 185 server compromessi che eseguivano container con pattern di comando standardizzati, stabilendo un’impronta affidabile della pipeline di deployment automatizzato di TeamPCP. L’infrastruttura di C2 primaria – l’IP 67.217.57[.]240 – è stata rilevata su 182 di questi host; un nodo secondario all’IP 44.252.85[.]168 è stato osservato su ulteriori tre server. Separatamente, un’analisi di Cyberpress dell’endpoint / stats del server C2, condotta tramite test su honeypot, ha rivelato 91.505 sistemi scansionati con un tasso di successo del 64,6%, suggerendo circa 59.128 server compromessi complessivamente. Dark Reading riporta una stima di almeno 60.000 server compromessi a livello mondiale.

In termini di mappatura MITRE ATT&CK, l’operazione coinvolge le tecniche T1190 (Exploit Public-Facing Application) per l’accesso iniziale, T1041 (Exfiltration Over C2 Channel) per l’esfiltrazione dei dati e T1543.002 (Create or Modify System Process: Systemd Service) per la persistenza.

Il modello living off the land cloud

TeamPCP incarna una tendenza tattica in accelerazione: il living off the land cloud. Gli attaccanti non installano strumenti estranei all’ambiente. Usano le API native dell’infrastruttura vittima – le stesse API che gli sviluppatori utilizzano ogni giorno per distribuire applicazioni, gestire container e orchestrare workload. Il traffico malevolo si mimetizza con le operazioni legittime, rendendo la detection estremamente complessa per gli strumenti tradizionali.

Questo approccio sfrutta un paradosso architetturale fondamentale. Le stesse proprietà che rendono potente il cloud – elasticità, automazione, scalabilità – diventano armi quando l’attaccante le controlla. Un cluster Kubernetes progettato per scalare applicazioni diventa un sistema che scala la propagazione del worm. Un’API Docker pensata per il deployment rapido diventa un vettore di distribuzione automatica di payload malevoli.

Il precedente: da TeamTNT a TeamPCP

TeamPCP non è il primo attore a specializzarsi nello sfruttamento di infrastruttura cloud-native. Il precedente più rilevante è TeamTNT, gruppo attivo tra il 2019 e il 2024, che aveva costruito una reputazione significativa nel cryptojacking di container Docker e cluster Kubernetes. Come rilevato da Flare, lo stesso pattern di costruzione di un seguito pubblico e di amplificazione reputazionale tramite Telegram si ripete con TeamPCP.

La differenza è di scala e ambizione. Dove TeamTNT si concentrava prevalentemente sul mining, TeamPCP integra il mining come uno dei molteplici flussi di ricavo in una piattaforma criminale completa che comprende ransomware, estorsione, vendita di accesso proxy e furto di dati.

React2Shell e CVE-2025-29927: il doppio catalizzatore

La campagna TeamPCP sfrutta due vulnerabilità distinte nell’ecosistema React/Next.js, spesso confuse tra loro ma tecnicamente differenti.

CVE-2025-55182 – React2Shell

CVE-2025-55182, nota come React2Shell, è una falla di deserializzazione insicura nel protocollo “Flight” dei React Server Components, scoperta dal ricercatore Lachlan Davidson e divulgata il 3 dicembre 2025. Con un punteggio CVSS di 10.0, interessa le versioni 19.0, 19.1.0, 19.1.1 e 19.2.0 dei pacchetti react-server-dom-webpack, react-server-dom-parcel e react-server-dom-turbopack . Come documentato da Wiz Research, le configurazioni di default sono vulnerabili: un’applicazione Next.js standard creata con create-next-app e compilata per la produzione può essere sfruttata senza alcuna modifica al codice da parte dello sviluppatore. I test di Wiz hanno dimostrato un’affidabilità prossima al 100% dell’exploit.

L’impatto è vasto. La ShadowServer Foundation ha identificato oltre 165.000 indirizzi IP vulnerabili e 644.000 domini all’8 dicembre 2025.

Lo sfruttamento è iniziato entro poche ore dalla divulgazione pubblica. Amazon AWS, Google GTIG, Microsoft, Palo Alto Unit 42, Cloudflare e Sophos hanno tutti pubblicato analisi dettagliate dell’attività di sfruttamento, identificando gruppi che vanno da attori state-nexus cinesi (Earth Lamia, Jackpot Panda secondo AWS) a operatori criminali opportunistici come TeamPCP. Ricerche di Sysdig hanno suggerito un possibile collegamento tra lo sfruttamento di React2Shell e strumenti compatibili con la campagna nordcoreana Contagious Interview, sebbene Sophos abbia precisato che i dati attualmente disponibili sono insufficienti per supportare tale attribuzione.

CVE-2025-29927 – Next.js Middleware Bypass

CVE-2025-29927 è una vulnerabilità di bypass dell’autorizzazione nel middleware di Next.js, divulgata il 21 marzo 2025, con CVSS 9.1. Scoperta dal ricercatore Rachid Allam, consente a un attaccante di aggirare completamente i controlli del middleware aggiungendo un header x-middleware-subrequest alle richieste HTTP. Un aspetto importante: il report di Flare identifica specificamente lo script react.py di TeamPCP come strumento progettato per sfruttare CVE-2025-29927, e la pagina Wiz Threats dedicata a TeamPCP conferma CVE-2025-29927 tra i vettori di accesso iniziale. Lo script implementa una pipeline automatizzata di sfruttamento che, una volta ottenuta l’esecuzione di codice remoto, esfiltra sistematicamente variabili d’ambiente, file . env , credenziali Git, chiavi SSH e credenziali cloud.

TeamPCP sfrutta quindi entrambe le vulnerabilità come vettori di accesso iniziale complementari, massimizzando la superficie d’attacco contro l’ecosistema React/Next.js.

Il problema strutturale: la superficie d’attacco che nessuno misura

Le misconfigurazioni come debito tecnico endemico

TeamPCP non inventa nuovi metodi d’attacco. Industrializza quelli vecchi con efficacia straordinaria. E questo è il problema: le vulnerabilità che sfrutta non sono bug esotici. Sono configurazioni di default lasciate invariate, interfacce di gestione esposte per comodità, credenziali hardcoded in file . env dimenticati.

Come sottolineato da eSecurity Planet nell’analisi della campagna, TeamPCP dimostra come ambienti cloud mal configurati possano essere rapidamente trasformati in piattaforme di attacco autoproliferanti quando i control plane sono esposti o insufficientemente monitorati.

Il modello build fast, secure later e le sue conseguenze

L’ecosistema cloud-native si è sviluppato attorno a un imperativo culturale: velocità. I framework DevOps e le pipeline CI/CD sono ottimizzati per ridurre il time-to-deployment. Kubernetes e Docker sono progettati per rendere il provisioning di infrastruttura rapido, ripetibile e scalabile.

Il problema è che la sicurezza, in questo modello, viene costantemente differita. Le API di orchestrazione vengono esposte per facilitare lo sviluppo e restano esposte in produzione. I service account ricevono privilegi eccessivi “per comodità” – e restano over-privileged per mesi o anni. Le credenziali finiscono nei file di configurazione, nelle immagini Docker e nei repository Git senza che nessuno le revochi.

TeamPCP prospera esattamente in questo divario tra velocità di deployment e maturità delle pratiche di sicurezza. Ogni organizzazione che ha accelerato la migrazione cloud senza investire proporzionalmente in competenze di cloud security è un potenziale nodo del suo ecosistema criminale.

Il rischio reputazionale e legale: corresponsabilità involontaria

C’è un aspetto che molte organizzazioni sottovalutano: quando TeamPCP compromette la vostra infrastruttura cloud, non la usa solo per rubarvi dati. La usa come launchpad per attaccare altri. Il vostro cluster Kubernetes diventa uno scanner che cerca nuove vittime. I vostri server diventano proxy per operazioni criminali. La vostra infrastruttura mina criptovalute per finanziare attività illecite.

Le implicazioni legali sono rilevanti. Nel contesto del Regolamento NIS2, le organizzazioni che operano in settori essenziali o importanti hanno obblighi specifici di gestione del rischio cyber e di notifica degli incidenti. Un’infrastruttura cloud compromessa che funge da trampolino per attacchi a terzi può generare responsabilità dirette sotto il profilo della due diligence e della gestione della catena di approvvigionamento.

Sotto il GDPR, se i dati personali dei clienti o dei dipendenti vengono esfiltrati attraverso un container compromesso, l’organizzazione è titolare del trattamento e risponde della violazione – indipendentemente dal fatto che la causa sia una misconfigurazione tecnica e non un attacco sofisticato.

Contromisure: dalla prevenzione alla detection, passando per l’architettura

Principio zero: ridurre la superficie d’attacco prima di tutto

La prima linea di difesa contro TeamPCP non è un prodotto di sicurezza: è la riduzione drastica dell’esposizione. Le raccomandazioni operative immediate includono:

• Disabilitare o restringere rigorosamente l’accesso pubblico alle API Docker, Kubernetes, Redis e Ray. Nessuna di queste interfacce dovrebbe essere raggiungibile da Internet senza autenticazione forte e network policy
• Implementare RBAC granulare su tutti i control plane Il principio del minimo privilegio non è una raccomandazione: è l’unica difesa contro la propagazione laterale automatizzata.
• Patchare React/Next.js immediatamente. Per CVE-2025-55182 (React2Shell), le versioni inizialmente corrette erano 19.0.1, 19.1.2 e 19.2.1, ma successive vulnerabilità correlate (CVE-2025-55183 e CVE-2025-55184) hanno richiesto ulteriori patch. Al 26 gennaio 2026, la pagina ufficiale React raccomanda di aggiornare all’ultima versione stabile disponibile nella propria release line. Per CVE-2025-29927, aggiornare Next.js alle versioni 12.3.5+, 13.5.9+, 14.2.25+ o 15.2.3+.
• Verificare tutte le immagini Docker in uso per la presenza di credenziali embedded, file . env con segreti in chiaro e token di accesso hardcoded.
• Implementare network policy Kubernetes che limitino la comunicazione tra pod al minimo indispensabile per le operazioni legittime.

Detection: cosa cercare

TeamPCP lascia tracce identificabili per chi sa dove guardare. I segnali da monitorare attivamente comprendono:

• Creazione non autorizzata di container, specialmente con immagini non presenti nel registro approvato.
• Deploy di DaemonSet inattesi, in particolare quelli con nomi generici come “system-monitor” che montano il filesystem dell’host.
• Connessioni in uscita verso l’indirizzo IP 67.217.57[.]240 sulle porte 5656, 666 e 888 (C2 primario identificato da Flare su 182 host compromessi) e 44.252.85[.]168 (C2 secondario).
• Servizi systemd anomali denominati pcpcat-frp.service e pcpcat-gost.service , creati per garantire la persistenza tramite auto-start, nonché teampcp-react.service per lo scanner React.
• Picchi di utilizzo della CPU compatibili con attività di cryptomining (XMRig).
• Attività di scanning anomala proveniente da pod interni verso range CIDR esterni.
• Esecuzione di script Python non autorizzati ( scanner.py, kube.py, pcpcat.py, react.py ).
• Traffico verso infrastruttura Sliver C2.
• Registrazione di nuovi servizi systemd, specialmente se eseguono proxy o tunneling.
• Presenza della firma testuale “UwU PCP Cat was here~” nei log o negli artefatti di sistema, e riferimenti ai canali Telegram @Persy_PCP e @teampcp.

I team di incident response possono inoltre impiegare le regole YARA e Snort condivise dalla comunità di ricerca per identificare artefatti specifici dell’operazione e verificare l’assenza di processi FRP o GOST non autorizzati sui server.

Strumenti di runtime security

Per la detection in ambienti cloud-native, gli strumenti di runtime security rappresentano un livello essenziale. Soluzioni come Falco (open-source, CNCF) e Sysdig Secure consentono di monitorare le syscall a livello di kernel e identificare comportamenti anomali nei container in esecuzione. Le piattaforme CSPM (Cloud Security Posture Management) e CWPP (Cloud Workload Protection Platform) permettono l’identificazione continua e automatizzata di misconfigurazioni.

Il principio dell’assunzione di compromissione

Quando TeamPCP viene rilevato in un ambiente, la risposta non può essere limitata alla rimozione del singolo container infetto. Il comportamento worm-like del malware impone di assumere una compromissione a livello di cluster. La risposta deve includere il contenimento immediato, la rotazione di tutte le credenziali (inclusi token di service account, chiavi API e segreti cloud), la ricostruzione dell’infrastruttura da baseline pulite e un’analisi forense completa per determinare l’estensione dell’esfiltrazione dei dati.

Lo scenario prospettico: perché TeamPCP è un indicatore, non un’eccezione

La democratizzazione dell’exploitation cloud

TeamPCP dimostra che compromettere infrastruttura cloud su larga scala non richiede più sofisticazione tecnica. Gli strumenti sono pubblici. Le vulnerabilità sono documentate. Le misconfigurazioni sono endemiche. Il modello è replicabile da qualsiasi attore con competenze di scripting basilari e accesso ai forum underground.

Come ha osservato Morag di Flare in un’intervista a eSecurity Planet, la campagna riflette un modello che replica quello dei mercati legittimi: così come un business moderno può scalare da un singolo individuo grazie all’AI e all’automazione, anche gli attori criminali stanno adottando lo stesso approccio operativo. Combinano vulnerabilità appena divulgate con metodi di accesso iniziale consolidati basati su misconfigurazioni cloud-native, e convertono rapidamente gli accessi compromessi in prodotti scambiati nei mercati underground.

La convergenza con il ransomware cloud-native

TeamPCP si inserisce in un trend più ampio di migrazione del ransomware verso ambienti cloud. Finché le organizzazioni continuano a esporre API di orchestrazione, a inserire segreti nei file . env e a distribuire servizi cloud senza confini di sicurezza robusti, attori come TeamPCP continueranno a convertire l’infrastruttura mondiale in piattaforma criminale.

Conclusione: la sicurezza cloud non è un optional

Il TeamPCP worm cloud-native non è una minaccia futuristica. È operativo adesso, sfrutta errori che le organizzazioni commettono adesso e converte infrastruttura legittima in arma criminale adesso.

La lezione fondamentale è scomoda ma necessaria: la sicurezza cloud non può essere differita, delegata al provider o affrontata dopo il deployment. Il modello di responsabilità condivisa implica che il provider protegge l’infrastruttura sottostante; il cliente protegge la configurazione, gli accessi e i workload. Quando le API di Docker e Kubernetes restano esposte senza autenticazione, non è il cloud a fallire: è l’organizzazione che lo gestisce.

Per i CISO e i security architect, TeamPCP impone una riconsiderazione delle priorità. La sicurezza cloud-native non è un sottoinsieme della sicurezza IT tradizionale applicata a un ambiente diverso. È una disciplina con superfici d’attacco proprie, pattern di minaccia specifici e requisiti di competenza dedicati. Trattarla come un’estensione del firewall perimetrale è il motivo per cui campagne come TeamPCP continuano a trovare decine di migliaia di porte aperte.