Google infiltrata in TeamPCP: così ha fermato gli hacker della supply chain
Un analista Mandiant ha osservato dall’interno una delle campagne cyber più estese del 2026.
Per mesi uno dei più pericolosi gruppi cyber specializzati negli attacchi alla filiera del software ha discusso obiettivi, credenziali rubate e nuove tecniche offensive senza sapere di avere un osservatore di Google nella propria cerchia interna. Dietro quella presenza c’era un analista di Mandiant, società controllata da Google, entrato nel gruppo attraverso una falsa identità costruita nel tempo.
L’operazione contro TeamPCP, conosciuto dai ricercatori di Google anche come UNC6780, segna un passaggio importante per la sicurezza informatica: dalla semplice analisi degli incidenti alla disruption attiva, cioè all’intervento diretto per impedire agli aggressori di sfruttare quanto già sottratto. La vicenda, raccontata da Austin Larsen del Google Threat Intelligence Group e ricostruita da Ars Technica, mostra anche quanto siano diventati fragili gli strumenti utilizzati quotidianamente dagli sviluppatori.
Come Google è entrata nella cerchia interna di TeamPCP
L’infiltrazione non sarebbe nata da un accesso improvvisato. Secondo Larsen, una persona operativa per Mandiant aveva trascorso mesi a costruire la credibilità di una propria identità sotto copertura presso un soggetto successivamente invitato in TeamPCP. Quando quest’ultimo entrò nel gruppo, anche la falsa identità dell’analista venne ammessa nelle conversazioni interne.
Da quella posizione Mandiant avrebbe potuto osservare quasi dall’inizio una parte rilevante delle attività. L’analista non partecipava agli attacchi e non incoraggiava i componenti del gruppo: il suo ruolo, secondo quanto dichiarato da Larsen, era quello di un osservatore silenzioso, vincolato da precise regole operative.
L’accesso non riguardava soltanto le chat. L’analista riuscì a vedere anche un server utilizzato per conservare nomi utente, password e token sottratti alle vittime. Google si trovò quindi davanti a un problema di scala: avvertire singolarmente ogni azienda avrebbe richiesto troppo tempo, mentre alcune credenziali potevano essere sfruttate immediatamente.
Che cos’è la cyber disruption
Non significa necessariamente violare i sistemi degli aggressori. Può comprendere la revoca di credenziali rubate, il blocco di infrastrutture, la notifica ai provider e la condivisione di prove con le autorità.
La strategia scelta fu contattare prima i fornitori presso i quali quelle credenziali potevano essere utilizzate, tra cui Amazon Web Services e Microsoft, chiedendone la revoca. Soltanto dopo partirono le notifiche dirette alle organizzazioni coinvolte. Il team inviò centinaia di segnalazioni, cercando di interrompere la catena prima che il furto di un token diventasse una nuova compromissione.
Perché gli attacchi alla supply chain sono così pericolosi
TeamPCP non puntava principalmente agli utenti finali. Il suo obiettivo erano gli strumenti attraverso cui viene prodotto e distribuito il software: repository, pacchetti open source, estensioni per ambienti di sviluppo e pipeline di continuous integration e continuous delivery, note come CI/CD.
Compromettendo uno strumento fidato, il codice malevolo poteva essere eseguito automaticamente nei sistemi di molte organizzazioni. Da lì rubava token e segreti con cui alterare altri progetti, generando un effetto a cascata. MITRE ATT&CK descrive TeamPCP come un gruppo finanziariamente motivato e cloud-native, attivo almeno dal settembre 2025 e orientato, dall’inizio del 2026, verso il furto sistematico di credenziali e la compromissione delle pipeline software.
Tra gli strumenti colpiti o associati alla campagna figurano il vulnerability scanner Trivy, KICS, LiteLLM e diversi pacchetti distribuiti attraverso npm, PyPI e Docker Hub. Il Google Threat Intelligence Group ha confermato di aver seguito numerosi incidenti legati a UNC6780 tra febbraio e maggio 2026, osservando tentativi di passare da software per l’intelligenza artificiale compromesso alle reti aziendali più ampie.
| Elemento colpito | Perché è strategico | Possibile conseguenza |
|---|---|---|
| Repository di codice | Contengono sorgenti e automazioni di rilascio | Pubblicazione di versioni modificate |
| Pipeline CI/CD | Gestiscono token e permessi elevati | Furto di segreti e compromissione dei build |
| Pacchetti open source | Sono installati automaticamente come dipendenze | Distribuzione del malware a valle |
| IDE ed estensioni | Operano sulle postazioni degli sviluppatori | Accesso a chiavi, codice privato e sessioni |
I numeri rendono visibile il rischio sistemico. Le autorità australiane, citate da Ars Technica, hanno collegato la campagna alla potenziale compromissione di oltre mille organizzazioni e al furto di più di mezzo milione di credenziali. Già a maggio, WIRED riportava almeno venti ondate e oltre cinquecento componenti software distinte alterate, senza contare le numerose versioni pubblicate per ciascun pacchetto.
Il fenomeno supera inoltre il singolo gruppo. Secondo i dati OpenSSF richiamati da Google, il numero dei pacchetti open source malevoli individuati è aumentato del 1.444% tra il 2024 e il 2025. Google ritiene altamente probabile che le tecniche basate su worm, credenziali rubate e compromissioni iterative vengano replicate da altri attori.
L’exploit zero-day sviluppato con l’aiuto dell’AI
L’accesso alle conversazioni interne avrebbe permesso a Google di scoprire anche un progetto distinto dagli attacchi alla supply chain. Un soggetto vicino al nucleo del gruppo stava utilizzando uno strumento di intelligenza artificiale per sviluppare un exploit contro un diffuso software di amministrazione via web.
Il codice sfruttava una vulnerabilità sconosciuta per aggirare l’autenticazione a due fattori, pur richiedendo credenziali valide. Google ottenne una copia dell’exploit, lo provò e verificò che poteva funzionare dopo alcune modifiche. La vulnerabilità fu quindi comunicata allo sviluppatore e corretta prima di un possibile utilizzo su vasta scala.
Il caso era già stato descritto, senza indicare TeamPCP, nel rapporto pubblicato da Google l’11 maggio 2026. GTIG dichiarò di avere un’elevata confidenza sull’impiego di un modello AI nella scoperta o nella trasformazione della vulnerabilità in un exploit, pur precisando di non ritenere coinvolto Gemini.
L’AI non rende automaticamente competente un aggressore
Può però ridurre drasticamente il tempo necessario per studiare codice, correggere errori e adattare strumenti offensivi. Questo accorcia la finestra disponibile ai difensori per identificare e chiudere una vulnerabilità.
La tendenza è confermata dal successivo AI Threat Tracker di settembre: nel secondo trimestre del 2026 Google ha osservato criminali compromettere una risorsa cloud e preparare una campagna automatizzata di raccolta delle credenziali in meno di sei ore. TeamPCP avrebbe inoltre cercato di ingannare assistenti di programmazione e scanner basati su modelli linguistici, nascondendo file malevoli nelle directory utilizzate da IDE e coding agent.
Gli errori operativi e gli arresti in Australia
L’infiltrazione non fu l’unico problema interno di TeamPCP. Nel tentativo di monetizzare l’enorme quantità di informazioni sottratte, il gruppo avrebbe condiviso l’accesso alle credenziali con altri criminali in cambio di una percentuale sulle estorsioni. Una di queste collaborazioni, con il gruppo ShinyHunters, sarebbe però degenerata: i partner avrebbero avviato proprie richieste di riscatto senza dividere i ricavi e consegnato a Larsen una copia delle conversazioni interne.
TeamPCP reagì restringendo la cerchia, cambiando server ed espellendo diversi account, compresa l’identità utilizzata dall’analista sotto copertura. A quel punto, tuttavia, Google disponeva già di informazioni sufficienti per seguire una serie di errori di sicurezza operativa.
Secondo la ricostruzione pubblicata da Ars Technica, alcuni file rubati sarebbero stati caricati su un account Google Drive riconducibile direttamente a uno dei presunti operatori. Google trasmise le informazioni all’FBI, mentre le autorità avviarono il percorso legale necessario per acquisire i dati.
Il 26 agosto 2026 la polizia australiana arrestò due uomini nell’Australia Occidentale. Il Dipartimento di Giustizia statunitense ha confermato l’incriminazione di Ruben Ian Thomson per reati informatici connessi agli attacchi attribuiti a TeamPCP. Le accuse devono ancora essere provate in giudizio e gli imputati sono da considerarsi innocenti fino a eventuale condanna definitiva.
Cosa devono fare aziende e sviluppatori
La lezione principale è che la sicurezza di una pipeline non coincide con la semplice scansione del codice. Un vulnerability scanner, un’estensione o un’azione automatizzata possono diventare essi stessi il vettore dell’attacco. Nella sua guida pubblicata il 24 settembre 2026, Mandiant raccomanda una difesa stratificata che comprenda postazioni degli sviluppatori, repository, sistemi di build e processi di pubblicazione.
- Sostituire token di lunga durata con credenziali temporanee, limitate e a privilegi minimi.
- Vincolare GitHub Actions e dipendenze a commit verificati, evitando tag modificabili.
- Separare gli ambienti di build e impedire l’accesso non necessario ai segreti di produzione.
- Monitorare IDE ed estensioni per processi anomali, accessi a chiavi e connessioni esterne inattese.
- Ruotare tutte le credenziali raggiungibili quando una pipeline esegue un componente compromesso.
- Conservare log, attestazioni e inventari delle dipendenze per ricostruire rapidamente l’incidente.
Dall’intelligence all’intervento diretto
L’operazione TeamPCP dimostra che la threat intelligence può essere molto più di un rapporto pubblicato dopo un incidente. La conoscenza raccolta dall’interno è stata trasformata in revoche di token, notifiche ai provider, correzioni di vulnerabilità e informazioni consegnate alle forze dell’ordine.
Questa impostazione solleva inevitabili questioni legali ed etiche: un ricercatore infiltrato deve osservare senza contribuire ai reati, preservare le prove e coordinarsi con aziende e autorità in più giurisdizioni. Ma mostra anche perché la sola difesa perimetrale non basta più. Quando gli attacchi si propagano attraverso strumenti fidati e l’AI accelera le operazioni, la velocità con cui l’intelligence diventa azione può determinare quante organizzazioni saranno colpite.
