LLMjacking si evolve: server Ollama esposti diventano il cervello di uno strumento di hacking autonomo, catturato in sviluppo da Sysdig
Si parla di:
Toggle
Il 12 giugno 2026, il Sysdig Threat Research Team (TRT) ha osservato qualcosa che i ricercatori di sicurezza prevedevano da almeno due anni: un threat actor che utilizzava un server AI accessibile su internet come cervello di uno strumento di hacking completamente automatizzato. Non si trattava di un esperimento accademico né di una proof-of-concept: il framework, denominato VAPT, era in sviluppo attivo, con stadi aggiornati in tempo reale, e operava contro ambienti benchmark privati usando capacità di inferenza sottratte tramite un server Ollama esposto senza autenticazione.
Dal furto di compute all’arma autonoma: l’evoluzione del LLMjacking
Il termine LLMjacking è stato coniato da Sysdig nel maggio 2024 per descrivere il pattern in cui attori malevoli utilizzano credenziali cloud sottratte per accedere a servizi AI a pagamento — OpenAI, Anthropic, Google Gemini — scaricando le spese sulla vittima, con costi potenziali fino a 46.000 dollari al giorno. Entro il 2025, questa pratica si era industrializzata in un mercato nero con infrastruttura di reverse-proxy che intermediava miliardi di token rubati.
Con la proliferazione di server AI auto-ospitati, la superficie di attacco si è spostata. Ollama, il popolare tool per servire modelli LLM in locale, ascolta sulla porta 11434 senza autenticazione per impostazione predefinita. Ricercatori indipendenti hanno catalogato circa 175.000 istanze Ollama pubblicamente esposte in più di 130 paesi, una superficie enorme di compute non protetto e non fatturato. Ciò che Sysdig TRT ha osservato a giugno 2026 è il passo successivo: non il furto di compute per rivenderlo, ma il suo utilizzo come motore ragionante per offensive tooling autonomo.
Il threat actor e le sessioni osservate
La prima sessione osservata dal Sysdig TRT ha avuto origine dall’IP 122.183.48.82, registrato a un provider residenziale/small-business di Hyderabad, India. La sessione è iniziata alle 15:43 UTC del 12 giugno 2026 e si è protratta per circa otto ore e mezza. Due giorni dopo, il 14 giugno, lo stesso tool è tornato operativo da tre IP aggiuntivi: 122.183.48.35, 122.183.48.195 (stessa rete del primo) e 47.15.69.15, tutti riconducibili a connessioni residenziali indiane.
Sysdig attribuisce tutte le sessioni allo stesso operatore per tre ragioni convergenti: identica pipeline VAPT, identici target benchmark privati, e comune origine geografica indiana. La rotazione tra ISP è la normale variazione di una connessione residenziale, non il segnale di operatori multipli indipendenti.
Architettura del framework VAPT: il modello AI come decision engine
Ciò che rende questa campagna eccezionale dal punto di vista dell’analisi è la visibilità completa ottenuta da Sysdig. Poiché il framework invia le proprie istruzioni complete al modello a ogni richiesta, il team ha potuto catturare l’architettura integrale: ogni stadio della pipeline logica, la struttura imposta agli output del modello, e la firma usata per confermare una compromissione.
Il framework VAPT opera come una pipeline sequenziale di stadi specializzati, ciascuno con un ruolo preciso:
- Service fingerprinting: normalizza i banner dei servizi di rete in un’identità software precisa per la ricerca CVE.
- Vulnerability matching e triage: incrocia prodotto e versione con le vulnerabilità note, filtrando quelle applicabili.
- Web reconnaissance: analizza testo della pagina, header, cookie, form field e path scoperti per costruire un profilo di attacco.
- Proof-of-concept synthesis: costruisce PoC per validare singole vulnerabilità, inclusi payload protocol-aware.
- Blind SQL injection crafting: costruisce payload time-based con logica di filter-evasion.
- Credential e secret extraction: analizza file di sistema compromessi alla ricerca di credenziali riusabili.
- Arbitrary file-read planning: data una primitiva di lettura file, pianifica quali file recuperare.
- Privilege escalation: decide il passo successivo per l’escalation dei privilegi.
- Autonomous orchestration: controller che guida l’intera catena fino al raggiungimento di command execution.
L’orchestratore autonomo: il codice catturato
Lo stadio di orchestrazione è il più rivelatore dell’intento del tool. L’istruzione inviata al modello specifica un agente di web-exploitation “autorizzato” che deve raggiungere la command execution sul target. Una volta confermata l’RCE tramite il pattern echo VAPTb3gin; id; echo VAPTfin, il tool congela la richiesta riuscita sostituendo il comando con il placeholder __VAPTCMD__, trasformando il singolo exploit in una ricetta riutilizzabile con qualsiasi comando.
Una variante dell’orchestratore rivela un ulteriore dettaglio architetturale: il modello opera in modalità “PROPOSE-ONLY”, mentre un verificatore deterministico separato (oracles.py) decide se un payload ha effettivamente avuto successo. Questa separazione tra componente AI (proposta) e componente deterministica (verifica) è il design pattern di software mantenuto professionalmente, non di uno script improvvisato.
Il tool era in sviluppo attivo
Uno degli aspetti più significativi della campagna è la prova che il tool era in sviluppo iterativo durante le sessioni osservate. Nella sessione dell’8 ore del 12 giugno, il set di stadi è cresciuto nel corso della giornata: service fingerprinting, vulnerability triage, blind SQL injection, PoC synthesis e orchestratore autonomo sono apparsi dopo circa tre ore. Credential extractor e file-read planner sono stati aggiunti in serata, gli stadi per il database SQL triage nelle ultime novanta minuti. Singoli stadi sono stati riscritti in-place più volte — la fase di web-reconnaissance ha attraversato tre versioni distinte.
Quando il tool è tornato il 14 giugno, il set completo di stadi — inclusi quelli apparsi solo nelle fasi finali della sessione precedente — era presente fin dalle prime richieste. Il threat actor aveva integrato ogni aggiunta nel codice baseline prima del run successivo. Sysdig descrive questo come un vantaggio di osservazione straordinariamente precoce: il tool è stato catturato prima di essere diretto contro vittime reali.
I modelli richiesti: agnosticismo del backend
Un dettaglio tecnico rivelatore è l’elenco dei modelli richiesti dal tool al server Ollama: gpt-4o-mini (OpenAI), claude-3-5-sonnet (Anthropic), gemini-2.0-flash-exp (Google), mistral:7b, deepseek-r1:8b, qwen3.5:4b, e una versione “abliterated” (con guardrail rimossi) di Llama-3.3-70B. I tre modelli commerciali non sono compatibili con Ollama: la loro presenza mostra che il tool è backend-agnostico e l’operatore aveva semplicemente reindirizzato il backend verso il server Ollama gratuito in sostituzione di un API key a pagamento. Il server esposto era un drop-in sostituto per l’inferenza a tariffazione.
Due righe per i difensori
Sysdig identifica un blind spot difensivo fondamentale: il rilevamento che monitora i log del proprio server modello presuppone che l’operatore possieda e monitori quel server. Un server esposto scoperto da un attore esterno è, per definizione, uno che il proprietario non sta osservando. I proprietari vedranno compute elevato e una porta aperta, non una pipeline di attacco multi-stadio.
Indicatori di Compromissione
# IP sorgente osservati
122.183.48.82 # Hyderabad, India - sessione 12 giugno
122.183.48.35 # Hyderabad, India - sessione 14 giugno
122.183.48.195 # Hyderabad, India - sessione 14 giugno
47.15.69.15 # India, secondo ISP - sessione 14 giugno
# Marker di compromissione (RCE oracle)
echo VAPTb3gin; id; echo VAPTfin
# Marker nel payload
VAPTb3gin # Sentinel di apertura
VAPTfin # Sentinel di chiusura
__VAPTCMD__ # Placeholder per replay exploit
# Target fittizi del benchmark
MediaVault Asset Portal
Reverb Studio
# Range di rete target
172.30.0.0/24 # Range benchmark privato
10.129.0.0/16 # Range HackTheBox lab VPN
# Porta esposta
11434 # Porta default Ollama (no auth)
# Pattern di detection (Falco)
richieste HTTP su porta 11434 con contenuto
matching /VAPTb3gin|VAPTfin|VAPTCMD/
Raccomandazioni operative
- Isolare i server modello dalla rete pubblica: Ollama e sistemi simili devono essere esposti solo su localhost o su interfacce interne, mai su internet. La porta 11434 non deve essere raggiungibile dall’esterno.
- Aggiungere autenticazione a livello di proxy: Ollama non implementa autenticazione nativa; deve essere aggiunta tramite un reverse proxy autenticante.
- Monitorare il volume di inferenza: picchi anomali di compute sul server AI sono un indicatore primario di abuso esterno.
- Cercare i marker VAPT nei log: scansionare i log delle applicazioni web per le stringhe
VAPTb3gin, VAPTfin e __VAPTCMD__ — la loro presenza indica che un sistema è stato attaccato da questo framework o da varianti. - Scansione proattiva dei propri asset: verificare internamente la presenza di server Ollama o altri inference endpoint esposti su internet con la stessa metodologia usata da un attaccante.
Fonte: Sysdig Threat Research Team, Michael Clark (Director of Threat Research). Research pubblicato il 17 giugno 2026. Full report: sysdig.com/blog/llmjacking-evolved
Sysdig TRT caught a threat actor using a stolen Ollama server to power an autonomous, multi-stage offensive hacking tool — live, in development, and in full detail.
Michael Clark (Sysdig)
Marcel Geveler
in reply to netzpolitik.org • • •Claus Berthold
in reply to netzpolitik.org • • •