Pagine civetta svuotano i conti mentre un sito può avvelenare gli agenti AI locali

🛡️ Executive Summary

• La Polizia di Frontiera di Catania ha denunciato sei uomini per truffa e riciclaggio dopo un’indagine su pagine civetta, messaggistica e bonifici istantanei.
• Separatamente, una ricerca di Oasis Security mostra una catena DNS rebinding capace in alcune configurazioni NemoClaw/Ollama di raggiungere l’API locale senza autenticazione.
• L’attacco AI può modificare il chat template del modello e rendere persistenti istruzioni malevole invisibili alle successive applicazioni che interrogano Ollama.

Una pagina Web può essere sufficiente per convincere una persona a consegnare denaro oppure, in uno scenario completamente diverso, per raggiungere un servizio AI locale che il proprietario considera confinato alla propria macchina. Due casi emersi il 25 agosto mostrano quanto il browser sia diventato un punto di contatto tra mondi tradizionalmente separati. A Catania la Polizia di Stato ha ricostruito una rete che avrebbe utilizzato siti civetta, messaggistica e bonifici istantanei per prosciugare conti correnti e riciclare il denaro. Sul versante AI, una ricerca di Oasis Security descrive invece una debolezza nelle configurazioni Windows/WSL di NVIDIA NemoClaw con Ollama che consentirebbe a una pagina controllata dall’attaccante di alterare persistentemente il comportamento del modello locale.

A Catania sei uomini denunciati dopo le truffe con pagine civetta

La Polizia di Stato riferisce di avere individuato una presunta rete criminale al termine di un’indagine sviluppata dagli agenti della Polizia di Frontiera dell’aeroporto di Catania Fontanarossa. Sei uomini sono stati denunciati all’autorità giudiziaria per truffa e riciclaggio di denaro, ferma restando la presunzione di innocenza fino a un eventuale accertamento definitivo. Secondo gli investigatori, il gruppo avrebbe realizzato pagine Internet civetta molto simili ai siti autentici, utilizzandole per convincere le vittime a fornire informazioni personali e documenti. Il meccanismo rientra nella stessa evoluzione del phishing che ha portato kit come JWR a gestire in tempo reale carte, OTP e identità mentre la vittima interagisce con la pagina: il sito falso non è più soltanto una copia grafica, ma una fase di una procedura sociale più ampia.

La messaggistica accompagna la vittima fino al bonifico istantaneo

Gli utenti sarebbero stati contattati anche attraverso una nota applicazione di messaggistica, ricevendo indicazioni che in diversi casi li avrebbero convinti a effettuare bonifici istantanei, difficili da revocare una volta completati. È un passaggio importante perché dimostra come il sito civetta rappresenti soltanto un elemento della frode. Il criminale deve costruire fiducia, acquisire informazioni e mantenere il controllo della conversazione abbastanza a lungo da trasformare la compromissione dei dati in un movimento finanziario reale. La dinamica è vicina alle campagne italiane che imitano SPID, pagoPA e istituzioni pubbliche, nelle quali l’interfaccia Web serve soprattutto a rendere plausibile un’azione che la vittima finisce per autorizzare volontariamente.

Tabulati e flussi finanziari ricostruiscono il percorso del denaro

La squadra di polizia giudiziaria ha incrociato tabulati telefonici e informazioni sui flussi finanziari fornite dagli istituti di credito, ricostruendo quella che gli investigatori descrivono come una rete capace di produrre guadagni rilevanti. Il denaro proveniente dalle frodi sarebbe stato trasferito attraverso operazioni multiple su diversi conti correnti, nel tentativo di renderne più difficile la provenienza, per poi essere recuperato anche attraverso prelievi in contanti. È il livello che spesso rimane meno visibile nelle campagne di phishing: rubare credenziali o convincere una vittima a eseguire un bonifico serve a poco se non esiste una struttura capace di movimentare e monetizzare rapidamente i fondi. Il cybercrime finanziario moderno combina quindi frontend Web, social engineering e money laundering in un’unica catena operativa.

NemoClaw mostra un rischio completamente diverso nascosto dietro una pagina Web

La seconda vicenda non ha alcun collegamento operativo con l’indagine italiana, ma parte dallo stesso oggetto: una pagina controllata dall’attaccante aperta nel browser. Oasis Security ha descritto una possibile catena contro NVIDIA NemoClaw, stack open source destinato all’esecuzione di agenti come OpenClaw dentro sandbox OpenShell. NemoClaw può utilizzare Ollama come backend di inferenza locale e proprio la modalità con cui alcune configurazioni rendono raggiungibile il server del modello apre il problema. La documentazione NVIDIA per l’inferenza locale con Ollama mostra che il comportamento cambia in base alla piattaforma: sui normali host il backend viene mantenuto su loopback e protetto attraverso un proxy con token, mentre alcuni percorsi Windows/WSL richiedono configurazioni differenti per permettere ai container Docker Desktop di raggiungere il servizio.

OLLAMA_HOST su 0.0.0.0 rende l’API raggiungibile oltre il loopback

