GTIG AI Threat Tracker: da un prompt a migliaia di credenziali in sei ore

Il Google Threat Intelligence Group ha pubblicato l'edizione Q2 2026 del suo AI Threat Tracker l'8 settembre 2026. Il caso su cui si basa il report è abbastanza breve da poterlo enunciare chiaramente: un attore sospettato di agire per motivazioni finanziarie si è impadronito di una risorsa cloud appartenente a una vittima, ha inserito un prompt e una serie di istruzioni pre-scritte per l'agente in un chatbot di programmazione basato sull'IA, ed è riuscito a raccogliere migliaia di credenziali di terze parti in meno di sei ore, con l'agente che ha gestito autonomamente la scansione delle vulnerabilità, la risoluzione dei problemi e la rotazione degli IP. Lo stesso report descrive server MCP trojanizzati su PyPI, un ladro di credenziali che ruba l'identità stessa di un sistema di build affinché i suoi pacchetti con backdoor arrivino con attestazioni SLSA Build 3 valide e firmate crittograficamente, e testo avversariale volto a far sì che gli scanner di sicurezza basati su LLM si rifiutino di leggere il codice sottostante. Tutto ciò è il resoconto di Google della propria telemetria. Questo report è catalogato, con il suo grado di confidenza e le sue fonti citate, in l'archivio degli incidenti di IA, che contiene insieme ad esso ogni altro incidente documentato di questa serie.

Nessuna delle affermazioni sostanziali è stata verificata da una parte che non stia ripetendo Google. Help Net Security ha trattato il tracker il giorno della pubblicazione, la Cloud Security Alliance ha pubblicato una nota di ricerca il giorno successivo, e Lineaje ha pubblicato un'analisi su DUSTMAKER il 17 settembre; ciascuno è un riassunto o una sovrapposizione analitica sulla divulgazione di Google, e Lineaje lo afferma essa stessa, osservando che GTIG «descrive diverse capacità correlate di DUSTMAKER anziché un'unica traccia di esecuzione end-to-end osservata». La seconda fonte citata accanto a questo documento, un elemento «threat pulse» di threatops.tech datato 11 settembre 2026, è una riformulazione anziché un secondo testimone: non aggiunge alcun resoconto, non contesta alcun dato e innalza l'etichetta di gravità senza spiegare rispetto a cosa sia misurata. La copertura non concorda pienamente nemmeno sul nome dell'edizione — Help Net Security lo chiama tracker del Q3 2026 pur datando il suo caso principale al Q2 2026 — il che è una differenza di numerazione, non un conflitto fattuale.

L'archivio lo registra come report anziché come incidente: grado di attendibilità A, non contestato, nessun dato quantificato sul danno reale registrato a suo carico. Tale classificazione descrive la qualità della documentazione, non l'entità del danno. Google conta le credenziali, non le vittime. Il tracker non indica quante organizzazioni siano state coinvolte nella campagna durata sei ore, chi fossero, quale chatbot sia stato usato, né se qualcuna delle credenziali rubate sia stata poi venduta o usata.

Le sei ore descritte da GTIG e i tre lavori che l'agente ha svolto da solo

La sequenza del rapporto va dall'accesso al risultato con un coinvolgimento umano minimo nel mezzo. L'attore ha compromesso una risorsa cloud, poi ha utilizzato un chatbot commerciale di programmazione basato sull'IA insieme a quelli che GTIG chiama "un prompt" e "un insieme di istruzioni per l'agente" — i playbook in markdown che oggi risiedono nei repository come file AGENTS.md — per pianificare, costruire ed eseguire l'operazione. La stessa definizione di Google per il risultato è una "campagna di raccolta massiva di credenziali abilitata da agenti", completata "in meno di sei ore".

Tre attività sono descritte come autonome, e sono le tre che altrimenti avrebbero richiesto l'attenzione di un operatore:

• La pipeline di scansione delle vulnerabilità, che le istruzioni dell'agente consentono all'IA di "gestire autonomamente", nella formulazione che Help Net Security cita da GTIG.

