TeamPCP: la gang che ha avvelenato la supply chain del software e violato la Commissione Europea

Tra marzo e aprile 2026, un gruppo criminale noto come TeamPCP ha orchestrato uno degli attacchi alla supply chain del software più devastanti degli ultimi anni: in meno di dieci giorni ha compromesso strumenti di sicurezza usati da milioni di sviluppatori, rubato credenziali da oltre 500.000 sistemi e — grazie a una chiave AWS sottratta — ha violato le infrastrutture cloud della Commissione Europea, esfiltrando 340 GB di dati da 71 enti dell’Unione.

La catena del veleno: come funziona una supply chain attack

Attaccare uno strumento usato da migliaia di organizzazioni significa colpire migliaia di bersagli con una singola operazione. TeamPCP ha applicato questa filosofia in modo sistematico, con una raffinatezza tecnica che ha sorpreso persino i ricercatori più esperti. Il punto critico sfruttato è quello che in gergo si chiama trusted build pipeline: le pipeline CI/CD che automaticamente scaricano dipendenze, eseguono scanner di sicurezza e pubblicano package su registri pubblici come npm e PyPI. Una volta compromessa questa infrastruttura, il codice malevolo si propaga silenziosamente a tutti gli utilizzatori del pacchetto.

Il punto di partenza: Trivy e le credenziali rubate

Il 19 marzo 2026, TeamPCP ha sfruttato credenziali CI/CD parzialmente ruotate dopo un incidente minore avvenuto a fine febbraio nel repository GitHub di Aqua Security Trivy — uno degli scanner di vulnerabilità open-source più utilizzati al mondo. Con queste credenziali, il gruppo ha pubblicato una versione malevola (v0.69.4) del tool ed eseguito il force-push di 76 dei 77 tag della GitHub Action aquasecurity/trivy-action, sostituendo i tag legittimi con commit malevoli.

In parallelo, il gruppo ha deturpato l’organizzazione GitHub di Aqua Security, rinominando 44 repository con il prefisso “tpcp-docs-” — un messaggio esplicito: “TeamPCP Owns Aqua Security.”

L’effetto domino: npm, Checkmarx, LiteLLM, Telnyx

A partire dal 20 marzo, TeamPCP ha sfruttato le credenziali sottratte per propagarsi orizzontalmente su altri ecosistemi:

• npm (20–22 marzo): Compromessi più di 45 pacchetti, inclusi scope @emilgroup e @opengov, con deployment di un worm auto-replicante focalizzato su payload Kubernetes.
• Checkmarx (23 marzo): Le GitHub Actions KICS e AST sono state backdoorate; compromesse anche due estensioni OpenVSX.
• LiteLLM (24 marzo): Due versioni del popolare AI gateway PyPI (1.82.7 e 1.82.8) pubblicate con payload malevoli. Particolarmente insidiosa la 1.82.8: il malware è stato iniettato in un file .pth denominato litellm_init.pth. L’interprete Python processa automaticamente i file .pth all’avvio, il che significa che il malware si eseguiva ad ogni avvio di qualsiasi processo Python, indipendentemente dal fatto che LiteLLM fosse mai importato.
• Telnyx (27 marzo): Versioni 4.87.1 e 4.87.2 avvelenate con un payload particolarmente creativo: il malware veniva scaricato da un file WAV (ringtone.wav) — un secondo stadio XOR-cifrato nascosto steganograficamente nei frame audio del file.

L’anatomia del payload: sei fasi per compromettere tutto

Il payload di LiteLLM operava in sei fasi distinte:

1. Raccolta credenziali: variabili d’ambiente, chiavi SSH, credenziali cloud (AWS, GCP, Azure), token Kubernetes, configurazioni Docker, cronologia shell, credenziali database, wallet file, segreti CI/CD.
2. Cifratura: chiave di sessione AES-256 con wrapping RSA-4096.
3. Esfiltrazione: dati inviati a models.litellm[.]cloud con header HTTP X-Filename: tpcp.tar.gz.
4. Persistenza: creazione di ~/.config/sysmon/sysmon.py e unità systemd sysmon.service.
5. Payload secondario: polling di https://checkmarx[.]zone/raw per eseguire codice controllato dagli attaccanti.
6. Propagazione Kubernetes: se disponibili token di service account, creazione di pod privilegiati node-setup-* per espandersi nel cluster.

Vale la pena sottolineare un dettaglio agghiacciante sul deploy Kubernetes: sui sistemi ritenuti non iraniani, veniva creato un DaemonSet host-provisioner-std; sui sistemi con caratteristiche riconducibili all’Iran, veniva invece lanciato un container denominato kamikaze che cancellava il filesystem dell’host e forzava il reboot del nodo — un payload distruttivo deliberatamente riservato a un target geopolitico specifico.

Il colpo più clamoroso: la Commissione Europea

Il 19 marzo, il payload Trivy aveva silenziosamente sottratto le chiavi API AWS della piattaforma Europa di hosting web dell’Unione Europea — chiavi che, come si è scoperto, funzionavano come master key sull’intera infrastruttura cloud della Commissione. Passano cinque giorni prima che l’accesso venga rilevato.

La timeline della crisi istituzionale:

• 19 marzo: accesso iniziale, chiavi AWS sottratte tramite Trivy
• 24 marzo: rilevamento dell’accesso anomalo (5 giorni di dwell time)
• 25 marzo: CERT-EU viene notificato
• 28 marzo: le credenziali compaiono sul dark web, pubblicate da ShinyHunters
• 2 aprile: la Commissione Europea divulga ufficialmente l’incidente

Il bilancio: 340 GB esfiltrando (91,7 GB compressi) da 71 enti clienti della piattaforma EU — 42 dipartimenti interni della Commissione più 29 altri enti UE. Inclusi circa 52.000 file email (2,22 GB di comunicazioni in uscita). Almeno 30 entità dell’Unione potenzialmente impattate, rendendo questo uno dei breach più significativi nella storia delle istituzioni europee.

La comparsa dei dati su ShinyHunters apre ulteriori interrogativi: il gruppo criminale opera indipendentemente da TeamPCP, suggerendo che le credenziali siano state cedute o vendute, complicando ulteriormente il quadro di attribuzione.

Indicatori di compromissione (IoC)

Rete

models.litellm[.]cloud
checkmarx[.]zone
83.142.209[.]203 / 83.142.209[.]11
46.151.182[.]203
championships-peoples-point-cassette.trycloudflare.com
investigation-launches-hearings-copying.trycloudflare.com
aquasecurtiy[.]org  (typosquat)

Filesystem

litellm_init.pth
~/.config/sysmon/sysmon.py
~/.config/systemd/user/sysmon.service
/tmp/pglog
/tmp/.pg_state

Kubernetes

Pod names: node-setup-*
DaemonSets: host-provisioner-std, host-provisioner-iran
Container names: kamikaze, provisioner

Cosa fare se si è stati esposti

• Aggiornare immediatamente i package colpiti alle versioni sicure (verificare i changelog ufficiali dei maintainer)
• Ruotare tutte le credenziali presenti sull’host: AWS, GCP, SSH, database, token CI/CD
• Verificare la presenza del file litellm_init.pth e del servizio sysmon.service
• Analizzare i log di rete per traffico verso i domini e IP indicati negli IoC
• Se si opera Kubernetes, ispezionare pod e DaemonSet per anomalie
• Se si trovano tracce di compromissione, considerare l’host come completamente compromesso e procedere a re-imaging

Fonti primarie: Datadog Security Labs | Palo Alto Unit42 | SANS ISC