LLM-jacking: account IA e quote cloud nel mercato nero

Il 2 ottobre 2026 il Cyber Brief di CERT-EU ha segnalato la crescita del LLM-jacking: criminali rubano e rivendono accessi a strumenti IA premium e sfruttano ambienti cloud compromessi per eseguire carichi non autorizzati. Il rischio per chi paga servizi e modelli riguarda sia la perdita di un account sia richieste e capacità di calcolo consumate a proprie spese.

Il rapporto di Google richiamato nel brief rileva più compratori e venditori di account IA nei forum osservati, con prezzi medi per account più che raddoppiati nel corso del 2026. La domanda si concentra sulle credenziali Claude e Gemini e cresce per gli assistenti di programmazione Cursor Pro e Devin. Chi ottiene una chiave API o un accesso cloud valido può inoltre usare le quote pagate dalla vittima, anche senza entrare nel suo account tramite il browser.

Che cosa viene venduto nei mercati clandestini

Il bene scambiato è l’accesso utilizzabile: credenziali di account premium, token di sessione, chiavi API oppure un servizio che inoltra le richieste a modelli pagati da altri. La quota resta associata al suo titolare, ma un accesso sottratto permette a un estraneo di consumarla. Per questo il prezzo basso offerto agli acquirenti può tradursi in spesa per l’organizzazione che possiede l’account o la chiave.

Un’indagine di Okta Threat Intelligence documenta la rivendita di segreti di autenticazione IA, compresi token di sessione pubblicizzati come ancora validi. Descrive anche offerte di accesso ai modelli a prezzo ridotto alimentate con crediti promozionali ottenuti mediante iscrizioni fraudolente. Sono modalità diverse: l’uso di bonus raccolti con falsi account non implica che ogni quota rivenduta provenga da un account aziendale violato.

Le credenziali nascoste negli assistenti di sviluppo

Le informazioni utili a un aggressore non sono limitate alle password conservate nel browser. Fra i file cercati dagli infostealer figurano secrets.json di Cline e config.yaml di Continue AI: possono contenere chiavi API in chiaro ed endpoint personalizzati per instradare le richieste ai modelli. Una chiave valida può quindi collegare direttamente il computer dello sviluppatore alla quota pagata dall’azienda, anche se l’account web del dipendente non viene aperto.

I controlli partono da quelle configurazioni e dalle directory degli IDE, dove gli strumenti conservano impostazioni e segreti. Conviene associare ogni chiave a un proprietario, al progetto che la paga e ai servizi che la utilizzano; altrimenti un picco di consumo compare nella fattura senza indicare quale credenziale lo abbia generato. Se un dispositivo risulta compromesso, cambiare solo la password dell’account lascia potenzialmente utilizzabili chiavi e token copiati dai file locali. Spostare i segreti persistenti in un gestore dedicato riduce l’esposizione dei file, purché restino limitati anche i permessi per richiamarli.

Dal token GitHub alla quota cloud

Un caso di intrusione mostra il percorso infrastrutturale del LLM-jacking. Un GitHub Personal Access Token esposto ha dato accesso iniziale all’ambiente cloud di una vittima. L’attore ha abilitato Gemini Enterprise, predisposto risorse di calcolo e creato un account di servizio con privilegi Editor, esportandone le chiavi. La credenziale iniziale è così diventata il punto di partenza per nuove identità e servizi, oltre che per richieste ai modelli.

Nello stesso ambiente l’attore ha usato la Cloud Quotas API per chiedere un aumento della quota relativa a hardware NVIDIA RTX 6000 e ha avviato ulteriori istanze di calcolo per carichi IA non autorizzati. La richiesta di quota indica il tentativo di ampliare la capacità disponibile; il rapporto descrive la richiesta, senza stabilire che l’aumento sia stato concesso. Per chi gestisce il progetto, i segnali utili sono dunque la comparsa di identità privilegiate, l’abilitazione inattesa di API e l’avvio di risorse non previste, oltre all’importo fatturato.

I controlli che riducono consumo e rivendita

La verifica più efficace segue l’accesso dalla sua origine fino al costo generato. Occorre distinguere le credenziali degli utenti da quelle delle applicazioni e delle identità di servizio: hanno diritti e procedure di revoca differenti. Una mappa essenziale per una PMI collega chiave, proprietario, progetto cloud, modello raggiungibile e centro di spesa; permette di individuare cosa disattivare quando il consumo diverge dall’attività prevista.

Chiavi API e file locali: cercare le credenziali nelle configurazioni degli assistenti e nelle directory degli IDE, verificare i permessi e ruotare le chiavi esposte. Aggiornare poi le applicazioni che le usano, perché la revoca interrompe anche le richieste legittime.
Sessioni e account: controllare gli accessi recenti, revocare le sessioni sospette e riesaminare separatamente i token API. Un token di sessione ancora valido può consentire l’accesso senza una nuova immissione della password.
Quote e risorse: osservare richieste di aumento quota, nuove identità con ampi privilegi, attivazione di servizi IA e istanze di calcolo inattese. Limiti e permessi proporzionati alle attività riducono la capacità che una singola credenziale compromessa può mettere a disposizione dell’aggressore.
Spesa: impostare avvisi sulle anomalie e confrontarli con volumi delle chiamate API, risorse avviate e log di accesso. L’avviso segnala il consumo; per fermarlo serve intervenire sulla credenziale e sulle risorse che lo stanno producendo.

Un aumento inatteso della fattura richiede quindi una ricerca sugli accessi ancora attivi, non soltanto una verifica contabile. Se la stessa chiave compare in un assistente locale e in un progetto che mostra nuove richieste ai modelli, revoca e rotazione vanno accompagnate dal controllo delle sessioni e delle identità di servizio: sono i punti attraverso cui l’uso abusivo può continuare.