TeamPCP e il worm cloud-native che trasforma Docker e Kubernetes in un’arma industriale

TeamPCP emerge come uno dei gruppi cybercriminali più strutturati del 2026, capace di sfruttare ambienti cloud-native per costruire un worm auto-propagante che combina accesso iniziale, persistenza, esfiltrazione dati, ransomware e cryptomining. Attivo almeno da novembre 2025, il gruppo opera sotto diversi alias, tra cui PCPcat, ShellForce, DeadCatx3 e PersyPCP, e ha trasformato Docker, Kubernetes e servizi cloud esposti in una piattaforma criminale distribuita. L’elemento distintivo non è l’uso di exploit inediti, ma la industrializzazione di vulnerabilità e misconfigurazioni note, assemblate in una catena automatizzata che consente a TeamPCP di muoversi lateralmente tra cluster, riconvertire workload legittimi e monetizzare risorse cloud su larga scala.

L’ascesa di TeamPCP nel panorama ransomware cloud

Le prime evidenze riconducibili a TeamPCP compaiono a novembre 2025, ma è intorno al 25 dicembre che l’operazione PCPcat mostra la sua portata. In pochi giorni vengono compromessi 185 server, con una prevalenza netta di ambienti Azure (61%) e AWS (36%), a conferma di una strategia mirata ai grandi provider cloud. Il gruppo non si limita a colpire singole macchine. Ogni infrastruttura compromessa diventa parte di un ecosistema auto-propagante, riutilizzato come proxy, nodo di scansione, relay C2 o piattaforma di mining. In questo modello, la vittima non è solo bersaglio, ma ingranaggio involontario di una botnet ibrida.

Un worm costruito sul control plane cloud

Il cuore dell’operazione TeamPCP è un worm cloud-native, progettato per colpire control plane esposti anziché endpoint tradizionali. Le superfici d’attacco includono API Docker non autenticate, cluster Kubernetes accessibili, dashboard Ray, server Redis e applicazioni React/Next.js vulnerabili alla React2Shell (CVE-2025-29927).

Il worm utilizza una serie di script Python e Shell per fingerprintare l’ambiente, determinare se si trova su un cluster Kubernetes o su un host standalone e scegliere il payload più efficace. In presenza di Kubernetes, la propagazione accelera drasticamente: il malware sfrutta le API per enumerare pod, namespace e segreti, quindi distribuisce container malevoli su ogni nodo. L’uso di pod privilegiati e mount hostPath consente a TeamPCP di evadere l’isolamento dei container, accedere al filesystem dell’host e ottenere una persistenza che sopravvive al riavvio dei workload.

Docker, Kubernetes e Ray come vettori di attacco

TeamPCP dimostra una profonda conoscenza dell’ecosistema cloud moderno. Le API Docker esposte permettono il deploy remoto di container malevoli; le dashboard Ray vengono abusate per sottomettere job arbitrari; Redis mal configurati offrono execution remota senza autenticazione. Nel caso delle applicazioni web, la vulnerabilità React2Shell (CVE-2025-29927) viene sfruttata per ottenere remote code execution tramite richieste multipart costruite ad hoc. Da lì, il worm scarica script aggiuntivi, raccoglie file .env, chiavi SSH e credenziali cloud, e passa alla fase successiva. Ogni compromissione alimenta nuove scansioni. Script come scanner.py recuperano liste CIDR pubblicate su GitHub sotto l’alias DeadCatx3, trasformando i server violati in fabbriche di scansione sempre attive.

Persistenza, evasione e controllo

La persistenza è garantita attraverso DaemonSet Kubernetes, policy di auto-restart e backdoor distribuite nei pod. I payload sono spesso offuscati con Base64, compressi o caricati in più stadi per ridurre la rilevabilità. Il gruppo utilizza tunnel come FRPS e gost per comunicazioni P2P, mentre il C2 fa leva su Sliver, con canali cifrati e relay ridondanti. Questo approccio consente a TeamPCP di resistere ai takedown. Anche se un nodo viene isolato, altri continuano a operare, mantenendo attiva la rete di scansione e monetizzazione.

Dalla compromissione alla monetizzazione

Una volta stabilita la presenza, TeamPCP passa rapidamente alla monetizzazione. Le risorse cloud vengono riconvertite per cryptomining, principalmente tramite XMRig, causando consumo anomalo di CPU e costi elevati per le vittime. In parallelo, i sistemi diventano proxy per altre operazioni criminali o relay C2 per campagne successive.

La fase più visibile resta l’estorsione. Dati sensibili – record HR, informazioni finanziarie, database e-commerce – vengono esfiltrati e pubblicati su canali Telegram riconducibili a ShellForce e TeamPCP. In totale, i ricercatori hanno osservato 27 GB di dati distribuiti in 17 dump, con vittime in Nord America, Europa, Medio Oriente e Asia. Questa esposizione pubblica serve sia a fare pressione sulle vittime, sia a costruire reputazione criminale all’interno dell’underground, rafforzando il ruolo di TeamPCP come access broker oltre che come gruppo ransomware.

Un modello operativo che anticipa il futuro del cybercrime

TeamPCP non appare come un gruppo improvvisato. La presenza di rebranding, l’uso coordinato di Telegram, GitHub e forum Tor, e la celebrazione pubblica dei “successi” indicano una struttura che evolve rapidamente, adattandosi alle difese e sfruttando la complessità intrinseca del cloud. Il messaggio per le organizzazioni è chiaro: le misconfigurazioni cloud non sono più un rischio teorico, ma il punto di ingresso privilegiato per operazioni criminali industriali. In questo contesto, la sicurezza del control plane diventa più critica della protezione dell’endpoint.

Difendersi da un worm cloud-native

Contrastare minacce come TeamPCP richiede un cambio di paradigma. È essenziale chiudere le API esposte, applicare least privilege su Kubernetes, monitorare creazioni anomale di pod e DaemonSet, e controllare l’egress verso repository pubblici e canali C2. Dopo un incidente, la rotazione completa dei segreti e il rebuild da Infrastructure as Code pulita diventano obbligatori, assumendo compromissione totale dell’ambiente. TeamPCP mostra come il ransomware del futuro non abbia bisogno di zero-day sofisticati. Gli basta un cloud mal configurato, un worm ben orchestrato e una rete di servizi moderni trasformati in arma.