Oltre 100.000 dollari in un giorno e, in alcuni casi, addebiti accumulati fino a un milione: è il costo che Google e Mandiant attribuiscono agli attacchi che dirottano infrastrutture di intelligenza artificiale aziendale. La tecnica, nota come LLMjacking, sfrutta credenziali rubate o esposte per generare consumi nei servizi cloud che l’organizzazione colpita continua a pagare.
Il 2 novembre, Google Threat Intelligence Group (GTIG) ha pubblicato un’analisi di diverse intrusioni investigate da Mandiant nel corso del 2026. I casi riguardano vari provider cloud e di modelli linguistici e hanno colpito organizzazioni in Nord America, Sud America e Asia-Pacifico, nei settori finanziario, della vendita al dettaglio, tecnologico e dei trasporti. BleepingComputer, The Hacker News, CSO Online e CRN Asia hanno ripreso i risultati.
L’operazione non consiste necessariamente nel rubare dati né nel manipolare un chatbot visibile al pubblico. Gli aggressori cercano accesso diretto alle risorse di modelli e di calcolo della vittima, per poi usarle o trasformarle in un servizio per terzi. In pratica, le richieste appaiono come consumi legittimi associati agli account compromessi; la fattura, tuttavia, arriva all’azienda il cui accesso è stato dirottato.
Da una credenziale rubata a una fattura a sette cifre
GTIG ha osservato due tipi di accesso iniziale: la ricerca di endpoint di modelli esposti pubblicamente e il furto di chiavi API valide da macchine o ambienti non protetti. Nei casi esaminati, il metodo più comune è stato l’uso di token di identità cloud esposti o rubati. Tra questi figurano credenziali di Identity and Access Management (IAM), chiavi di account di servizio, token personali di GitHub e token di sessione attivi.
Sono state trovate anche chiavi API di modelli pubblicate in repository pubblici di GitHub. Un gruppo le ha verificate tramite richieste automatizzate che generavano un solo token, utilizzando il parametro max_tokens=1. Il test consentiva di confermare che una chiave fosse funzionante senza produrre il volume di traffico che normalmente potrebbe attirare l’attenzione dei sistemi di rilevamento. CSO Online ha osservato che queste microtransazioni possono restare al di sotto delle soglie di allerta basate sui consumi.
In un altro caso, un attore sconosciuto ha utilizzato un Personal Access Token rubato per accedere a repository di codice privati e ha poi sfruttato una vulnerabilità sospetta in un’applicazione inserita in un ambiente cloud con container. Google ha inoltre descritto l’uso di credenziali IAM aziendali per generare nuove chiavi di accesso e l’abuso di chiavi di account di servizio con autorizzazioni estese.
L’accesso iniziale può aprire la strada a una ricerca più ampia all’interno dell’infrastruttura. Gli aggressori hanno enumerato servizi cloud, repository e archivi di dati; esaminato i log di accesso; clonato codice per individuare segreti incorporati e credenziali degli sviluppatori; ed eseguito query sui database per ottenere password e altri dati di accesso. In un’intrusione, l’esplorazione ha interessato diverse regioni cloud.
Per mantenere il controllo, alcuni attori hanno creato account IAM o di servizio non autorizzati, modificato le autorizzazioni e inserito chiavi SSH nelle macchine virtuali. Google ha inoltre rilevato account backdoor camuffati da strumenti interni di ottimizzazione della fatturazione e l’uso di autorizzazioni per la creazione di token per ottenere credenziali temporanee di account con privilegi più elevati. In un caso, questo processo ha permesso di estrarre dai gestori di segreti credenziali infrastrutturali, password di database interni e chiavi API di terze parti.
UNC6993, una pagina falsa e una violazione di LiteLLM
Uno dei gruppi identificati da Google è UNC6993. A metà del 2026, secondo l’analisi di GTIG, ha compromesso un’istanza cloud tramite una chiave di account di servizio configurata in modo errato e ha usato l’accesso per entrare in un’API LLM. Il gruppo ha anche creato una pagina per il dirottamento delle sessioni che imitava il portale di un’applicazione.
La pagina indirizzava gli utenti al sito legittimo del servizio LLM e chiedeva loro di incollare un blocco JSON contenente un token di accesso attivo. Il token veniva poi inviato a un’API di backend per aggirare la password e l’autenticazione a più fattori (MFA). Google ha così descritto un metodo per rubare una sessione già autenticata senza limitarsi a intercettare una password.
Le intrusioni non si sono limitate alle credenziali. I ricercatori hanno osservato lo sfruttamento di CVE-2026-40217, una vulnerabilità in LiteLLM, un software che instrada le richieste tra applicazioni e modelli. L’analisi di Google colloca il difetto nell’endpoint /key/regenerate: un attore ha sfruttato una vulnerabilità di riassegnazione dell’identificatore utente per convertire chiavi virtuali standard in credenziali amministrative PROXY_ADMIN.
CRN Asia descrive il risultato come un’escalation da chiavi virtuali ordinarie a privilegi di amministratore. Google ha riferito che, in quell’indagine, un secondo gruppo ha ottenuto chiavi virtuali precedentemente convalidate dall’attore che aveva acquisito l’accesso iniziale e ha poi preso di mira la logica dell’applicazione. Questa divisione dei compiti dimostra che le intrusioni possono combinare la compromissione iniziale di un account con la successiva presa di controllo del gateway dei modelli.
Gli intermediari rivendono l’accesso ai modelli
Il business che ne deriva ruota attorno ai cosiddetti LLM Mixers: gateway di instradamento che aggregano credenziali compromesse, distribuiscono le richieste tra gli account e rivendono l’accesso ad abbonati clandestini. Gli operatori possono interporre la propria infrastruttura per nascondere l’origine delle richieste e trasformare le quote aziendali rubate in un servizio a pagamento.
Google ha identificato Jet Night come uno di questi servizi. In un caso, un attore ha effettuato più di 500.000 chiamate alle API LLM in meno di otto ore, usando chiavi API di terze parti rubate per alimentare l’instradamento delle richieste di Jet Night. I consumi hanno trasferito quasi un milione di dollari di costi per i token all’organizzazione vittima.
Jet Night offriva un piano con token illimitati a circa 60 dollari al mese, pubblicizzando l’accesso a modelli avanzati. Google ha confrontato questo prezzo con un costo abituale compreso tra 100 e 250 dollari al mese per servizi consumer simili. Il prezzo basso permette di attirare abbonati, mentre la spesa effettiva viene addebitata agli account delle aziende compromesse.
GTIG ha inoltre osservato che Jet Night ha annunciato diverse interruzioni sul proprio canale pubblico di Telegram. Google ritiene probabile che alcune fossero legate alla revoca delle chiavi rubate dopo che le vittime avevano scoperto l’accesso non autorizzato. L’infrastruttura dipende dal fatto che le credenziali restino attive: quando un’azienda le invalida, il servizio perde parte della capacità che rivendeva.
UNC6993, da parte sua, avrebbe utilizzato strumenti open source come new-api e gcli2api per raccogliere chiavi e distribuire le richieste tra gli account. GTIG ritiene che il gruppo venda l’accesso a questi strumenti tramite negozi clandestini. In un altro caso, un’infrastruttura di inoltro personalizzata, ospitata su domini che imitavano i sistemi interni di una vittima, ha dirottato le quote commerciali dei modelli verso l’ecosistema di rivendita newapi[.]pro.
L’uso fraudolento può andare oltre le chiamate ai modelli. I ricercatori hanno visto attori attivare servizi di IA che non erano abilitati prima dell’intrusione, generare chiavi aggiuntive e sottoscrivere modalità a consumo con modelli premium. Per aggirare i limiti alle richieste, alcuni hanno adottato una strategia di «brucia e ruota»: creare ed eliminare ripetutamente account di servizio di breve durata, monitorando nel frattempo l’interfaccia di fatturazione.
In un caso, un attore ha abilitato agenti, distribuito proxy inversi accessibili pubblicamente e utilizzato pacchetti proxy personalizzati di Node.js per offrire endpoint compatibili con diversi modelli avanzati con l’identità D1337-KAIROS. Google ha inoltre documentato una backdoor basata sul framework di agenti Manus, che interrogava un modello per interpretare istruzioni ed eseguire comandi nell’ambiente compromesso. L’attore è arrivato a predisporre istanze cloud con GPU, ha tentato di distribuire hardware di fascia alta in diverse regioni e ha richiesto aumenti delle quote tramite l’API del provider.
Cosa consiglia Google e cosa si aspetta dagli aggressori
Google consiglia di partire da IAM e dalla sicurezza della supply chain. Le misure indicate includono la centralizzazione della gestione e della rotazione dei segreti, l’eliminazione dei privilegi non necessari per ciascun ruolo e il rifiuto predefinito delle autorizzazioni non richieste esplicitamente, compreso l’accesso ai servizi cloud LLM.
L’azienda consiglia inoltre di applicare MFA resistente al phishing, monitorare l’attivazione non autorizzata dei servizi di IA e impostare limiti di utilizzo e di spesa per le API. I log di audit cloud e di inferenza devono essere abilitati e controllati per rilevare attivazioni impreviste, verifiche sospette delle credenziali, modelli di consumo insoliti e tentativi di disabilitare la registrazione.
Il monitoraggio è importante anche prima che arrivi una fattura sorprendente. I test delle chiavi con richieste di un solo token possono passare inosservati se si osservano soltanto i grandi volumi. Google propone di rendere visibili i servizi di IA e i modelli non autorizzati — la cosiddetta shadow AI — e di considerare un incidente grave qualsiasi attivazione di servizi non autorizzata dall’organizzazione.
Le conclusioni di Google indicano un’espansione del modello di rivendita. GTIG si aspetta che gli aggressori diano la priorità al LLMjacking rispetto alle forme tradizionali di furto di risorse, come il cryptojacking, grazie alla possibilità di monetizzare rapidamente l’accesso tramite gli LLM Mixers. Prevede inoltre che migliorino la scansione automatizzata dei token esposti e cerchino vulnerabilità nei middleware di instradamento, man mano che le aziende adotteranno modelli più potenti e flussi di lavoro basati su agenti.
«Le organizzazioni dovranno monitorare attentamente e proteggere i modelli e le risorse di calcolo che stanno implementando rapidamente, altrimenti potrebbero non essere le uniche a utilizzarli. Questo significa esaminare l’utilizzo, abilitare l’autenticazione a più fattori e gestire con cura i segreti».
— John Hultquist, analista capo di Google Threat Intelligence Group
Negli incidenti analizzati, alcune organizzazioni hanno accumulato addebiti fino a un milione di dollari prima di revocare l’accesso compromesso. Google consiglia di monitorare le credenziali, l’attivazione dei servizi, le modifiche alle autorizzazioni e i consumi delle API, così da rilevare gli abusi prima che i costi continuino a crescere.
Fonti: BleepingComputer, The Hacker News, Google Cloud Blog, CSO Online, CRN Asia
