I log degli infostealer rivelano migliaia di token IA riutilizzabili che possono aggirare l'MFA

Un archivio da 7 GB espone dati di autenticazione di 5.871 sistemi

Gli infostealer stanno fornendo ai criminali informatici qualcosa di più utile delle password: token di sessione attivi e chiavi API per i servizi di intelligenza artificiale.

Le ultime scoperte sono emerse il 9 settembre 2026 e riguardano un archivio di log di infostealer da 7 GB pubblicato su Telegram il 2 agosto 2026. Il set di dati conteneva informazioni raccolte da 5.871 macchine infette in 162 Paesi.

L'analisi di Okta dell'archivio di log degli infostealer ha identificato 44.791 JSON Web Token (JWT) univoci. Gli investigatori hanno ritenuto che 555 fossero probabilmente collegati all'autenticazione per i servizi di intelligenza artificiale.

L'archivio conteneva anche 2.937 strutture di crittografia Web JSON (JWE). La maggior parte era associata a OpenAI, che utilizza il framework di autenticazione NextAuth.js. Sebbene queste strutture contengano JWT crittografati, la crittografia non impedisce necessariamente a un utente malintenzionato di riprodurli.

Il giorno in cui è apparso l'archivio, 1.843 JWT e JWE non erano ancora scaduti. Questo ha offerto a chiunque avesse accesso al dump una potenziale finestra per il dirottamento degli account.

La scansione con TruffleHog ha individuato un'altra categoria di credenziali esposte: 24 chiavi API ancora valide per Google Gemini, OpenAI, Groq e OpenRouter. Altri token nel set di dati corrispondevano a Google, Microsoft, Anthropic, Amazon, Gamma, Notion, Character.ai, Cursor, Poe.com e Pika AI.

Non si tratta di una vulnerabilità che interessa una specifica versione software. Non sono coinvolte versioni vulnerabili di prodotti o patch di sicurezza. L'esposizione deriva dal fatto che il materiale di autenticazione viene estratto dagli endpoint compromessi e riutilizzato altrove.

Perché un token rubato può rendere irrilevante l'MFA

Un token di sessione valido rappresenta un evento di autenticazione già avvenuto. Quando un servizio accetta quel token, può trattare chi lo presenta come un utente autenticato senza chiedere nuovamente una password o l'autenticazione a più fattori.

Questo cambia l'obiettivo dell'aggressore. Invece di superare l'MFA durante l'accesso, ruba l'artefatto creato dopo che l'MFA è già riuscita.

I JWT in genere contengono attestazioni (claim) utilizzate dalle applicazioni per identificare utenti, sessioni, autorizzazioni, emittenti, destinatari e tempi di scadenza. Nell'archivio analizzato, il 17,7% dei 44.791 JWT conteneva anche informazioni personali identificative in chiaro, tra cui nomi, numeri di telefono o indirizzi e-mail.

Questo crea due rischi distinti. Un token può consentire l'accesso all'account finché rimane valido, e il suo contenuto leggibile può esporre dati identificativi anche dopo la scadenza del token.

I JWE nascondono le loro attestazioni interne tramite crittografia, ma ciò non li rende innocui. Un aggressore potrebbe non aver bisogno di decifrare un JWE rubato se il servizio che lo riceve è in grado di farlo. Se il token rimane valido ed è accettato come credenziale bearer, la riproduzione dell'oggetto crittografato può comunque ripristinare la sessione della vittima.

Le chiavi API presentano un problema analogo. Spesso autorizzano un accesso programmatico diretto anziché un accesso interattivo dal browser. Un aggressore in possesso di una chiave valida può potenzialmente consumare risorse del modello, richiamare API o eseguire carichi di lavoro automatizzati sotto l'account e i limiti di fatturazione della vittima.

Le passkey non risolvono questa fase dell'attacco. L'autenticazione resistente al phishing può prevenire molte compromissioni basate su password e phishing delle credenziali, ma non invalida automaticamente i dati di sessione o i segreti API copiati da un dispositivo infetto.

I browser anti-rilevamento rendono più facile riutilizzare le sessioni rubate

Riprodurre un token di sessione non è sempre semplice come incollare una stringa in un browser. Le applicazioni possono dipendere da diversi cookie, valori di archiviazione del browser e caratteristiche ambientali che devono essere ricostruiti insieme.

Gli aggressori utilizzano strumenti come il browser anti-rilevamento open source Camoufox e il framework di automazione del browser SeleniumBase per importare da file i dati rubati di sessionStorage e localStorage. Ciò può ricreare una quantità sufficiente dello stato del browser della vittima affinché un servizio riconosca la sessione esistente.

L'infrastruttura proxy aiuta a ridurre le discrepanze visibili. Se un token rubato appare improvvisamente da un Paese lontano o da una rete sconosciuta, le regole di viaggio impossibile e altri controlli del rischio possono attivarsi. Instradare la riproduzione attraverso un indirizzo più vicino alla posizione prevista della vittima può rendere l'attività meno evidente.

Il rilevamento comportamentale rimane possibile. Nuovi dispositivi, modelli di utilizzo insoliti, consumo anomalo del modello e uso simultaneo dei token possono fornire segnali. Tuttavia, l'aggressore inizia la sessione con un artefatto valido anziché con una password evidentemente errata.

Jeremy Kirk, direttore della threat intelligence di Okta, ha descritto i token di sessione e le chiavi API come molto ricercati perché possono aggirare l'autenticazione basata su credenziali. Una volta che la riproduzione riesce, l'aggressore è di fatto all'interno dell'account LLM senza completare un accesso convenzionale.

