Gli attacchi di LLM-jacking di Google trasformano l'accesso all'AI in una risorsa rubata

Google afferma che i criminali stanno rubando account AI e credenziali cloud, mentre il costo dei modelli premium crea un mercato nero dell'accesso in rapida crescita.

L'avvertimento di settembre 2026 sposta il focus della sicurezza AI. Per anni, le aziende hanno discusso se gli aggressori possano manipolare o compromettere i modelli stessi. Google descrive ora un problema più immediato: gli aggressori rubano gli account, le chiavi API, i file di configurazione e le risorse cloud che circondano quei modelli.

I conseguenti attacchi di LLM-jacking di Google contrappongono un accesso all'AI in rapida espansione a controlli dell'identità progettati per normali servizi software. LLM-jacking significa usare credenziali compromesse per consumare l'accesso a modelli a pagamento o la capacità di calcolo di qualcun altro. La tecnica è emersa pubblicamente per la prima volta nel 2024, ma le prove di Google suggeriscono che sia entrata in un'economia criminale più ampia.

Gli attacchi di LLM-jacking di Google si espandono oltre le chiavi API rubate

La conclusione centrale di Google è che l'accesso all'AI è diventato abbastanza prezioso da essere rubato, scambiato, condiviso e rivenduto.

La valutazione delle minacce di settembre proviene dal Google Threat Intelligence Group, o GTIG. Le sue prove attingono al lavoro di risposta agli incidenti di Mandiant, al tracciamento degli attori delle minacce, ai forum clandestini e alle attività osservate nei servizi di Google.

GTIG ha rilevato un maggior numero di acquirenti in cerca di account legati all'AI durante il 2026. I ricercatori hanno inoltre osservato più venditori che li pubblicizzavano. Secondo quanto riferito, la domanda si è concentrata sulle credenziali per Claude e Gemini, mentre hanno attirato interesse anche gli account per ambienti di programmazione autonomi.

Google non ha pubblicato il numero totale degli account rubati. Ha però riferito che i prezzi medi clandestini per account sono più che raddoppiati nel corso del 2026. Questo dettaglio conta perché indica una risposta del mercato, non un semplice insieme di furti isolati di credenziali.

Gli aggressori vogliono accesso AI premium per diverse ragioni. Gli account a pagamento offrono limiti di utilizzo più elevati, modelli più potenti e meno interruzioni rispetto agli account gratuiti usa e getta. Le credenziali API possono inoltre supportare carichi di lavoro automatizzati difficili da sostenere attraverso un'interfaccia di chat per consumatori.

Le credenziali cloud hanno un valore ancora maggiore. Un'identità compromessa può esporre modelli ospitati, autorizzazioni di deployment, archiviazione e costose risorse di calcolo. Gli aggressori possono quindi eseguire carichi di lavoro di inferenza mentre la vittima assorbe le conseguenze operative e di utilizzo.

Google collega questo comportamento al LLM-jacking, in cui i criminali assumono il controllo di servizi a modelli a pagamento o infrastrutture cloud senza autorizzazione. L'obiettivo immediato può essere l'accesso gratuito, ma la stessa infrastruttura può supportare phishing, ricerca di vulnerabilità, sviluppo di malware o rivendita.

Si tratta di un fenomeno più ampio rispetto a qualcuno che trova una chiave API esposta in un repository pubblico. Google ha osservato un ecosistema che include account rubati, registrazione automatizzata, condivisione di account, aggregazione API, servizi proxy e strumenti anti-rilevamento.

La condivisione di account combina diverse identità o chiavi API dietro un unico servizio. Questo assetto può distribuire l'utilizzo, ridurre l'effetto dei singoli ban e rendere l'attività più difficile da attribuire. Un aggregatore può anche presentare diversi provider attraverso un'unica interfaccia compatibile.

Google aveva già documentato attori che utilizzavano servizi capaci di consolidare account da Gemini, Claude e OpenAI. Il suo report sulle minacce di maggio descriveva strumenti per la registrazione automatizzata, la verifica, l'instradamento, il monitoraggio delle quote e il mascheramento delle impronte del browser.

Alcuni di questi strumenti hanno usi legittimi. Gli sviluppatori spesso instradano le richieste tra diversi modelli per migliorare la disponibilità o controllare i carichi di lavoro interni. Il problema di sicurezza emerge quando gli operatori alimentano questi sistemi con account rubati o creati in modo fraudolento.

