Dentro TeamPCP: come Google ha interrotto una campagna di supply chain dalla chat interna degli hacker

Google ha monitorato TeamPCP dall’interno del gruppo criminale informatico mentre comprometteva software open source, sottraeva credenziali degli sviluppatori e si espandeva fino a coinvolgere più di mille aziende. Questo accesso ha permesso ai difensori di revocare i dati di autenticazione rubati, avvertire le vittime e ottenere codice funzionante per un exploit zero-day assistito dall’AI.

L’operazione ha inoltre rivelato un ecosistema criminale frammentato. TeamPCP si è alleata con ShinyHunters per monetizzare il proprio accesso, salvo poi vedersi sottrarre dal gruppo le credenziali rubate, i pagamenti trattenuti e i messaggi interni di TeamPCP divulgati pubblicamente.

Successivamente sono stati arrestati e incriminati due cittadini australiani, Ruben Ian Thomson e Louis Michael Gaebler. Le autorità li hanno descritti come partecipanti di primo piano di TeamPCP, ma l’attribuzione resta un’ipotesi investigativa e i capi d’accusa specifici non sono stati resi noti.

I pacchetti compromessi diventavano porte d’accesso per la vittima successiva

TeamPCP sembra essere comparsa pubblicamente alla fine del 2025. La campagna seguiva un modello di supply chain a cascata, in cui ogni intrusione riuscita creava opportunità per ulteriori compromissioni.

Gli aggressori prendevano innanzitutto il controllo di un progetto open source o di un fornitore di software. Inserivano quindi malware progettati per sottrarre credenziali nel software compromesso, esponendo nomi utente, password e token di accesso appartenenti agli sviluppatori e agli utenti a valle.

TeamPCP poteva utilizzare quei dati di autenticazione per entrare in un altro progetto, ambiente cloud o azienda tecnologica. Il malware introdotto nel software appena compromesso produceva un’ulteriore raccolta di credenziali, consentendo al ciclo di proseguire.

Secondo l’indagine di Google, la campagna ha colpito centinaia di pacchetti open source e ha consentito violazioni ai danni di più di mille aziende. Tra i prodotti e le organizzazioni coinvolti nell’operazione figuravano:

• Trivy, uno scanner di sicurezza open source;
• LiteLLM, uno strumento API utilizzato dalle applicazioni di AI;
• l’azienda di sicurezza delle applicazioni web Checkmarx;
• TanStack, una libreria per applicazioni web;
• Mistral AI e la sua piattaforma di AI per le aziende;
• GitHub;
• Mercor, azienda specializzata in contratti per i dati;
• i dispositivi dei dipendenti di OpenAI;
• i dispositivi dei dipendenti della Commissione europea.

Non sono state rese note altre vittime. Non sono stati divulgati neppure i pacchetti precisi, i numeri delle release malevole e le versioni software interessate, impedendo alle organizzazioni di fare affidamento su un elenco definitivo dell’esposizione basato sulle versioni.

TeamPCP ha affiancato queste intrusioni a Mini Shai-Hulud, un worm autoriproducente progettato per automatizzare l’espansione negli ambienti di sviluppo. Il nome sembrerebbe richiamare Shai-Hulud, un worm distinto associato a una tecnica di supply chain simile nel settembre 2025. Non è stato stabilito alcun collegamento tra TeamPCP, gli indagati arrestati e quella campagna precedente.

Un’identità sotto copertura è entrata nella cerchia interna di CanisterWorm

Un analista di Mandiant ha contattato TeamPCP utilizzando un’identità online inventata. Dopo aver conquistato la fiducia di una persona invitata nell’organizzazione, a marzo l’analista è stato ammesso a CanisterWorm, una chat interna che contava circa dodici partecipanti.

Austin Larsen del Google Threat Intelligence Group, che dovrebbe discutere l’indagine durante una conferenza SentinelOne LABScon, non era l’agente sotto copertura.

L’analista ha evitato di partecipare agli attacchi, assistere le intrusioni o incoraggiare i membri di TeamPCP. L’identità fittizia comunicava invece solo quando necessario per mantenere l’accesso e osservava in silenzio l’infrastruttura, le discussioni, i dati rubati e i piani futuri del gruppo.

Questa posizione ha consentito di accedere a un server che conteneva credenziali sottratte alle vittime. La raccolta comprendeva password, nomi utente e token di accesso catturati attraverso le compromissioni software del gruppo, oltre a materiale apparentemente in preparazione per un’estorsione.