Le famiglie di malware indicate in relazione a questa attività includono Lumma Stealer e Vidar. Le informazioni disponibili non identificano quale famiglia abbia infettato ciascuna delle 5.871 macchine, né rivelano singole vittime o forniscono indicatori pubblici per gli endpoint interessati.

L'accesso rubato all'IA è diventato un prodotto commerciale

I log degli stealer vengono venduti tramite forum underground e piattaforme di messaggistica, ma il mercato sta diventando più specializzato. Alcuni servizi criminali ora confezionano token rubati con profili browser o configurazioni anti-rilevamento destinate a semplificare l'accesso agli account.

Okta ha identificato un venditore su Telegram che pubblicizzava accessi scontati a Claude, Cursor, ChatGPT e Gemini. Il venditore promuoveva supporto continuo e garanzie di rimborso, un linguaggio pensato per far assomigliare l'accesso illecito a un'attività di abbonamento convenzionale.

Un'altra operazione che si fa chiamare «Poison Claude» afferma di vendere l'accesso a modelli Anthropic identificati come Opus 4.8, Opus 4.7, Opus 4.6 e Sonnet 4.6. Si tratta di affermazioni del venditore e non è stata divulgata alcuna convalida indipendente dell'accesso pubblicizzato.

Il Google Threat Intelligence Group ha osservato un numero crescente di acquirenti e venditori che commerciano account legati all'IA nelle comunità del cybercrimine. La domanda include credenziali Claude e Gemini, insieme ad ambienti di programmazione autonoma come Cursor Pro e Devin.

L'uso potenziale va oltre l'accesso economico ai chatbot. Gli account rubati possono esporre conversazioni private, documenti caricati, codice generato, prompt proprietari e altre informazioni conservate all'interno delle piattaforme di IA.

L'abuso delle API consente anche il furto di risorse, talvolta descritto come LLMjacking. Il modello ricorda il mining illecito di criptovalute: gli aggressori eseguono attività ad alta intensità di calcolo scaricando sulla vittima i costi dell'infrastruttura o dell'utilizzo.

Mandiant ha riscontrato una versione più ampia di questo problema durante un intervento di risposta agli incidenti. Un autore di minacce è entrato nell'ambiente cloud di una vittima utilizzando un GitHub Personal Access Token esposto, quindi ha distribuito infrastruttura IA non autorizzata e ha scalato risorse di calcolo ad alte prestazioni.

Le conseguenze vanno dalla frode sulla fatturazione allo spionaggio aziendale

Per i singoli individui, il dirottamento dell'account può esporre conversazioni personali e informazioni identificative. Le PII in chiaro trovate all'interno di alcuni JWT possono anche favorire campagne di phishing mirato, furto d'identità e ingegneria sociale.

Le conseguenze per le aziende sono più ampie. Un aggressore potrebbe accedere a prompt sensibili, documenti interni, codice sorgente, materiale dei clienti o ricerche inviate a un servizio di IA. Gli account compromessi potrebbero anche essere rivenduti o utilizzati come punto d'appoggio per estorsioni e spionaggio.

L'impatto finanziario può accumularsi rapidamente quando le chiavi API rubate consentono richieste automatizzate. Anche quando l'aggressore non può raggiungere i dati archiviati, consumare il budget di token o l'allocazione di calcolo cloud della vittima crea un costo diretto.

La presenza di dati di autenticazione provenienti da 162 Paesi dimostra che il fenomeno non è limitato a una singola regione o servizio. Tuttavia, non è noto il numero di token riprodotti con successo. È inoltre sconosciuto quante delle identità esposte fossero abbonamenti personali, account sviluppatore o identità gestite a livello aziendale.

Le difese devono proteggere sia le sessioni sia gli accessi

Le organizzazioni dovrebbero monitorare la comparsa dello stesso token di sessione da indirizzi IP, dispositivi o posizioni inattesi. L'uso simultaneo da ambienti diversi, cambiamenti improvvisi nelle caratteristiche del browser e consumi anomali di IA possono anche indicare una riproduzione.

L'inserimento in una whitelist IP può limitare l'accesso alle reti approvate, in particolare per le funzioni amministrative o API. Non è una difesa completa perché gli aggressori possono utilizzare proxy o compromettere infrastrutture all'interno di un intervallo consentito.

Le chiavi API dovrebbero avere autorizzazioni definite in modo restrittivo, quote di utilizzo e monitoraggio continuo dei consumi. Le chiavi sospette dovrebbero essere revocate e sostituite, mentre le sessioni browser interessate dovrebbero essere terminate per invalidare lo stato rubato.

Le implementazioni di OAuth 2.0 dovrebbero privilegiare token di accesso di breve durata, riducendo il periodo in cui un token copiato rimane utile. Le credenziali di lunga durata creano una finestra di riproduzione più ampia dopo la compromissione dell'endpoint.

Le Device Bound Session Credentials di Chrome offrono una contromisura più diretta. Il DBSC collega crittograficamente le credenziali di sessione a un dispositivo, impedendo che un token esportato venga accettato su un sistema diverso.

La sicurezza degli endpoint rimane centrale perché il furto inizia sulla macchina dell'utente. Le passkey possono rafforzare l'accesso, ma le aziende che adottano servizi di IA devono anche inventariare i segreti API, controllare le sessioni del browser e considerare le infezioni da infostealer come una potenziale compromissione di ogni account cloud e di IA attivo sul dispositivo.