• Risoluzione dei problemi in tempo reale di qualunque cosa sia emersa dalla scansione, così che un errore non bloccasse l'esecuzione in attesa di una decisione.

• Rotazione degli IP, così che i tentativi successivi partissero da indirizzi diversi senza che nessuno impartisse il comando.

Dove è stata eseguita l'operazione è importante tanto quanto la velocità con cui è stata eseguita. Operando dall'infrastruttura cloud della vittima stessa, l'attore ha instradato il traffico attraverso gli intervalli IP legittimi della vittima. Le richieste che sembrano provenire dall'interno di un'organizzazione sono esattamente quelle che le difese basate sulla reputazione sono meno attrezzate a mettere in discussione, e il rapporto lo registra come conseguenza dell'aver operato dall'infrastruttura della vittima stessa.

Ciò che il rapporto non contiene è tanto rivelatore quanto ciò che contiene. Non c'è una cronometratura per singolo passaggio, quindi "meno di sei ore" è un'unica misurazione dell'intera esecuzione e non è scomponibile in un grafico. Non c'è alcun nome per l'attore oltre a "presunto movente finanziario", nessuna vittima e nessuna indicazione di quale modello o chatbot di quale fornitore fosse coinvolto. Il tracker tratta il caso come un esempio pratico di una tendenza, ed è scritto a un livello di dettaglio funzionale a quello scopo anziché al livello che vorrebbe un addetto alla risposta agli incidenti.

Un server esposto che è diventato una dashboard di 23.800 segreti

Un secondo riscontro nella stessa sezione è più concreto, e costituisce un caso a sé. GTIG ha individuato un server di command-and-control esposto che ospitava un framework automatizzato per la ricognizione e la gestione delle credenziali, da essa chiamato Recon. L'elenco della directory era leggibile e tradiva l'architettura: AGENTS.md, KNOWLEDGE.md, agentic_vuln_research.md, oltre a una directory modulare .openclaw/ e a una directory memory/. Quei nomi di file sono l'impronta digitale di uno stack di agenti più che di un implant su misura — istruzioni, conoscenze accumulate e un piano di ricerca, tutto su disco dove gli strumenti dell'operatore possono leggerlo.

La stessa directory, in seguito, fungeva da dashboard frontend live che organizzava e convalidava più di 23.800 segreti raccolti, incluse chiavi API per servizi cloud e AI. GTIG caratterizza il cambiamento che ciò rappresenta come un passaggio "da infostealer passivi e incentrati sugli endpoint a una raccolta agentica offensiva" — ovvero, da malware che arraffa ciò che può da un singolo laptop a strumenti che continuano a lavorare sui target già raggiunti.

Due avvertenze accompagnano quel numero. Ventitremilaottocento è un conteggio di segreti, non di persone o aziende, e il rapporto non stabilisce una corrispondenza tra gli uni e le altre. Inoltre GTIG non dichiara se il server Recon e la campagna di sei ore siano la stessa operazione; sono presentati come osservazioni separate nella stessa sezione, quindi considerarli un'unica vicenda sarebbe un'inferenza che il rapporto non compie.

DUSTMAKER e l'attestazione che dichiara correttamente che il pacchetto è autentico

La metà della catena di approvvigionamento del tracker riguarda UNC6780, che Google traccia anche come TeamPCP, un gruppo motivato da interessi economici che compromette l'infrastruttura open source da marzo 2026 su PyPI, npm e Docker Hub. Il suo metodo con gli strumenti di IA è diretto: account di sviluppatori compromessi sono stati usati per pubblicare fork di server MCP legittimi con trojan, con tiktoken_mcp citato come esempio su PyPI, e codice malevolo è stato iniettato nei repository organizzativi ufficiali, inclusi azure-functions-mcp-extension. GTIG osserva che i payload e gli hook malevoli per il workspace venivano poi importati automaticamente ogni volta che le risorse venivano scaricate o clonate — nessuna esca separata, nessun secondo passaggio.