Questa distinzione evita un comune errore analitico. Il software proxy non costituisce di per sé una prova di attività criminale. Tuttavia, la combinazione di credenziali rubate, registrazione elusiva, traffico occultato e rivendita non autorizzata crea una catena di abuso riconoscibile.

Google ha inoltre rilevato aggressori che prendevano di mira archivi di configurazione locali utilizzati dagli assistenti di programmazione AI. Nel maggio 2026, i controllori associati alla famiglia di malware ACRSTEALER hanno emesso regole di raccolta file per secrets.json di Cline e config.yaml di Continue AI.

Questi file possono contenere chiavi API in chiaro o endpoint personalizzati per l'instradamento dei modelli. Una sessione del browser rubata potrebbe esporre un singolo account utente, mentre una configurazione per sviluppatori può aprire l'accesso a quote e infrastrutture organizzative.

Il confine pratico di un account AI è quindi diventato difficile da definire. Può includere un'identità, un token di sessione, un segreto API, una configurazione della riga di comando, un ruolo cloud e l'autorizzazione a invocare diversi modelli esterni.

Per i team di sicurezza, questo confine ampliato crea la tensione centrale dell'articolo. Le organizzazioni vogliono integrare l'accesso ai modelli nel lavoro quotidiano, ma ogni comoda integrazione crea un ulteriore punto da cui credenziali preziose possono fuoriuscire.

Perché il furto di account AI ora mette sotto pressione ogni cliente cloud

La pressione ricade sulle organizzazioni che adottano l'AI più rapidamente, perché il loro accesso ai modelli si sta diffondendo più velocemente della responsabilità della sicurezza.

Un tradizionale account software rubato di solito offre a un aggressore accesso a dati o funzioni applicative. Un account AI rubato può aggiungere consumo di modelli a consumo, calcolo cloud, strumenti autonomi e connessioni alla conoscenza interna.

Questa combinazione modifica il danno potenziale. Una credenziale compromessa può generare una fattura, esporre informazioni proprietarie e fornire infrastruttura per attacchi contro altri obiettivi. Inizialmente, la vittima potrebbe rilevare solo un utilizzo insolito anziché un noto segnale di intrusione.

Gli sviluppatori affrontano un'esposizione particolare. Gli assistenti di programmazione AI operano spesso accanto a repository di codice sorgente, terminali, gestori di pacchetti e strumenti di deployment. I loro file di configurazione possono rivelare credenziali con una portata molto maggiore di una singola cronologia di chat.

Il crescente uso dell'AI agentica aumenta ulteriormente la posta in gioco. Un sistema agentico consente a un modello di pianificare passaggi e utilizzare strumenti con un minore intervento umano. Le sue credenziali possono autorizzare l'accesso ai file, l'esecuzione di codice, la navigazione o la comunicazione con servizi esterni.

Google ha riferito che gli attori delle minacce stanno adottando anche framework multi-agente per flussi di lavoro offensivi. Questi sistemi possono coordinare la scansione, risolvere errori e gestire la raccolta di credenziali con meno pause per decisioni umane.

Un caso del secondo trimestre 2026 ha condensato questo cambiamento in una cronologia significativa. GTIG ha osservato aggressori compromettere una risorsa cloud, quindi pianificare, realizzare ed eseguire una campagna di raccolta massiva di credenziali abilitata da agenti in meno di sei ore.

Questa scoperta non significa che ogni gruppo criminale operi ora sistemi di attacco autonomi. Mostra che l'automazione può ridurre il periodo tra l'accesso iniziale e lo sfruttamento su scala.

Tradizionalmente, i difensori fanno affidamento sul tempo tra queste fasi. Un avviso può attivare un'indagine prima che un aggressore ampli l'accesso, crei persistenza o raggiunga sistemi sensibili. Un ciclo di realizzazione ed esecuzione di sei ore lascia molto meno spazio al triage manuale.

Il valore delle credenziali AI rubate si estende anche oltre le loro quote dirette. Un file di configurazione può esporre un endpoint privato, mentre l'identità cloud correlata può rivelare log, archivi dati o applicazioni connesse.

Le organizzazioni dovrebbero quindi trattare il furto di account AI di Google come un problema di sicurezza dell'identità, non solo di governance dell'AI. Il punto di controllo è spesso la credenziale e le autorizzazioni che la circondano, piuttosto che il livello di sicurezza del modello.