Google si è trovata di fronte a un problema di contenimento: contattare individualmente ogni proprietario delle credenziali avrebbe concesso agli aggressori più tempo per utilizzare gli accessi rubati. Gli investigatori si sono rivolti invece ai fornitori in grado di invalidare grandi quantità di credenziali, tra cui Amazon Web Services e Microsoft.

GTIG ha inviato centinaia di notifiche ai fornitori e alle organizzazioni interessate. Molti destinatari hanno agito immediatamente, consentendo di revocare credenziali e token prima che potessero agevolare ulteriori intrusioni.

Questa strategia incentrata sui fornitori ha affrontato una caratteristica distintiva degli incidenti di supply chain. Un singolo token sviluppatore rubato può compromettere repository, release di pacchetti, sistemi di build e risorse cloud appartenenti a diverse organizzazioni. Revocarlo a livello di servizio può quindi chiudere contemporaneamente molteplici percorsi d’attacco.

L’AI ha contribuito a creare un bypass funzionante dell’autenticazione a due fattori

La sorveglianza interna ha portato alla luce un altro membro di TeamPCP impegnato nello sviluppo di un exploit zero-day contro un prodotto di login ampiamente utilizzato. L’aggressore si serviva di uno strumento di AI per contribuire alla creazione di codice in grado di aggirare il controllo di autenticazione a due fattori del prodotto.

Google ha ottenuto l’exploit e lo ha testato. Sebbene i ricercatori abbiano dovuto apportare diverse modifiche, alla fine il codice ha funzionato, dimostrando un tentativo di sfruttamento assistito dall’AI ai danni di una vulnerabilità precedentemente sconosciuta, nel corso di un’operazione criminale in corso.

Lo sviluppatore interessato è stato informato e ha corretto la vulnerabilità. Google ha descritto l’episodio in un case study pubblicato a maggio, ma non ha identificato TeamPCP né rivelato che i suoi investigatori avevano recuperato il codice dalle comunicazioni del gruppo.

Il nome del prodotto, il fornitore, l’identificativo della vulnerabilità e la versione corretta restano sconosciuti. Di conseguenza, non esiste un CVE pubblico che le organizzazioni possano utilizzare per monitorare l’esposizione e non sono disponibili informazioni che stabiliscano se la vulnerabilità compaia nel catalogo delle Known Exploited Vulnerabilities di CISA.

Queste omissioni limitano la verifica indipendente e le attività di remediation mirate. Gli amministratori non possono stabilire, sulla base delle informazioni disponibili, se utilizzano la tecnologia di login interessata o se una specifica versione installata contiene il codice corretto.

L’incidente illustra comunque un uso concreto dell’AI nello sviluppo offensivo. Lo strumento non ha eliminato la necessità di apportare modifiche manuali, ma ha contribuito alla realizzazione di codice mirato a eludere una misura di sicurezza critica per l’autenticazione.

ShinyHunters ha rivolto contro TeamPCP gli accessi rubati dal gruppo

Nonostante sostenesse di detenere credenziali associate a più di mezzo milione di utenti, TeamPCP faticava a trasformare gli accessi in entrate. Larsen ha stimato che il gruppo avesse guadagnato solo decine di migliaia di dollari dalle estorsioni, molto meno dei milioni ottenuti da organizzazioni criminali più esperte.

TeamPCP ha quindi offerto ad altri gruppi l’accesso alla propria raccolta di credenziali in cambio di una quota dei pagamenti derivanti dalle estorsioni. Tra i partner figurava ShinyHunters, una prolifica organizzazione dedita al furto di dati e alle estorsioni.

Intorno ad aprile, alcune settimane dopo l’inizio dell’accordo, ShinyHunters ha iniziato a utilizzare autonomamente le credenziali di TeamPCP e non ha versato la quota concordata dei proventi. Ha inoltre inviato a Larsen una copia completa dei messaggi archiviati sul server di TeamPCP, apparentemente senza sapere che Google disponeva già dell’accesso attraverso l’identità Mandiant.

ShinyHunters ha deriso pubblicamente TeamPCP su X. TeamPCP ha reagito limitando le adesioni, trasferendo le informazioni rubate su un altro server e rimuovendo ShinyHunters e diversi altri partecipanti da CanisterWorm.

Anche l’identità Google sotto copertura è stata espulsa. I responsabili di TeamPCP hanno ordinato ai membri rimasti di non continuare a condividere informazioni con ShinyHunters.

