Perché gli hacker stanno trasformando l'open source in un'arma globale

TeamPCP ha trasformato gli attacchi alla supply chain in campagne automatizzate contro GitHub, npm, PyPI e strumenti AI.

Il furto di codice sorgente ai danni di GitHub, confermato dopo l’installazione di un’estensione malevola per Visual Studio Code su una workstation interna, segna uno dei punti più critici nella storia recente degli attacchi alla supply chain software. Dietro l’operazione c’è TeamPCP, gruppo criminale che negli ultimi mesi ha compromesso centinaia di pacchetti open source distribuiti tramite npm, PyPI, Docker Hub e repository GitHub, introducendo malware in strumenti usati quotidianamente da sviluppatori e infrastrutture CI/CD.

Già nel 2020 il caso SolarWinds aveva mostrato quanto potesse essere devastante compromettere software considerato affidabile. Oggi però la situazione appare molto più aggressiva: TeamPCP ha automatizzato gran parte delle operazioni sfruttando token GitHub, credenziali cloud, workflow GitHub Actions e meccanismi di pubblicazione trusted publisher.

Secondo diverse società di sicurezza, il gruppo ha orchestrato oltre 20 campagne distinte in pochi mesi, compromettendo più di 500 componenti software e migliaia di versioni distribuite tramite registri pubblici.

La fragilità nascosta nella filiera open source

Chi segue IlSoftware.it ha già visto più volte il nome TeamPCP associato a compromissioni sempre più aggressive della supply chain software.

Negli ultimi mesi il gruppo ha colpito componenti molto diversi tra loro: dal gateway AI LiteLLM ai pacchetti collegati a Mistral AI, passando per Bitwarden CLI e numerosi strumenti DevOps distribuiti tramite npm e PyPI. In tutti i casi emerge lo stesso schema operativo: sfruttare la fiducia implicita che sviluppatori e aziende ripongono nei componenti open source per distribuire malware attraverso aggiornamenti apparentemente legittimi. Un attacco ha interessato direttamente le infrastrutture della Commissione Europea, con la sottrazione di 340 GB di dati.

Il problema riguarda quindi l’intera catena open source. Repository GitHub, workflow GitHub Actions, package manager come npm e PyPI, estensioni VSCode, strumenti CI/CD e librerie AI condividono oggi una rete di dipendenze estremamente interconnessa. Basta compromettere un maintainer, un token di pubblicazione o una pipeline automatizzata per trasformare un normale aggiornamento software in un vettore d’infezione capace di raggiungere migliaia di ambienti di sviluppo nel giro di poche ore.

Nel caso di GitHub, la compromissione è avvenuta tramite un’estensione Visual Studio Code alterata. Una volta installata, l’estensione ha sottratto credenziali e token interni consentendo agli attaccanti di accedere a circa 3.800 repository privati della piattaforma. GitHub ha dichiarato che i repository coinvolti contenevano codice interno e non dati dei clienti, ma TeamPCP ha pubblicizzato la vendita del materiale sottratto su un noto forum del mercato nero chiedendo almeno 50.000 dollari.

Come funziona la catena di compromissione usata da TeamPCP

La tecnica adottata dal gruppo sfrutta un meccanismo molto semplice nella teoria ma estremamente efficace nella pratica: compromettere uno strumento usato dagli sviluppatori per ottenere accesso ad altri ambienti di sviluppo. Una volta ottenuto il controllo di un account maintainer oppure di un workflow CI/CD, gli attaccanti pubblicano versioni malevole delle librerie, rese il più possibile legittime all’apparenza.

Molte campagne recenti hanno preso di mira repository npm molto utilizzati. In alcuni casi, il gruppo TeamPCP ha sfruttato workflow GitHub Actions configurati in modo vulnerabile all’attacco pull_request_target, una tecnica che permette di eseguire codice malevolo durante la gestione delle pull request. L’attacco è stato combinato con pratiche di cache poisoning, cioè la manipolazione dei dati temporanei usati dai sistemi di build e con il furto di token OIDC, credenziali temporanee conservate nella memoria dei runner GitHub Actions e utilizzate per autenticare i processi automatizzati.

In questo modo gli aggressori sono riusciti a pubblicare pacchetti con firme e attestazioni di provenienza valide secondo lo standard SLSA Level 3, eludendo così i controlli di sicurezza che dovrebbero garantire autenticità e integrità del software.

Il malware utilizzato per rubare i segreti degli sviluppatori

Il malware distribuito dal gruppo TeamPCP prende spesso il nome di Mini Shai-Hulud: si tratta di uno strumento malevolo specializzato nel furto di segreti presenti negli ambienti di sviluppo. I dati esfiltrati includono infatti token GitHub, chiavi AWS, credenziali Azure, secret Kubernetes, file .npmrc, chiavi SSH e sessioni Claude Code o Visual Studio Code.

Alcune varianti analizzano direttamente la memoria del processo Runner.Worker usato da GitHub Actions per estrarre segreti in chiaro.

Una caratteristica particolarmente pericolosa del malware riguarda la capacità di propagarsi automaticamente. Dopo aver sottratto i token di pubblicazione, il malware enumera tutti i pacchetti controllati dal maintainer compromesso e pubblica nuove versioni infette. In pratica ogni repository violato diventa un punto di diffusione per ulteriori compromissioni. Mini Shai-Hulud è quindi di fatto un vero e proprio worm di alto profilo.

Le contromisure che le aziende stanno adottando

La risposta del settore si sta concentrando su controlli più severi durante la gestione delle dipendenze software. Diverse aziende stanno introducendo policy di age-gating che bloccano automaticamente l’installazione di pacchetti pubblicati da poche ore. L’obiettivo è creare una finestra temporale utile ai sistemi di rilevamento per identificare comportamenti sospetti.

Molti team DevSecOps stanno inoltre adottando repository mirror interni: invece di scaricare direttamente i package da npm o PyPI, il software viene prima analizzato in sandbox e poi replicato nei registri aziendali.

La rotazione frequente dei token rimane una delle misure più efficaci; anche l’uso di account maintainer separati dai profili personali riduce l’impatto delle compromissioni.

Una crisi di fiducia che colpisce l’open source

L’impatto di TeamPCP va oltre il numero di repository compromessi: il gruppo ha dimostrato quanto sia fragile la catena di fiducia che sostiene lo sviluppo software moderno. Un singolo maintainer compromesso può trasformarsi in un moltiplicatore di attacchi capace di propagarsi attraverso migliaia di build automatiche nel giro di poche ore.

La situazione diventa ancora più delicata nel mondo AI: framework Python, SDK LLM, estensioni Visual Studio Code e agenti di coding automatico gestiscono spesso privilegi elevati, token cloud e accesso diretto a repository GitHub. Un malware installato in questi ambienti può raggiungere rapidamente infrastrutture Kubernetes, cluster GPU e pipeline di addestramento.

Facile ipotizzare che le tecniche usate da TeamPCP possano continuare a concretizzarsi in attacchi su larga scala. Il successo delle campagne dimostra che gli ambienti di sviluppo rappresentano un obiettivo ad altissimo valore: non solo permettono di sottrarre dati, ma consentono di compromettere software destinato a milioni di utenti finali.

La conclusione da tenere a mente è che l’aggiornamento automatico di una dipendenza non può e non deve essere considerato un’operazione innocua. Nel momento in cui il codice modificato arriva sulla macchina dello sviluppatore, spesso il danno è già iniziato.

Ti consigliamo anche

Link copiato negli appunti