I segreti a lunga durata creano il rischio più evidente. Possono rimanere utilizzabili dopo che un dipendente chiude un laptop o modifica una password web. Gli aggressori possono testarli silenziosamente, instradare il traffico attraverso proxy e aumentare l'utilizzo dopo aver confermato i servizi disponibili.

Gli account condivisi degli sviluppatori creano un'altra debolezza. Quando diverse persone o sistemi automatizzati usano un'unica identità, l'attività insolita diventa più difficile da attribuire. Anche la revoca dell'accesso può interrompere il lavoro legittimo, ritardando il contenimento.

I clienti cloud affrontano un secondo problema: il consumo appare normale a livello di infrastruttura. Una chiave valida che effettua richieste valide al modello potrebbe non attivare i controlli progettati per intercettare malware o traffico di rete vietato.

I team hanno invece bisogno di segnali comportamentali. Indicatori utili includono nuove origini geografiche, attivazione inattesa di modelli, cambiamenti improvvisi delle quote, gateway API sconosciuti, tempistiche anomale delle richieste e utilizzo incoerente con il proprietario della credenziale.

Anche i provider di modelli subiscono pressioni. Devono distinguere l'aggregazione legittima dalla condivisione criminale senza bloccare le normali architetture aziendali. Devono inoltre collegare segnali relativi ad account, rete, pagamenti, dispositivi e utilizzo tra prodotti in rapido cambiamento.

La risposta imposta è una riprogettazione dell'identità attorno all'accesso AI. Le organizzazioni necessitano di credenziali a breve durata, autorizzazioni più ristrette, identità di servizio separate, limiti di utilizzo, revoca rapida e monitoraggio collegato al comportamento atteso.

Queste misure suonano familiari perché lo sono i fallimenti sottostanti. Ciò che è cambiato è la risorsa monetizzata e la velocità con cui l'accesso rubato può sostenere ulteriori operazioni.

Il vero compromesso è tra praticità dell'AI e controllo delle credenziali

L'adozione dell'AI riduce gli attriti per gli utenti, ma la stessa praticità può nascondere credenziali in strumenti, plug-in, agenti e file locali.

La maggior parte delle organizzazioni non implementa un unico sistema AI gestito centralmente. I dipendenti utilizzano applicazioni browser, assistenti di programmazione, client da riga di comando, gateway per modelli, piattaforme cloud, estensioni e automazioni personalizzate.

Ogni percorso di accesso gestisce l'identità in modo diverso. Uno può usare un cookie di sessione, un altro una chiave API e un altro ancora un ruolo cloud ereditato dall'ambiente dell'utente. I team di sicurezza possono avere difficoltà a inventariare tutti e tre.

Gli strumenti di programmazione AI rendono questo compromesso particolarmente evidente. Gli sviluppatori si aspettano una configurazione rapida e un accesso ininterrotto ai modelli. Salvare una chiave in un file di configurazione è pratico, ma un malware che già cerca nei sistemi locali può aggiungere quel file al proprio elenco di raccolta.

Le scoperte di Google mostrano che gli infostealer si stanno adattando di conseguenza. Gli operatori di LUMMAC.V2, STEALC.V2, VIDAR e ACRSTEALER hanno mostrato interesse per le configurazioni AI degli sviluppatori, andando oltre il furto dei profili browser.

Gli infostealer sono malware progettati per raccogliere informazioni preziose da un dispositivo infetto. Prendono comunemente di mira password, cookie, wallet e dati applicativi. Aggiungere file di configurazione AI è un'estensione logica di un modello di business consolidato.

Questo meccanismo aiuta a spiegare perché il problema possa crescere senza una svolta drammatica contro i modelli di frontiera. Gli aggressori non devono sconfiggere l'architettura di sicurezza principale di un modello se possono impersonare un utente pagante.

Google ha ripetutamente sottolineato questa distinzione. Le sue conclusioni di febbraio affermavano che gli aggressori necessitavano di chiavi API e risorse per abusare dei servizi LLM su larga scala. Questo requisito crea un incentivo diretto a dirottare organizzazioni con una capacità AI significativa.