Il suo credential stealer, DUSTMAKER, è il punto in cui si trova l'osservazione tecnica più utile del report. La catena è breve. Lo stealer rileva di essere in esecuzione in un ambiente CI/CD; GTIG scrive che "se confermato," estrae token OIDC dalla memoria di processo di un runner di GitHub Actions. Usa quei token per autorizzarsi come publisher attendibile. Poi pubblica versioni compromesse del pacchetto che portano attestazioni SLSA Build 3 valide e firmate crittograficamente. Nulla in quella catena è falsificato. L'attestazione è reale, emessa a un'identità reale, per una build realmente avvenuta — di codice scritto dall'attaccante. La conclusione di GTIG è la frase che conta per chiunque si affidi alla provenienza: "I pacchetti pubblicati con token validi supereranno i controlli automatici di attendibilità degli agenti di codifica AI."

Il resto del comportamento di DUSTMAKER è rivolto ai luoghi che i difensori non sorvegliano. Rilascia e modifica file all'interno delle directory di workspace degli assistenti di coding AI e degli IDE — .claude/, .vscode/, .cursor/ — dove si confonde con il rumore degli sviluppatori ed evita le posizioni che il rilevamento endpoint monitora effettivamente, come le chiavi del registro di Windows o /etc/cron.*. Scrive configurazioni che fanno sì che l'IDE o l'estensione AI eseguano uno script come setup.mjs all'apertura del workspace, il che trasforma l'apertura di una cartella in esecuzione di codice. Crea attività di pipeline con nomi a tema AI come "Copilot Setup" per cercare token, ed effettua chiamate API per eliminare i log di esecuzione dei workflow affinché l'esecuzione non compaia nell'interfaccia di GitHub.

Il malware che chiede allo scanner di guardare altrove

L'ultimo meccanismo è il meno verificato dei tre. Gli script loader JavaScript di DUSTMAKER si aprono con testo di prompt adversarial incorporato come commenti — in _index.js tra gli altri — che fa riferimento ad armi biologiche e nucleari e include una richiesta di specifiche per un dispositivo a fissione di tipo implosivo da 20 kilotoni. La valutazione di GTIG è che questo fosse "probabilmente inteso a far sì che gli scanner di sicurezza LLM falliscano o saltino l'analisi del codice JavaScript malevolo sottostante a causa di rifiuti di sicurezza o di policy".

L'etichetta su quella frase conta. È un'affermazione sull'intento, dedotta dal testo che il loader trasporta, non una dimostrazione che un qualche scanner abbia effettivamente rifiutato. Il rapporto non nomina uno scanner che abbia saltato il file, non riporta un tasso di bypass e non dice che la tecnica abbia funzionato. Ciò che è stabilito è che qualcuno ha scritto l'esca e l'ha spedita all'interno di un credential stealer — il che è di per sé prova che gli attaccanti si aspettano che il triage basato su LLM sia nel percorso.

UNC6508, MIDNIGHT NEPTUNE e CALANQUE ION si trovano nello stesso report

Il materiale del tracker connesso allo Stato è più ampio del suo materiale criminale, e in gran parte meno automatizzato. UNC6508, un gruppo legato alla RPC, ha condotto una campagna di spionaggio pluriennale contro la ricerca accademica, medica e militare nordamericana e ora prende di mira specificamente la ricerca proprietaria sull'IA; GTIG sospetta che il gruppo comprometta ambienti cloud per distribuire modelli open-weight locali, il che evita il monitoraggio delle API commerciali e mette al lavoro la potenza di calcolo della vittima stessa.

