Predatori di LLM e come respingerli

La sicurezza dell’IA non è limitata solo a prevenire furti di dati, bloccare agenti IA non autorizzati o impedire agli assistenti IA di fornire consigli dannosi. Una nuova minaccia, relativamente semplice ma in rapida crescita, è all’orizzonte in forma di tentativi di dirottare e sfruttare potenza di calcolo e reti neurali altrui per guadagno personale. Questa tecnica è nota come dirottamento di LLM o LLMjacking. Con la previsione ampiamente diffusa del drammatico aumento dei costi di elaborazione dell’IA, il numero di aggressori è destinato a crescere. Di conseguenza, è fondamentale stabilire rigorose misure di sicurezza sin dal primo giorno di distribuzione di server IA proprietari e dei relativi ecosistemi di supporto come RAG o MCP.

Statistiche da un honeypot

La velocità e la portata di questi tentativi di dirottamento sono illustrate al meglio in un esperimento documentato in dettaglio nell’aprile 2026. Un Raspberry Pi è stato mascherato da server IA privato ad alte prestazioni ed è stato reso accessibile da Internet. Sottoposto a query, segnalava la disponibilità di server Ollama, LM Studio, AutoGPT, LangServe e text-gen-webui, tutti strumenti comunemente usati come wrapper per modelli di IA ospitati localmente. Il server appariva inoltre pronto ad accettare richieste API nel formato OpenAI, ormai diventato lo standard del settore.

Tutti questi servizi apparivano alimentati da un’istanza locale di Qwen3-Coder 30B Heretic, uno dei modelli open source più potenti, ma senza il relativo allineamento di sicurezza. Poi, per dare più pepe all’operazione, l’honeypot segnalava la presenza di vari database RAG e di un server MCP dotato di allettanti funzionalità come get_credentials.

In realtà, il Raspberry Pi ospitava semplicemente 500 risposte presalvate da un vero modello Qwen3, con un breve script che selezionava la risposta più pertinente per ogni query in entrata. Questa configurazione è stata sufficiente a superare un controllo superficiale e consentire al ricercatore di sondare le intenzioni degli aggressori.

Stando all’autore dell’esperimento, Shodan (il popolare servizio di scansione Internet) ha scoperto il server entro tre ore dalla sua messa in funzione. Solo un’ora dopo sono iniziate a piovere richieste d’aspetto simile a funzioni di ricognizione. Nel mese successivo il server ha gestito più di 113.000 richieste da migliaia di IP univoci, con il 23% di tale traffico mirato specificamente all’individuazione delle funzionalità dell’IA e allo sfruttamento di LLM e agenti IA locali.

Le richieste a endpoint come /api/tags e /v1/models consentono a utenti malintenzionati di rilevare le impronte digitali dei modelli ospitati in un server, mentre la scansione alla ricerca di /.cursor/rules in genere precede il tentativo di sfruttamento di un agente IA. Analogamente, il controllo di /.well-known/mcp.json funge da inventario dei server MCP della vittima. Sebbene l’autore non faccia menzione del numero totale di attacchi proceduti oltre la semplice scansione, sono stati contati 175 tentativi attivi di dirottare l’LLM durante l’ultima settimana dell’esperimento.

Di cosa vanno in cerca gli attaccanti?

In base alle osservazioni del ricercatore, nessuno di coloro che hanno preso di mira il server-esca ha tentato di eseguire codice arbitrario o di ottenere l’accesso come root (il che, aggiungiamo noi, è sorprendente e potrebbe indicare lacune nei dati di registrazione). Quasi tutti gli attacchi erano volti a sottrarre risorse. Ad esempio, a esperimento in corso sono state registrate le seguenti attività:

• Un tentativo ben strutturato di analizzare la documentazione tecnica di un microprocessore
• Un prompt per la scrittura di un romanzo erotico
• Richieste di analizzare e strutturare dati di testo da social media relativi a nuove vulnerabilità
• Tentativo di chiamare modelli Anthropic usando il server compromesso come proxy API