Il conflitto diventa più netto quando agli agenti vengono assegnate ampie autorizzazioni sugli strumenti. Per offrire un’assistenza utile, un agente può necessitare dell’accesso a repository, documentazione, sistemi di tracciamento dei problemi e sistemi di distribuzione. Ogni connettore aggiunto aumenta sia l’utilità sia la potenziale esposizione.

Il furto di una credenziale AI non concede automaticamente tutte quelle autorizzazioni collegate. L’esito dipende da come l’organizzazione ha progettato autenticazione e autorizzazione. Identità mal separate, tuttavia, possono trasformare un singolo segreto rubato in diversi percorsi di accesso.

I segreti non dovrebbero trovarsi nei prompt, nei file sorgente, nei notebook o nelle directory di configurazione ampiamente leggibili. Le organizzazioni dovrebbero conservarli in sistemi gestiti per i segreti e assegnarli soltanto al carico di lavoro che ne ha bisogno.

Questa raccomandazione è facile da formulare e più difficile da applicare. Gli sviluppatori possono creare esperimenti temporanei al di fuori delle piattaforme centrali. I team possono condividere credenziali per rispettare una scadenza, mentre prototipi abbandonati possono conservare chiavi attive per mesi.

I gateway AI possono ridurre la proliferazione centralizzando autenticazione e policy. Possono anche diventare obiettivi di alto valore. Se un gateway ha accesso a molti provider e a quote ampie, la sua compromissione offre a un attaccante un concentrato di capacità.

La risposta non è evitare i gateway. È limitare ciò che ogni identità gateway può invocare, stabilire l’attribuzione per utente e impedire che un componente compromesso attivi servizi non correlati.

Le organizzazioni devono anche separare l’accesso ai modelli dall’accesso amministrativo. Un servizio che invia richieste di inferenza non dovrebbe ricevere automaticamente il permesso di modificare la fatturazione, abilitare nuovi modelli, creare identità o recuperare segreti cloud non correlati.

Un’autenticazione solida è importante per gli account interattivi, ma l’autenticazione a più fattori non risolve ogni percorso. Le chiavi API e le identità di servizio spesso operano senza una verifica interattiva, e il materiale di sessione rubato può talvolta aggirare un nuovo accesso.

Durate brevi delle credenziali riducono questa esposizione. Lo stesso vale per i sistemi di identità del carico di lavoro, che sostituiscono le chiavi statiche con token temporanei basati sul contesto verificato dell’applicazione in esecuzione.

I controlli sull’utilizzo forniscono un ulteriore livello di protezione. Budget per identità, limiti di frequenza, liste di modelli consentiti e avvisi per nuove regioni possono ridurre il tempo e la capacità a disposizione di un attaccante.

Anche i log devono conservare un contesto sufficiente per le indagini. Una richiesta a un modello dovrebbe poter essere ricondotta a un utente, un servizio, un ambiente e una finalità approvata, senza esporre inutilmente contenuti sensibili dei prompt.

Per i knowledge worker, la lezione è più personale. Un’estensione del browser, un’utilità di programmazione scaricata o un client non ufficiale possono interporsi tra l’utente e diversi servizi AI a pagamento. Installarne uno comporta una decisione di fiducia su come conserva e trasmette le credenziali.

I dipendenti non dovrebbero incollare chiavi API dell’organizzazione in strumenti non approvati. Dovrebbero inoltre segnalare avvisi di accesso inattesi, notifiche sull’uso dei modelli e improvvisi esaurimenti delle quote come possibili incidenti di sicurezza, anziché come normali errori di fatturazione.

Il compromesso tra comodità e controllo non può essere eliminato. Gli strumenti AI diventano utili raggiungendo più informazioni e compiendo più azioni. L’approccio difendibile consiste nel rendere ogni connessione visibile, limitata, attribuibile e facile da revocare.

L’avvertimento di Google non misura l’intera portata dell’LLM-jacking

Le evidenze mostrano una minaccia reale e in evoluzione, ma non stabiliscono quante organizzazioni abbiano subito perdite dovute all’LLM-jacking.

Il report di Google utilizza formulazioni indicative come “aumento del targeting” e “numero crescente di intrusioni”. Fornisce esempi, tattiche osservate, tendenze dei marketplace e casi di risposta agli incidenti, anziché una stima completa della prevalenza.