La disputa non ha posto fine all’indagine di Google. Ha invece costretto l’operazione a passare dall’osservazione diretta all’analisi dell’infrastruttura, dei record archiviati dei forum e dell’attribuzione digitale.

I vecchi record dei forum hanno collegato uno pseudonimo a Ruben Ian Thomson

I dati trapelati relativi agli account di BreachForums hanno associato una delle identità più attive di CanisterWorm all’indirizzo Gmail [email protected].

Google ha esaminato vecchi archivi dei forum e ha identificato una disputa del 2019 che coinvolgeva lo pseudonimo “sheepstealing” e un venditore di chiavi piratate di Microsoft Office. Durante il litigio, l’utente ha chiesto un rimborso su un account PayPal collegato a [email protected].

Gli investigatori hanno trovato un altro collegamento dopo il trasferimento del repository di credenziali di TeamPCP. Le informazioni ottenute tramite un partner fidato hanno mostrato che il nuovo server veniva sottoposto a backup su un account Google Drive associato a [email protected].

Google ha trasmesso le informazioni identificative all’FBI. Larsen ha riferito che un agente ha risposto nel giro di pochi minuti. Circa un mese dopo, le autorità statunitensi hanno completato la procedura necessaria per ottenere da Google i dati dell’account di Thomson.

La polizia australiana ha successivamente arrestato Thomson in un’abitazione di periferia. Louis Michael Gaebler è stato arrestato nell’ambito della stessa indagine. Entrambi avevano poco più di vent’anni e la Australian Federal Police li ha descritti come partecipanti di primo piano di TeamPCP.

L’AFP non li ha identificati nella propria dichiarazione pubblica a causa delle norme australiane sulla privacy. Nessuno dei due ha rilasciato dichiarazioni e i capi d’accusa precisi non sono stati riportati. Anche il giornalista e ricercatore di cybersecurity Brian Krebs potrebbe aver identificato Thomson in modo indipendente prima degli arresti.

I difensori devono considerare le credenziali degli sviluppatori come un’esposizione estesa all’intero incidente

Le organizzazioni potenzialmente interessate da TeamPCP non possono fare affidamento su un elenco completo di pacchetti o versioni. Le attività di difesa dovrebbero quindi concentrarsi sulle credenziali, sull’integrità delle release e sui sistemi utilizzati per creare e pubblicare il software.

Le password, le chiavi API, i token dei repository e le credenziali cloud esposti sulle workstation degli sviluppatori dovrebbero essere ruotati immediatamente. La revoca è preferibile al solo cambio della password, perché i token a lunga durata possono continuare a funzionare indipendentemente dalla password dell’utente.

I team di sicurezza dovrebbero inoltre verificare:

• i repository del codice sorgente, alla ricerca di commit, manutentori o artefatti di release non autorizzati;
• le piattaforme CI/CD, per individuare workflow alterati e accessi sconosciuti ai secret;
• i registri dei pacchetti, alla ricerca di release create al di fuori delle normali procedure di pubblicazione;
• gli endpoint degli sviluppatori, per individuare il furto di credenziali e l’attività di Mini Shai-Hulud;
• gli ambienti AWS e Microsoft, per individuare sessioni create con credenziali esposte;
• lo storage cloud, per individuare backup sospetti o la sincronizzazione di informazioni rubate.

Gli account compromessi degli sviluppatori dovrebbero essere disabilitati finché non saranno esaminate la loro attività, i fattori di autenticazione e i token collegati. Le organizzazioni che utilizzano Trivy, LiteLLM, TanStack e le altre tecnologie citate dovrebbero verificare la provenienza dei pacchetti, ma l’assenza di versioni divulgate significa che la loro semplice presenza non dimostra una compromissione.

Le azioni di Google hanno fatto parte di un più ampio cambiamento verso l’interruzione diretta delle attività criminali attraverso la sua Cyber Disruption Unit. Invece di limitarsi a pubblicare informazioni di intelligence, l’azienda ha utilizzato il proprio accesso per invalidare le risorse degli aggressori, informare i fornitori, proteggere le vittime, mettere in sicurezza una patch per una vulnerabilità zero-day e supportare le autorità nell’attribuzione.

L’indagine sotto copertura su TeamPCP dimostra quanto possa propagarsi in profondità una singola identità sviluppatore rubata attraverso la moderna distribuzione del software. In questa campagna, i pacchetti considerati affidabili non erano semplicemente degli obiettivi: erano il meccanismo per raggiungere l’organizzazione successiva.