Red Hot Cyber
Sicurezza Informatica, Notizie su Cybercrime e Analisi Vulnerabilità
Gli strumenti che le aziende usano per proteggere la propria supply chain sono diventati l’arma principale di un threat actor che, in cinque giorni, ha compromesso tre prodotti di sicurezza open source usati da decine di milioni di ambienti cloud in tutto il mondo. E non si è fermato lì.
Il 19 marzo 2026, il gruppo noto come TeamPCP — tracciato anche con gli alias DeadCatx3, PCPcat, ShellForce e CanisterWorm — ha avviato quella che i ricercatori di Wiz, Endor Labs, Mend e ReversingLabs definiscono la campagna di supply chain attack più consequenziale mai documentata in ambito CI/CD.
L’obiettivo non erano i sistemi produttivi delle vittime finali: erano i fornitori di fiducia che le vittime usano per auditare i propri sistemi. Dal punto di vista CTI, non siamo davanti a un incidente singolo, ma a una campagna multi-stadio con un’orchestrazione di livello professionale — e un’alleanza emergente con l’ecosistema LAPSUS$ che cambia radicalmente il profilo di rischio.
Tutto inizia in febbraio 2026, quando TeamPCP sfrutta una misconfiguration nelle GitHub Actions di Trivy, il vulnerability scanner open source sviluppato da Aqua Security. Il gruppo riesce a sottrarre un Personal Access Token privilegiato — probabilmente legato a un workflow di rilascio — che non viene mai completamente invalidato dai maintainer dopo una prima segnalazione.
Il token dormiente diventa la chiave di tutto. Il 19 marzo, TeamPCP lo usa per effettuare force-push su 75 dei 76 tag di versione di aquasecurity/trivy-action, avvelenando anche la release ufficiale v0.69.4 su GitHub e i container registry collegati (Docker Hub, GHCR, ECR). Nelle ventiquattro ore successive, lo stesso accesso viene usato per defaciare 44 repository di Aqua Security.
Il 21 marzo, la campagna si espande a Checkmarx KICS — il linter open source per Infrastructure as Code — con 35 tag hijackati tra le 12:58 e le 16:50 UTC. Il meccanismo è identico: credenziali ricavate dall’ambiente CI/CD di Trivy, che aveva KICS integrato nella propria pipeline.
Il 24 marzo, la terza mossa: LiteLLM, il layer Python di astrazione per i modelli linguistici, presente in circa il 36% di tutti gli ambienti cloud secondo Wiz, con 95 milioni di download mensili su PyPI. Le versioni 1.82.7 e 1.82.8 vengono pubblicate con payload malevolo, sfruttando le credenziali PyPI del maintainer ricavate ancora una volta dall’ecosistema Trivy. Mandiant Consulting CTO Charles Carmakal ha dichiarato pubblicamente che “We know of over 1,000 impacted SaaS environments right now that are actively dealing with this particular threat actor.”
Come spesso accade in questo tipo di campagne, ogni compromissione non è fine a sé stessa: è il pivot per la successiva. TeamPCP ha dimostrato di operare con una logica a cascata molto precisa — credential-pivot-expand — raramente osservata con questa efficienza in campagne supply chain pubblicamente documentate.
Il 24 marzo 2026 alle 19:00 UTC, l’account ufficiale di LiteLLM su X ha pubblicato un incident update che conferma in modo diretto sia la compromissione sia il vettore. Vale la pena leggerlo letteralmente, perché contiene tre dettagli operativi rilevanti.
“Compromised LiteLLM packages have been deleted. Proxy docker image users were not impacted — All dependencies are pinned on requirements.txt. Compromise came from Trivvy security scan dependency, looking into it with Google’s Mandiant Security.” — @LiteLLM su X, 24 marzo 2026 ore 19:00 UTC
In un secondo tweet dello stesso thread, pubblicato circa tre ore dopo: “The comprised packages were 1.82.7 and 1.82.8, they were quarantined and deleted, thanks to @pypi team.”
Questo comunicato aggiunge tre elementi concreti al quadro della campagna.
Il primo è la conferma esplicita del vettore: LiteLLM nomina direttamente “Trivvy security scan dependency” come origine della compromissione. Non è un’attribuzione speculativa dei ricercatori — è il maintainer del progetto che riconosce pubblicamente la catena Trivy → LiteLLM. Questo valida il modello di pivot-credenziali che TeamPCP ha usato sull’intera campagna.
Il secondo è una parziale buona notizia per una categoria di utenti: chi usa LiteLLM tramite le immagini Docker ufficiali non è stato colpito, perché in quel contesto le dipendenze sono “pinned” nel requirements.txt e non vengono risolte dinamicamente da PyPI. La compromissione ha colpito chi installava il pacchetto direttamente via pip install litellm.
Il terzo elemento è il coinvolgimento di Mandiant (ora parte di Google Cloud Security). LiteLLM ha dichiarato di aver ingaggiato Google’s Mandiant Security — il che suggerisce che la portata dell’impatto sugli ambienti dei clienti enterprise sia ritenuta sufficientemente significativa da giustificare il coinvolgimento di una delle strutture di incident response più qualificate al mondo (ndr coerente con la stima di Mandiant CTO Carmakal di oltre 1.000 ambienti SaaS compromessi).
Le versioni 1.82.7 e 1.82.8 sono state messe in quarantena e rimosse dal team PyPI — un’azione che riduce la superficie di nuove infezioni ma non risolve nulla per i sistemi che le avevano già installate e che ospitano il backdoor sysmon.service attivo.
Il payload distribuito attraverso Trivy e successivamente LiteLLM ha un’architettura a tre stadi che rivela un livello tecnico superiore alla media per un gruppo di questa natura.
Il primo stadio è un credential harvester che, all’installazione del pacchetto malevolo, recupera sistematicamente: chiavi SSH, credenziali cloud (AWS, GCP, Azure), configurazioni Kubernetes (~/.kube/config), file .env, wallet di criptovalute e API key di qualsiasi servizio trovato nel filesystem. Il tutto viene cifrato ed esfiltrato verso domini lookalike dei maintainer originali, rendendo il traffico difficilmente distinguibile dal baseline legittimo.
Il secondo stadio è un toolkit di lateral movement su Kubernetes: deploy di pod privilegiati su ogni nodo raggiungibile, con escalation sistematica a cluster-admin tramite account binding malevoli.
Il terzo stadio è la persistenza. TeamPCP installa un backdoor scritto in Python come ~/.config/systemd/user/sysmon.py, accompagnato da un’unità systemd (sysmon.service) che si avvia automaticamente e, in polling continuo, interroga un endpoint di comando e controllo per ricevere payload aggiuntivi. L’infrastruttura C2 è ospitata su un ICP Canister — la prima volta in assoluto che questa tecnica viene osservata in una campagna di questo tipo. L’uso di Internet Computer Protocol come dead-drop è tecnicamente rilevante perché rende il C2 di fatto impossibile da takedown con i metodi tradizionali di abuse report o domain seizure.
Nel contempo, attraverso npm, TeamPCP ha distribuito CanisterWorm: un worm auto-propagante che ha compromesso 47 pacchetti nel registro npm in meno di 24 ore dall’attacco a Trivy. Il vettore di infezione iniziale è un postinstall Node.js loader; la persistenza è garantita dallo stesso canister ICP. CVE-2026-33634 (CVSS: 9.4) traccia formalmente la vulnerabilità sfruttata nella catena Trivy.
L’ecosistema colpito alla fine della campagna copre cinque registri: GitHub Actions, Docker Hub, npm, OpenVSX e PyPI. In altre parole: ogni anello della toolchain DevSecOps moderna è stato toccato.
È qui che la valenza CTI della campagna TeamPCP supera la dimensione tecnica e diventa un segnale strategico.
Sul canale Telegram di TeamPCP, il gruppo ha pubblicato il seguente messaggio: “These companies were built to protect your supply chains yet they can’t even protect their own, the state of modern security research is a joke, as a result we’re gonna be around for a long time stealing terrabytes [sic] of trade secrets with our new partners.”
Il riferimento ai “new partners” non è vago. Ricercatori di Wiz, Flare e Resecurity hanno confermato quello che Ben Read di Wiz ha definito “a dangerous convergence between supply chain attackers and high-profile extortion groups like Lapsus$”. TeamPCP sta operando in coordinazione — o quantomeno con un accordo commerciale di accesso — con il collettivo noto come Scattered Lapsus$ Hunters (SLSH), la fusione operativa tra elementi di LAPSUS$, Scattered Spider e ShinyHunters.
Il connettore operativo è il modello a cui sta convergendo SLSH: brokered access. TeamPCP fornisce accesso di alta qualità — credenziali cloud, segreti Kubernetes, chiavi API — ricavate da ambienti di sviluppo che per definizione contengono le chiavi più sensibili di un’organizzazione. SLSH converte quell’accesso in estorsione, data leak e, tramite la piattaforma RaaS ShinySp1d3r (annunciata il 19 novembre 2025), in ransomware distribuito.
Dal punto di vista CTI, non siamo davanti a una collaborazione occasionale tra gruppi criminali, ma a qualcosa di strutturalmente più preoccupante: una divisione del lavoro specializzata, in cui il supply chain attack diventa il layer di accesso iniziale per un’operazione di estorsione organizzata. TeamPCP non ha bisogno di sapere chi è la vittima finale: produce accesso, SLSH lo monetizza.
Questo non equivale a una conferma formale dell’integrazione operativa, ma le evidenze convergenti — messaggi Telegram, analisi dell’infrastruttura e overlap degli IOC — suggeriscono che il modello sia già attivo.
Quello che colpisce della campagna TeamPCP non è solo l’ampiezza, ma la metodologia. In oltre sei settimane di attività documentata (da febbraio a fine marzo 2026), il gruppo non ha mai usato un exploit zero-day in senso stretto. Ha usato credenziali mal gestite, token non ruotati, GitHub Actions con permessi eccessivi, e la fiducia implicita che il settore ripone nei propri strumenti di sicurezza.
In altre parole: TeamPCP non ha sfondato le porte. Ha usato le chiavi che le aziende di sicurezza avevano lasciato nella serratura.
Il fatto che Trivy, KICS e LiteLLM — strumenti usati precisamente per fare sicurezza — siano stati i vettori primari ha un impatto psicologico e operativo che va oltre i numeri. Ogni pipeline DevSecOps che incorpora uno di questi tool è potenzialmente stata esposta. Ogni audit di sicurezza automatizzato che si basava su questi scanner ha prodotto risultati in un ambiente già compromesso.
Riguardo alla presenza italiana: non ci sono conferme indipendenti di organizzazioni italiane esplicitamente colpite, ma il grado di penetrazione di LiteLLM e dei GitHub Actions Trivy nell’ecosistema DevOps italiano — molto utilizzati in ambito bancario, fintech e pubblica amministrazione digitale — rende la superficie di rischio concreta.
Ogni team italiano che ha eseguito una pipeline con Trivy Action tra il 19 e il 22 marzo deve trattare l’ambiente come potenzialmente compromesso fino a verifica contraria.
La campagna TeamPCP ridisegna il modello di minaccia per chi lavora in sicurezza offensiva e difensiva. Non è la prima volta che strumenti di security vengono compromessi, ma è la prima campagna documentata in cui un attore singolo ha attraversato in sequenza cinque ecosistemi in sei settimane, con una persistenza che sfrutta un’infrastruttura decentralizzata immune ai takedown tradizionali.
Il salto qualitativo è l’alleanza con SLSH: TeamPCP non è più soltanto un gruppo di supply chain attack. È diventato un Initial Access Broker specializzato per l’ecosistema del cybercrime organizzato anglosassone. I terabyte di trade secret promessi nel messaggio Telegram non sono una bravata — sono un modello di business.
Non è un campanello d’allarme. È una campana che ha già suonato.
| Campo | Dettaglio |
|---|---|
| Tipo | Supply Chain Attacker / Initial Access Broker (IAB) con link ransomware/extortion |
| Alias | DeadCatx3, PCPcat, ShellForce, CanisterWorm |
| Attività documentata | Da dicembre 2025 (cloud-native worm) → marzo 2026 (supply chain campaign) |
| Vittime documentate | 1.000+ ambienti SaaS (fonte: Mandiant CTO, marzo 2026) |
| Ecosistemi colpiti | GitHub Actions, Docker Hub, npm (47 pkg), OpenVSX, PyPI |
| Tool compromessi | Trivy v0.69.4, Checkmarx KICS (35 tag), LiteLLM 1.82.7–1.82.8 |
| C2 | ICP Canister decentralizzato (icp0.io) — prima osservazione in campagna attiva |
| Partner extortion | Scattered Lapsus$ Hunters (LAPSUS$ + Scattered Spider + ShinyHunters) |
| RaaS collegato | ShinySp1d3r (annunciato novembre 2025) |
| Target primari | DevSecOps toolchain, ambienti Kubernetes/cloud-native, AI middleware |
| Italia | Nessuna vittima confermata; esposizione implicita per penetrazione LiteLLM/Trivy Action |
~/.config/systemd/user/sysmon.py e unità systemd sysmon.service*.icp0.io (ICP Canister C2 dead-drop)checkmarx.zone/raw per payload secondarisecurityContext.privileged: true non autorizzati in K8s