Questa limitazione è importante. La threat intelligence riflette gli ambienti, i clienti, le piattaforme e gli spazi underground visibili ai ricercatori che la raccolgono. Le attività al di fuori di quel campo visivo possono non essere conteggiate, mentre gli attori fortemente monitorati possono apparire più rilevanti.

Il raddoppio riportato dei prezzi medi degli account nel mercato underground è informativo, ma incompleto. Google non ha pubblicato la dimensione del campione sottostante, la distribuzione dei prezzi o la metodologia necessaria per confrontare rigorosamente quel mercato nel tempo.

Prezzi più elevati possono indicare una domanda in crescita, un’offerta limitata, una migliore qualità degli account o cambiamenti nei marketplace monitorati. Non dimostrano in modo indipendente che il furto riuscito di account sia raddoppiato.

Il riferimento a un “aumento” dovrebbe quindi essere interpretato come evidenza di una maggiore attività osservata, non come un censimento degli incidenti globali. Le affermazioni più solide di Google riguardano ciò che i suoi team hanno osservato direttamente: più acquirenti e venditori, furto mirato di configurazioni e compromissioni cloud a supporto di carichi di lavoro non autorizzati.

C’è anche un problema terminologico. LLM-jacking può descrivere diversi comportamenti correlati, dall’uso di una singola chiave API rubata al dirottamento di un ambiente cloud aziendale. Riunirli sotto un’unica etichetta può nascondere differenze sostanziali nell’impatto.

La ricerca pubblica originale sulle credenziali cloud rubate definiva l’LLM-jacking come l’uso non autorizzato di servizi di modelli ospitati. Le analisi successive hanno ampliato il quadro includendo reti proxy, rivendita e sviluppo di agenti offensivi.

Questa storia offre un confronto utile. Il cryptojacking cloud seguiva una logica economica simile: gli attaccanti rubavano capacità di calcolo perché la vittima pagava il conto. I carichi di lavoro AI creano un altro impiego monetizzabile per infrastrutture compromesse.

Tuttavia, l’LLM-jacking può generare rischi che vanno oltre i costi di consumo. L’accesso ai modelli può aiutare un attaccante ad analizzare codice rubato, generare esche localizzate, automatizzare la ricerca o creare servizi per altri criminali.

Le conclusioni di Google richiedono un’ulteriore precisazione. L’azienda afferma che gli attaccanti stanno diventando utilizzatori più capaci dell’AI, ma ha anche riferito che molti tentativi di abuso dei modelli hanno attivato sistemi di sicurezza o non hanno prodotto significativi salti di capacità.

In indagini precedenti, gruppi sostenuti da Stati hanno utilizzato Gemini per ricerca, programmazione, traduzione e risoluzione dei problemi. Google ha disabilitato le risorse correlate e aggiornato le proprie difese. Non ha concluso che tali attori avessero sconfitto le protezioni fondamentali del modello.

Questo contrasto è importante. Il furto di account fornisce accesso, ma l’accesso non garantisce output senza restrizioni né operazioni riuscite. I provider possono ancora rilevare gli abusi, applicare policy, disabilitare account e aggiornare le protezioni dei modelli.

I criminali potrebbero inoltre preferire account rubati proprio perché l’applicazione delle misure di sicurezza rimane attiva. Pool di identità usa e getta possono aiutarli ad assorbire i ban, distribuire le richieste e nascondere lo schema più ampio.

La competizione che ne deriva non è semplicemente tra attaccanti e guardrail dei modelli. Riguarda attaccanti che ruotano le identità più velocemente di quanto provider e clienti riescano a collegare comportamenti sospetti tra gli account.

La ricerca indipendente supporta il meccanismo di fondo. Sysdig ha documentato l’LLM-jacking nel 2024 e in seguito ha segnalato obiettivi e tattiche più vari. Tuttavia, la ricerca dei vendor deriva spesso da incidenti selezionati anziché da un campione globale rappresentativo.

I lettori dovrebbero resistere a due conclusioni opposte. Sarebbe errato liquidare la minaccia perché Google non dispone di un conteggio globale. Sarebbe altrettanto errato affermare che ogni account AI o cliente cloud affronti una compromissione immediata.

La conclusione difendibile è più circoscritta. L’accesso AI rubato ha ora un valore osservabile nei marketplace, percorsi tecnici consolidati e un utilizzo criminale dimostrato. Questo è sufficiente per giustificare controlli specifici senza gonfiare le evidenze disponibili.