Altrove lo schema è quello di modelli pronti all'uso che svolgono attività ordinarie su larga scala. Il gruppo nordcoreano MIDNIGHT NEPTUNE, in precedenza UNC1069, ha usato DeepSeek-Coder per scrivere trojan di accesso remoto in Python con persistenza cross-platform e process injection, ha usato gli LLM per script Bash di movimento laterale, ha gestito personaggi di social engineering ed esche tecniche, ha avvelenato configurazioni di repository interni, ha modificato gli hook di Claude CLI e ha distribuito la SOMBERMEME backdoor quando uno sviluppatore interagiva con il repository. Il gruppo iraniano CALANQUE ION, in precedenza APT42, ha usato i modelli per identificare gli indirizzi email dei target, condurre OSINT, localizzare le esche, riassumere i dati esfiltrati e tentare il reverse engineering del codice di licenza. Il gruppo PRC-nexus BASIN CASTLE ha usato Gemini per il profiling dei target, per tradurre materiale in cinese in reportistica politica in inglese formale e per la risoluzione di problemi con PowerShell; RAVINE CASTLE ha condotto ricerche su bypass SAML di VMware vCenter e su post-exploitation di Active Directory con esso; il gruppo russo SANDWORM RELIC si è fatto scrivere da Gemini il proprio codice di password spraying. Il gruppo con motivazioni finanziarie UNC6240, noto anche come ShinyHunters, ha usato i prompt di Claude Code per scrivere codice offuscato, aggirare Cloudflare e analizzare le directory esfiltrate tramite strumenti MCP personalizzati.

Un caso in questa sezione va oltre gli altri. Un gruppo con legami con la RPC ha utilizzato Gemini per progettare un framework dinamico di penetration testing automatizzato, pensato per osservare lo stato di un obiettivo, ragionare sulle azioni da intraprendere successivamente ed eseguire scansioni delle porte e analisi dei servizi. Google afferma di aver adottato misure più ampie contro le campagne identificate, disabilitando risorse, progetti e account associati. Separatamente, nel giugno 2026, Google ha interrotto «Outsider Enterprise», un servizio di cybercriminalità con sede in Cina che forniva kit di phishing, e ha descritto ciò come la prima volta in cui ha intrapreso un'azione legale per l'uso improprio di Gemini. Si tratta di due affermazioni distinte, e un riassunto che le unisse direbbe più di quanto affermi il rapporto: il framework di pentest rientra nella formulazione relativa alla disabilitazione delle risorse, mentre l'azione legale riguarda Outsider Enterprise.

LLMJacking, e quanto costa ora un account AI rubato

Il tracker stima anche i prezzi del mercato attorno agli accessi all'IA rubati. La domanda sotterranea si è concentrata sulle credenziali di Claude e Gemini, insieme agli IDE di coding autonomo Cursor Pro e Devin, quest'ultimo realizzato da Cognition, e i prezzi medi di mercato per account sono più che raddoppiati nel corso del 2026. Gli infostealer che eseguono la raccolta — LUMMAC.V2, STEALC.V2, VIDAR e ACRSTEALER — sono stati aggiornati per colpire la configurazione degli sviluppatori di IA. A maggio 2026, i gestori di ACRSTEALER hanno diffuso regole di acquisizione file per secrets.json di Cline e config.yaml di Continue AI, entrambi in grado di contenere chiavi API in chiaro e endpoint personalizzati per l'instradamento dei modelli.

Un'intrusione descritta da GTIG mostra quanto vale un account AI una volta compromesso. Nell'aprile 2026 un token di accesso personale GitHub esposto è bastato per abilitare Gemini Enterprise, effettuare il provisioning di risorse di calcolo ad alte prestazioni, creare repository Docker per una distribuzione dell'API LiteLLM e il framework di agenti Manus, e attivare servizi Cloud Run esposti a allUsers tramite un binding di invocazione IAM. La stessa sessione ha creato un account di servizio non autorizzato con privilegi Editor ed esportato le relative chiavi, interrogato BigQuery per variabili d'ambiente e credenziali, tentato di cedere la proprietà del progetto a un indirizzo esterno e usato l'API Cloud Quotas per richiedere capacità NVIDIA RTX 6000 e istanze aggiuntive da 48 vCPU.

Il quadro dell'estrazione di modelli riflette la stessa logica economica su scala più ampia. GTIG afferma che le campagne di distillazione ora avvengono regolarmente, «alcune superano i 100 milioni di prompt», con query ruotate tra migliaia di account compromessi e fraudolenti e instradate attraverso infrastrutture proxy, e che Google ha implementato contromisure in grado di degradare le prestazioni di un modello studente e metodi per identificare i modelli distillati da Gemini in base alla provenienza.

Che cosa è stabilito, che cosa è una valutazione e che cosa GTIG afferma di non aver visto