Nello scenario analizzato, il percorso Windows-host può configurare OLLAMA_HOST=0.0.0.0:11434, facendo ascoltare Ollama su tutte le interfacce invece che soltanto su 127.0.0.1. L’API nativa di Ollama sulla porta 11434 non utilizza normalmente un sistema di autenticazione applicativa. Anche la documentazione dell’integrazione NemoClaw di Ollama contempla l’esposizione del servizio in configurazioni WSL2 o containerizzate. Questo tipo di superficie non è teoricamente nuovo: NadMesh ha già dimostrato quanto server Ollama e altri servizi AI esposti possano diventare bersagli per furto di credenziali e accesso al cloud. La particolarità del nuovo attacco è però che non richiede necessariamente che l’API sia direttamente accessibile da Internet.

Il DNS rebinding porta il browser dal sito dell’attaccante a localhost

La tecnica utilizza DNS rebinding. La vittima visita inizialmente un dominio controllato dall’attaccante e il browser scarica normalmente JavaScript dal server remoto. Successivamente la risoluzione DNS dello stesso hostname viene modificata in modo che punti verso 127.0.0.1, mentre dal punto di vista del browser l’origine continua ad apparire coerente. Il JavaScript può così tentare di raggiungere il servizio locale mantenendo il dominio utilizzato nella navigazione iniziale. Il principio sfrutta una debolezza classica: un’applicazione considera “fidabile” una richiesta perché proviene da localhost, mentre il browser può essere utilizzato come ponte tra una pagina Internet e quel servizio. Meccanismi DNS analoghi hanno già dimostrato quanto la manipolazione della risoluzione possa trasformare infrastrutture apparentemente isolate in superfici di attacco.

Il bersaglio non è soltanto Ollama ma il template con cui il modello interpreta ogni conversazione

Una volta raggiunta l’API, la ricerca mostra la possibilità di utilizzare /api/create per modificare il chat template associato al modello. Il template determina come messaggi di sistema, richieste dell’utente e risposte vengono trasformati nel testo effettivamente fornito al modello durante l’inferenza. Un aggressore può quindi aggiungere istruzioni nascoste che vengono inserite automaticamente in ogni successiva conversazione. È qui che l’impatto cambia natura: non viene semplicemente rubata una risposta dell’AI, ma viene alterato persistentemente il modo con cui il modello interpreta le richieste future. L’applicazione che utilizza Ollama potrebbe continuare a inviare il proprio system prompt senza sapere che il template sottostante sta aggiungendo istruzioni estranee.

Il poisoning sopravvive alle conversazioni successive

Secondo la ricerca, le istruzioni introdotte nel template persistono e vengono applicate anche alle nuove sessioni. Non si tratta quindi della classica prompt injection presente in una singola pagina o documento, che cessa quando quel contenuto esce dal contesto. Il comportamento si avvicina molto di più alla Stealthy Memory Injection capace di avvelenare la memoria a lungo termine degli agenti AI: l’attaccante cerca di intervenire sullo strato persistente che condizionerà decisioni future. In NemoClaw il problema diventa ancora più delicato perché un agente non genera soltanto testo. Può disporre di tool, filesystem, API e capacità operative dentro una sandbox. Compromettere stabilmente le istruzioni dell’agente significa quindi potenzialmente influenzare azioni successive anche quando l’utente non sta più interagendo con la pagina che ha originato l’attacco.

Non esiste però al momento una CVE né una campagna osservata in natura

Il rischio deve essere delimitato con precisione. Al 25 agosto 2026 non risulta pubblicato un identificativo CVE specifico per questa catena, non è stato indicato un intervallo completo di versioni vulnerabili e non sono stati segnalati sfruttamenti in-the-wild. Inoltre NemoClaw ha già introdotto nel ramo corrente controlli che, sui percorsi nei quali viene utilizzato il proxy locale, rifiutano backend Ollama raggiungibili su interfacce non-loopback. La protezione non copre però necessariamente ogni configurazione Windows/WSL nella quale il proxy non viene avviato nello stesso modo. Gli operatori non devono quindi interpretare la ricerca come prova che qualsiasi installazione NemoClaw sia compromettibile, ma devono verificare concretamente dove ascolta Ollama, se la porta 11434 è raggiungibile e quali controlli Host/Origin proteggono l’API.

Due pagine Web mostrano due problemi opposti di fiducia

A Catania la pagina falsa funziona perché la persona si fida di ciò che vede. Nel caso NemoClaw la pagina potrebbe funzionare perché un servizio locale si fida eccessivamente della provenienza della connessione. È la stessa parola — fiducia — applicata a due livelli completamente differenti. La lezione per gli utenti resta quella tradizionale: un sito graficamente credibile non rende autentica una richiesta di documenti o un bonifico. Per chi costruisce infrastrutture AI locali la regola è più nuova ma altrettanto netta: localhost non è un meccanismo di autenticazione e un modello eseguito sul computer non è automaticamente isolato dal Web. Man mano che gli agenti AI acquisiscono strumenti e autonomia, questa distinzione diventa critica. Una pagina ostile non deve necessariamente “bucare” la sandbox per diventare pericolosa: può essere sufficiente convincere l’agente, o il livello che gli fornisce il modello, a fidarsi delle istruzioni sbagliate.