Cosa osservare dopo l’avvertimento di Google sul furto di account AI

La prossima fase sarà definita dalla telemetria dei provider, dal targeting degli infostealer e dalla capacità delle imprese di isolare le identità AI prima che gli attaccanti amplino il proprio accesso.

Il primo segnale sarà una reportistica più dettagliata da parte dei provider di modelli e cloud. Google ha stabilito una direzione di marcia, ma i report futuri dovranno includere conteggi degli incidenti, tipi di credenziali coinvolte, durata degli abusi e una metodologia di marketplace più chiara.

Tali divulgazioni rafforzerebbero l’ipotesi che gli attacchi Google LLM-jacking rappresentino una categoria di crescita distinta. L’assenza di un’espansione misurabile suggerirebbe che i report attuali riuniscono diverse forme consolidate di abuso delle credenziali sotto un’etichetta specifica per l’AI.

Il secondo segnale è il comportamento degli operatori di infostealer. Google ha osservato regole mirate per le configurazioni degli assistenti di programmazione AI, dimostrando che i criminali sanno dove gli sviluppatori conservano le credenziali dei modelli.

I difensori dovrebbero verificare se più famiglie di malware aggiungono sistematicamente client AI, framework per agenti e gateway dei modelli alle proprie liste di raccolta. Un’adozione diffusa mostrerebbe che i segreti AI sono diventati un obiettivo standard accanto ai cookie del browser e ai wallet di criptovalute.

I team di sicurezza possono individuare internamente questo cambiamento. I rilevamenti sugli endpoint che coinvolgono percorsi di configurazione AI meritano una revisione anche quando non risultano colpiti codice sorgente o archivi di password tradizionali.

Il terzo segnale è l’architettura delle identità aziendali. Le organizzazioni continueranno a distribuire segreti portabili e di lunga durata, oppure passeranno a credenziali temporanee per i carichi di lavoro con autorizzazioni ristrette e attribuzione per utente.

Questa transizione determinerà se l’accesso rubato rimarrà facile da riutilizzare e rivendere. Inventari centralizzati, rotazione rapida, limiti di utilizzo predefiniti e avvisi per l’attivazione dei modelli possono rendere meno preziose le credenziali compromesse.

Anche i provider di modelli hanno un ruolo. Possono identificare il pooling di account attraverso segnali di rete, dispositivo, pagamento e schemi delle richieste. Possono richiedere verifiche più forti quando l’attività attraversa improvvisamente regioni, modelli o profili di utilizzo.

Queste protezioni devono evitare di penalizzare il routing aziendale legittimo. Un’azienda può distribuire intenzionalmente i carichi di lavoro tra regioni o provider. I sistemi di rilevamento hanno bisogno del contesto delle policy dei clienti, non solo di soglie generiche di anomalia.

Le organizzazioni dovrebbero iniziare con un inventario concreto. Identificare chi può accedere ai modelli a pagamento, quali applicazioni conservano le credenziali, quali ruoli cloud possono abilitare servizi e dove vengono registrate le richieste ai modelli.

Dovrebbero poi testare la revoca. Una credenziale che non può essere individuata e disabilitata rapidamente è già una passività per la risposta agli incidenti. I team dovrebbero confermare che la rimozione di un’identità non richieda l’interruzione di carichi di lavoro AI non correlati.

Gli sviluppatori possono ridurre il rischio sostituendo le chiavi statiche locali, separando gli account sperimentali dai sistemi di produzione e rifiutandosi di condividere credenziali tramite chat o repository di codice sorgente. I team di sicurezza dovrebbero rendere il percorso approvato più semplice della soluzione alternativa.

I dirigenti dovrebbero porsi una domanda semplice: se una credenziale AI venisse rubata stanotte, l’organizzazione noterebbe prima l’attaccante, la fattura o i dati sottratti?

L’avvertimento di Google rende urgente questa domanda perché gli attaccanti non considerano più l’accesso AI una novità. Lo vedono come una risorsa che può essere acquisita, aggregata, consumata e venduta.

I prossimi mesi dovrebbero rivelare se i provider pubblicheranno misurazioni più solide e se gli infostealer amplieranno le proprie liste di obiettivi. I lettori dovrebbero sfruttare questa finestra per verificare l’accesso AI prima che il mercato underground maturi ulteriormente.