Vale la pena notare che la ricognizione delle risorse IA usa strumenti standardizzati e in rapida evoluzione. Le richieste provenienti da un’applicazione denominata LLM-Scanner provenivano dall’infrastruttura di sette diversi provider cloud in otto paesi, suggerendo che gli aggressori stettero mettendo in atto metodologie consolidate e piattaforme specializzate in tecniche di condivisione. Entro la terza settimana dell’esperimento lo scanner è stato aggiornato con un controllo aggiuntivo: ora usava semplici domande astratte per verificare di stare interagendo con l’IA e non con un honeypot che restituisse risposte predefinite.

Tra gli attacchi non specifici, l’esperimento ha registrato numerosi tentativi di esfiltrazione delle credenziali dal file .env.  Questo file è stato sistematicamente cercato in ogni possibile directory del server. Lasciare un file .env accessibile pubblicamente è uno degli errori più elementari nella distribuzione di progetti in Laravel, Node.js e altri framework, ma rimane una svista comune, soprattutto tra principianti e programmatori vibe. Di conseguenza, gli aggressori hanno tutte le ragioni di aspettarsi che i loro sforzi vengano ripagati.

Conclusioni e consigli per difendersi

La scansione dei server accessibili al pubblico e il tentativo di sfruttarli non è una novità, ma l’ascesa degli LLM offre agli aggressori un nuovo modo di monetizzare i propri sforzi, altamente redditizio per loro e devastante per le vittime. Per capire quanto potrebbero diventare massicci questi attacchi, dobbiamo guardare la loro controparte più prossima: il mercato del cryptojacking, dove i criminali estraggono criptovalute usando risorse di calcolo rubate. Quel mercato è cresciuto del 20% nel solo 2025. Con il proliferare di soluzioni basate sull’intelligenza artificiale, l’aumento dei costi di abbonamento da parte dei principali provider e la scarsità di chip dedicati, dovremmo aspettarci che il dirottamento di LLM diventi un fenomeno su scala industriale.

Misure difensive per infrastrutture IA private

• Per i sistemi di IA in esecuzione localmente su un singolo computer, assicurartevi che server come LM Studio, Ollama o simili siano configurati per accettare connessioni solo nell’interfaccia locale (localhost), anziché in tutte le interfacce di rete disponibili. Così facendo limiterete l’accesso da parte dell’LLM al computer host stesso e impedirete che l’IA sia raggiungibile tramite Internet.
• Per i server che gestiscono le richieste remote, anche se il server opera solo all’interno di una rete aziendale locale, implementate un’autenticazione e un’autorizzazione solide anziché fare affidamento esclusivamente sulla convalida della chiave API. Le soluzioni basate su OIDC o OAuth2 con token di breve durata sono le più efficaci. Ciò non solo protegge dal dirottamento di LLM, ma consente anche un tracciamento più granulare delle attività dell’utente e previene abusi delle chiavi API. Inoltre, le chiavi devono essere protette da più che semplici utenti malintenzionati esterni; un rischio crescente è infatti l’uso improprio delle chiavi da parte degli stessi agenti di IA. Questo vale per le interfacce LLM, ma anche per MCP, RAG e altro.
• Usate la segmentazione della rete e liste di IP consentiti per concedere al server IA solo l’accesso ai reparti, ai dipendenti e ai servizi che lo richiedono.
• Verificate che tutte le connessioni client-server siano protette con una versione corrente di TLS.
• Applicate il principio del privilegio minimo separando l’accesso a servizi specifici; ad esempio, i componenti MCP e LLM dovrebbero disporre di propri token di accesso distinti.
• Assicuratevi che sia installato un agente di protezione EDR in tutte le workstation e i server, inclusi quelli che ospitano modelli AI.
• Monitorate il consumo delle risorse IA, stabilite quote d’uso per i diversi ruoli dei dipendenti e impostate avvisi per picchi di attività anomali.
• Gestite registri dettagliati delle risposte LLM e delle richieste rivolte al modello e ai relativi strumenti di supporto. Integrate queste fonti con il vostro SIEM. Verificate la resilienza dei log da manomissioni o eliminazioni.