Accertato, nel senso che Google descrive la propria telemetria di prima parte e le proprie azioni sull'account: il report e la sua data; gli artefatti che afferma di aver osservato, inclusi i nomi dei pacchetti, i nomi dei file del loader, i nomi delle directory e la dashboard dei 23.800 segreti; e le misure di contrasto che Google afferma di aver adottato, che può attestare perché disattivare un account è qualcosa che fa, non qualcosa che deduce. Help Net Security, la Cloud Security Alliance e Lineaje riportano tutti quegli elementi senza contraddizioni, sebbene nessuno di essi porti prove indipendenti proprie.

Valutazione, nel senso che è un giudizio che Google sta esprimendo: ogni attribuzione a uno Stato-nazione nel rapporto; l'interpretazione dell'esca di rifiuto come deliberata; e l'affermazione che i token rubati supereranno i "controlli automatici di affidabilità degli agenti di codifica AI", che è un'affermazione su come tali controlli vengono comunemente costruiti anziché una misurazione del fallimento di uno specifico prodotto in uno di essi.

Non stabilito: l'identità dell'attore delle sei ore, le vittime e il loro numero, il chatbot e il modello coinvolti, e se il server Recon sia connesso o meno a quella campagna.

E il tetto del rapporto stesso è più basso di quanto suggerisca il suo titolo. GTIG afferma di non aver ancora osservato pipeline di sfruttamento completamente autonome in ambienti reali, e valuta che l'uso da parte degli avversari "potrebbe evolvere verso questo caso d'uso". La divisione è all'interno dell'attacco, non ai suoi margini: gli esseri umani forniscono l'obiettivo, il prompt e il file di istruzioni; l'agente fornisce la scansione, la risoluzione dei problemi e la rotazione, e non si ferma a chiedere il permesso. Letta con attenzione, la campagna di sei ore non è prova che l'autonomia sia arrivata. È prova che la quota umana del lavoro si è ridotta alla parte che richiede un umano — decidere cosa fare — mentre tutto ciò che sta tra la decisione e il risultato si è svolto da solo.

Cosa dice Google di aver cambiato, e il controllo a cui il rapporto punta realmente

La risposta dichiarata di Google si articola su due binari. Sul fronte degli abusi, afferma che le attività "hanno attivato le risposte di sicurezza di Gemini", che ha intrapreso "un'azione aggiuntiva e più ampia" contro le campagne sulla base delle carenze di sicurezza operativa degli attori, che ha disabilitato asset, progetti e account associati, e che Google DeepMind ha utilizzato i risultati per rafforzare i propri classificatori e il modello stesso affinché rifiuti queste richieste. Sul fronte della difesa, ha implementato Google AI Threat Defense, che combina Gemini e modelli frontier con la prioritizzazione del rischio di Wiz, la remediation di Gemini e CodeMender e l'intelligence di Mandiant, utilizzando modelli più leggeri per la scansione continua e modelli frontier per i rilevamenti ad alto rischio; ha inoltre introdotto Gemini 3.8 Flash Cyber per il rilevamento delle vulnerabilità e l'applicazione automatizzata delle patch, e ha pubblicato linee guida open source per il rafforzamento della supply chain.

La correzione specifica che il caso DUSTMAKER richiede è più circoscritta di quello stack, e le analisi esterne convergono su di essa. Un'attestazione SLSA risponde alla domanda se un pacchetto sia stato costruito dall'identità che dichiara. Non risponde alla domanda se quell'identità appartenga ancora alla parte di cui intendevi fidarti, e l'intero metodo di DUSTMAKER consiste nel prendere in prestito un'identità anziché falsificarla. Il riassunto di Lineaje del cambiamento di fondo è l'affermazione più limpida al riguardo: "Il contenuto del repository diventa autorità di esecuzione." I nomi dei pacchetti, i nomi dei server MCP, i badge di attestazione e i file di istruzioni all'interno di un repository arrivano ormai tutti con una qualche pretesa di essere obbediti, e il token OIDC rubato è ciò che fa sembrare verificata tale pretesa.