C’è una certa poesia amara nel ricevere una fattura cloud a sei cifre per un servizio che non sapevi nemmeno di avere. È il genere di sorpresa che trasforma un lunedì mattina in una riunione d’emergenza, e che negli ultimi mesi è capitata a diverse aziende reali: North America, South America, Asia Pacific, settori che vanno dai servizi finanziari al retail, dalla tecnologia ai trasporti.
Il 2 novembre 2026 Google Threat Intelligence Group e Mandiant hanno pubblicato il report “The Rise of LLMJacking“, e il dato che fa alzare un sopracciglio è questo: in singoli incidenti sono stati osservati addebiti fraudolenti superiori a 100.000 dollari in un solo giorno, con addebiti cumulativi che in alcune organizzazioni hanno raggiunto il milione di dollari prima che l’accesso venisse revocato.
Fin qui potrebbe sembrare l’ennesima variazione sul tema “qualcuno ti ruba le credenziali e le usa”. Lo è, ma con una torsione che ribalta l’assunto confortante su cui molti dormono sonni tranquilli: “io l’AI non la uso, quindi non sono esposto”.
Ecco, no. Il bello – si fa per dire – è che in diversi incidenti investigati da Mandiant i servizi LLM non erano abilitati al momento della compromissione. L’abuso delle chiavi di accesso ha permesso all’attaccante di modificare e abilitare i servizi API LLM (per esempio Bedrock, Gemini API, eccetera).
Tradotto: l’attaccante entra con una chiave che hai lasciato in giro, accende lui il servizio al posto tuo, e una volta abilitato può usare le API per generare bollette enormi in pochi minuti o ore. Non devi aver mai scritto un prompt in vita tua. Basta che qualcuno, con le tue credenziali, lo faccia per te e lo faccia industrialmente.
Indice degli argomenti
LLMJacking: il cryptojacking invecchiato male
Per capire perché questa cosa spaventa più del furto di credenziali classico, conviene confrontarla con il suo cugino più noto, il cryptojacking. Chi minava criptovalute abusive sul tuo cloud lo faceva con una certa discrezione forzata: il mining consuma risorse lentamente, la bolletta sale con la pazienza di un tassametro nel traffico. L’LLMJacking no. A differenza del consumo graduale di risorse associato al cryptojacking, l’LLMJacking può generare enormi picchi di addebiti fraudolenti nel giro di ore. È la differenza tra un rubinetto che gocciola e uno scoppio di tubatura.
Il caso che meglio illustra la velocità arriva da un threat actor che ha eseguito oltre 500.000 chiamate API LLM in meno di otto ore, usando chiavi API di terze parti rubate per alimentare un servizio di token routing chiamato jet-night.com. Jet Night ha scaricato quasi un milione di dollari di costi in token sull’organizzazione vittima. Qui va fatta una precisazione che il comunicato stampa medio tende a impastare: il caso UNC6993 – il gruppo spesso citato per i tool new-api e gcli2api – e il caso Jet Night da mezzo milione di chiamate sono due attori distinti. UNC6993 ha accumulato rapidamente oltre 100.000 dollari di addebiti e ha usato strumenti open source come new-api (un hub e gateway centralizzato per modelli) e gcli2api (un tool proxy che converte strumenti CLI in endpoint standard per modelli di frontiera), probabilmente per aggregare chiavi rubate e bilanciare il carico delle richieste su più account.
Il milione da 500k chiamate è un altro cluster. Mescolarli fa un titolo più grasso, ma è impreciso.
La divisione del lavoro criminale (e il termine da ricordare: LLM Mixer)
La parte che un occhio tecnico apprezza di più non sono le cifre — quelle fanno rumore e basta — ma la struttura industriale che il report fotografa. Siamo passati dal singolo smanettone che ruba una chiave a una filiera con reparti separati.
Google traccia una divisione del lavoro tra i threat actor che stabiliscono l’accesso iniziale agli ambienti compromessi e gli operatori che gestiscono l’infrastruttura di monetizzazione a valle, noti come “LLM Mixer”.
Il Mixer è il pezzo nuovo di vocabolario da appuntarsi: funziona come un gateway di routing illecito che fa da proxy, aggrega e rivende accesso LLM non autorizzato ad abbonati underground. In un’indagine, GTIG ha osservato due cluster operativi distinti che si coordinavano per compromettere e monetizzare infrastruttura LLM aziendale.
C’è chi scassina e chi rivende, come in qualsiasi economia matura.
E i prezzi raccontano la storia meglio di qualsiasi analisi di mercato. Jet Night offre un piano a token illimitati per circa 60 dollari al mese con presunto accesso a modelli di frontiera, un livello di servizio che normalmente costerebbe tra 100 e 250 dollari al mese.
Quando qualcuno vende a 60 ciò che costa 250, non è efficienza operativa: dato che i costi per token di Jet Night sono così al di sotto dei normali prezzi di mercato, GTIG ritiene che il servizio si regga su chiavi rubate per operare in modo profittevole.
Il margine lo paga la vittima, sulla sua carta di credito aziendale.
Dettaglio quasi comico: il servizio ha pubblicizzato diverse interruzioni sul suo canale Telegram pubblico, probabilmente dovute alla revoca delle chiavi rubate man mano che le vittime scoprono di essere compromesse. Un SaaS illegale con tanto di pagina di stato dei disservizi.
Come entrano: niente di esotico, purtroppo
Se speravi in una tecnica da film, preparati alla delusione. Il vettore d’accesso dominante è la banalità elevata a sistema. Nelle varie indagini, il vettore d’accesso iniziale predominante sono state identità cloud esposte o rubate – incluse credenziali IAM, chiavi di Service Account, GitHub Personal Access Token (PAT) e token di sessione attivi. La solita roba che finisce committata in un repo, lasciata in una variabile d’ambiente, dimenticata in un log.
Un paio di dettagli operativi meritano attenzione perché sono quelli che fanno la differenza in fase di detection. Primo: la validazione furtiva. Un gruppo che aveva raccolto chiavi API LLM da repository GitHub pubblici ha condotto sweep di validazione automatizzati usando richieste minime a singolo token (max_tokens=1).
Questo ha permesso di confermare la validità delle chiavi rubate restando invisibile agli alert di anomalia di volume di EDR e SIEM. Una chiamata da un token non fa scattare nessuna soglia. Sembra un health check. È ricognizione. Se monitori solo i picchi, questa fase ti passa sotto il naso e te ne accorgi solo quando arriva la fattura.
Secondo: l’evasione MFA via federazione. Più di un attore ha sfruttato credenziali IAM compromesse usando token di federazione cloud per generare programmaticamente nuove chiavi di accesso e aggirare i requisiti MFA.
L’autenticazione a più fattori, quella che nelle slide della security awareness viene presentata come la panacea, qui viene semplicemente scavalcata lavorando a un livello dove l’MFA non arriva.
C’è anche chi ha giocato di persistenza fine: un attore ha creato account di servizio backdoor mascherati da utility interne di ottimizzazione dei costi e ha iniettato chiavi SSH a livello di ambiente nei metadata delle istanze di calcolo. Chiamare “billing optimizer” il tuo backdoor mentre prosciughi il budget cloud della vittima ha un suo nero senso dell’umorismo.
Il gateway come punto di controllo e la nota critica sulla CVE
Veniamo al pezzo decisivo: non è l’uso dell’AI il rischio, è il gateway che la governa. E qui entra in scena LiteLLM, uno dei proxy open source più diffusi per instradare traffico verso modelli diversi.
In un caso, dopo aver acquisito Virtual Key pre-validate dal threat actor che aveva stabilito l’accesso iniziale, un cluster successivo ha eseguito un exploit mirato di application logic contro il gateway LiteLLM della vittima.
L’attore ha sfruttato una vulnerabilità di user ID rebind nell’endpoint /key/regenerate (CVE-2026-40217) per elevare Virtual Key standard a credenziali amministrative master PROXY_ADMIN, stabilendo un controllo profondo e persistente. Una chiave qualsiasi diventa la chiave di tutto.
Ora, qui faccio il lavoro che un articolo serio deve fare e che il comunicato non fa: il riferimento a CVE-2026-40217 va preso con le pinze. Se vai a controllare l’identificativo sulle fonti autoritative – NVD, Red Hat, cve.org, l’advisory X41 – CVE-2026-40217 è descritta come l’esecuzione di codice arbitrario via bytecode rewriting sull’URI /guardrails/test_custom_code, un code injection (CWE-94) con punteggio CVSS 8.8, che impatta tutte le versioni di LiteLLM rilasciate fino all’8 aprile 2026 e risolta aggiornando alla versione v1.83.10-stable o successiva.
È tutt’altro endpoint e tutt’altra classe di bug rispetto allo /key/regenerate descritto da Mandiant. Non a caso, una delle analisi indipendenti segnala esplicitamente una discrepanza tra il report di Google e la risposta dell’advisory ufficiale di LiteLLM, e avverte che la corretta mappatura della CVE, le versioni affette e quelle corrette per questo specifico vettore restano non confermate.
Perché te lo dico? Perché se gestisci un gateway LiteLLM e corri a patchare basandoti solo sul numero di CVE citato nel report, rischi di applicare la correzione per l’endpoint sbagliato e lasciarti aperto il vettore giusto.
La spiegazione più plausibile è che l’escalation /key/regenerate faccia parte della catena divulgata da Obsidian Security a giugno 2026, che concatenava CVE-2026-47101, CVE-2026-47102 e CVE-2026-40217 in un percorso da utente a basso privilegio fino ad admin e RCE, con fix completo incluso in LiteLLM v1.83.14-stable e successive.
Morale operativa: se hai LiteLLM in produzione, non fermarti al numero. Aggiorna almeno alla 1.83.14-stable, verifica la catena completa, e non trattare il proxy come un pezzo d’infrastruttura di serie B esente da patch management. Mandiant stessa raccomanda di estendere i programmi di vulnerability management per includere i gateway centralizzati di proxy e routing dei modelli.
Cosa fare, al netto della retorica
La difesa qui non è un prodotto nuovo da comprare, è igiene che molti rimandano da anni. Le raccomandazioni di Mandiant ruotano attorno a due cose che la maggior parte dei team di sicurezza non guarda da vicino: la spesa cloud e le credenziali macchina.
Nel concreto significa least privilege serio (negare esplicitamente l’accesso ai servizi LLM a chi non deve averlo), scope granulari sulle API key – in modo che un token compromesso per un modello di utilità base non possa invocare i costosi modelli di frontiera – spending cap e budget alert che blocchino l’emorragia prima che diventi un milione, e soprattutto trattare qualsiasi abilitazione non autorizzata di servizi LLM come un evento di sicurezza critico.
Quel log di “servizio Bedrock abilitato” che nessuno guarda è esattamente il campanello che suona prima della fattura. E per intercettare la fase silenziosa, monitorare i log del gateway per richieste anomale a basso volume come max_tokens=1: la ricognizione si nasconde nel rumore, non nel picco. La verità scomoda è che l’AI non ha introdotto una nuova superficie d’attacco magica. Ha solo attaccato un prezzo altissimo e istantaneo a una negligenza vecchissima: le chiavi lasciate in giro.
Il cryptojacking ti costava lentamente e te ne accorgevi; l’LLMJacking ti svuota il conto nel tempo di una pausa caffè.
La domanda da portarsi a casa non è “la mia azienda usa l’AI?”, perché quella risposta non ti protegge. È un’altra: chi, in questo momento, potrebbe accendere Bedrock al posto tuo – e quanto ci metteresti ad accorgertene?
Partecipa alla community