Il termine “LLMJacking” è stato coniato da Mandiant nel 2026 per descrivere una nuova forma di furto di risorse informatiche, in cui gli aggressori ottengono l’accesso non autorizzato a modelli di linguaggio di grandi dimensioni (LLM) ospitati su infrastrutture cloud e ne sfruttano la potenza computazionale a fini di profitto. A differenza del tradizionale cryptojacking, che consuma risorse in modo graduale, il LLMJacking può generare picchi di spesa in poche ore, con costi fraudolenti che superano i 100 000 USD al giorno e, in alcuni casi, raggiungono la cifra di un milione di dollari prima che l’accesso venga revocato.

Il panorama globale delle compromissioni

Le indagini condotte dal Google Threat Intelligence Group (GTIG) hanno rilevato che gli attacchi hanno interessato organizzazioni in Nord America, Sud America e Asia‑Pacifico, operanti nei settori finanziario, retail, tecnologico e dei trasporti. Le intrusioni hanno coinvolto diversi fornitori cloud e LLM, dimostrando che la vulnerabilità non è limitata a una singola piattaforma.

GTIG ha identificato diversi cluster di attori motivati dal profitto, distribuiti in più regioni. Questi gruppi si sono specializzati in una divisione del lavoro: alcuni si occupano dell’accesso iniziale ai sistemi compromessi, mentre altri gestiscono l’infrastruttura di monetizzazione nota come “LLM Mixers”. Gli LLM Mixers agiscono da gateway illeciti che proxy, aggregano e rivendono l’accesso non autorizzato a LLM a sottoscrittori underground.

Lifecycle dell’attacco LLMJacking

1. Accesso iniziale

Le tecniche più comuni per ottenere l’accesso iniziale includono:

    • Token di identità cloud esposti o rubati (IAM credentials, chiavi di Service Account, GitHub Personal Access Tokens, token di sessione attivi).
    • Chiavi API LLM lasciate pubblicamente accessibili su repository GitHub.
    • Scripting automatico per verificare endpoint LLM non protetti, ad esempio chiamando /api/create per avviare modelli su risorse pubbliche.

Un caso emblematico è stato quello di UNC6993, che ha compromesso una Service Account mal configurata, ha ottenuto l’accesso a un’API LLM e ha creato una pagina di hijacking della sessione che ingannava gli utenti facendoli incollare token JSON in un form mascherato.

2. Movimento laterale e persistenza

Dopo l’infiltrazione, gli attori eseguono:

    • Ricognizione interna per mappare regioni cloud, servizi disponibili e policy di identità.
    • Clonazione di repository per cercare segreti hardcoded, variabili di configurazione e credenziali di sviluppatori.
    • Query a data warehouse per estrarre password di database, credenziali amministrative e colonne sensibili.
    • Abuso di permessi IAM per creare credenziali temporanee di account ad alto privilegio, consentendo l’esfiltrazione di secret manager e chiavi API di terze parti.
    • Creazione di account IAM non autorizzati e iniezione di chiavi SSH in metadati di VM, garantendo accessi persistenti.

In alcuni casi, gli aggressori hanno sfruttato vulnerabilità specifiche del software di routing LLM per elevare i privilegi, dimostrando una conoscenza approfondita delle architetture di servizio.

3. Monetizzazione

Una volta ottenuto l’accesso, gli attori avviano richieste massicce verso gli endpoint LLM, spesso configurando parametri di token minimo (es. max_tokens=1) per validare le chiavi rubate senza generare allarmi di volume. Le richieste sono poi instradate attraverso gli LLM Mixers, che le aggregano e le vendono a gruppi underground che le utilizzano per:

    • Generare contenuti fraudolenti (spam, phishing, deepfake testuali).
    • Eseguire code generation per sviluppo software non autorizzato.
    • Addestrare modelli proprietari con dati rubati, riducendo i costi di ricerca e sviluppo.

Le spese fraudolente osservate variano da centinaia di migliaia a oltre un milione di dollari, con picchi giornalieri che superano i 100 000 USD.

Indicazioni operative per la difesa

Rilevamento

Implementare controlli di monitoraggio basati su:

    • Analisi dei log di API LLM per individuare pattern di chiamata anomali (es. volumi elevati di max_tokens=1).
    • Alert su creazione non autorizzata di Service Account o IAM policy ad alta privilegiatura.
    • Rilevamento di token di accesso esposti in repository pubblici tramite scansioni regolari con tool come GitGuardian.

Rinforzo

Le misure di hardening includono:

    • Restrizione dell’accesso alle API LLM mediante liste di controllo IP e autenticazione a più fattori.
    • Rotazione regolare delle chiavi di Service Account e utilizzo di chiavi a breve vita (short‑lived).
    • Separazione delle funzioni di amministrazione cloud da quelle di sviluppo, con privilegi minimi.
    • Applicazione di policy di “least privilege” per le identità IAM, evitando permessi di creazione di token per account di servizio non necessari.

Remediation

In caso di compromissione, le azioni consigliate sono:

    • Revocare immediatamente tutti i token sospetti e rigenerare le chiavi API LLM.
    • Eseguire una revisione completa degli account IAM, disabilitando quelli inattivi o non riconosciuti.
    • Utilizzare strumenti di forense cloud per tracciare la catena di compromissione e identificare eventuali backdoor persistenti.
    • Comunicare l’incidente al provider cloud e, se necessario, avviare una procedura di risposta coordinata con le autorità competenti.

Conclusioni

Il LLMJacking rappresenta una minaccia emergente che combina l’alto valore dei modelli LLM con la capacità di generare costi cloud enormi in tempi brevissimi. La proliferazione di credenziali cloud esposte, la diffusione di repository pubblici non sicuri e la specializzazione dei gruppi criminali in attività di “mixing” rendono essenziale un approccio difensivo multilivello. Le organizzazioni devono investire in monitoraggio continuo, gestione rigorosa delle identità e policy di accesso granulari per mitigare il rischio e proteggere sia i propri budget che la reputazione digitale.