Verme AI auto-replicante usa LLM locali e infetta reti senza API esterne

Un team guidato da ricercatori dell’Università di Toronto dimostra che un verme informatico alimentato da agenti AI può propagarsi autonomamente in una rete eterogenea usando modelli linguistici open-weight eseguiti localmente, senza dipendere da API commerciali o servizi cloud proprietari. Il proof-of-concept, descritto nel paper AI Agents Enable Adaptive Computer Worms, mostra un salto concettuale rispetto ai worm tradizionali: il malware non trasporta soltanto exploit predefiniti, ma ragiona sui target, legge lo stato della rete, interpreta vulnerabilità disponibili pubblicamente e costruisce strategie di attacco su misura. Nei test condotti in una rete isolata chiamata FakeCorp, composta da 33 host Linux, Windows Server, dispositivi IoT e macchine con GPU, il sistema ottiene accesso elevato in media su 23,1 host e riesce a replicarsi su 20,4 macchine, pari a circa il 62% dell’ambiente. La propagazione raggiunge fino a sette generazioni in sette giorni, dimostrando che l’autonomia agentica applicata al malware non appartiene più alla sola teoria. Il lavoro, firmato da Jonas Guan, Tom Blanchard, Hanna Foerster, Hengrui Jia, Gabriel Huang e Nicolas Papernot, coinvolge CleverHans Lab, Vector Institute, University of Cambridge e ServiceNow, e apre un fronte critico per la sicurezza delle reti aziendali che ospitano GPU e infrastrutture locali di inferenza.

Un worm AI costruito su modelli open-weight locali

Il punto più rilevante della ricerca è l’assenza di dipendenza da servizi AI esterni. Il worm utilizza modelli linguistici open-weight eseguiti localmente su host dotati di GPU, eliminando vincoli tipici delle API commerciali come rate limit, costi per token, policy di rifiuto o kill-switch centralizzati. Questo dettaglio cambia radicalmente il modello economico della minaccia. Un attaccante che compromette un primo host con capacità GPU può usare la potenza di calcolo rubata per sostenere ulteriori fasi di inferenza, pianificazione e propagazione. Il costo marginale di ogni nuova infezione tende così a zero, perché l’operazione non dipende più da risorse pagate dall’attaccante ma da hardware sottratto alla vittima.

Nei contesti aziendali moderni, dove server di machine learning, workstation scientifiche e cluster GPU diventano sempre più diffusi, questo scenario assume particolare importanza. Una macchina di deep learning compromessa non rappresenta soltanto un asset violato, ma può diventare il centro di ragionamento di un malware capace di coordinare attacchi successivi contro dispositivi meno potenti della stessa rete.

La rete FakeCorp usata per il proof-of-concept

I ricercatori costruiscono un ambiente sperimentale controllato denominato FakeCorp, progettato per simulare una rete aziendale realistica ma isolata. L’infrastruttura comprende 33 macchine virtuali, tra cui sistemi Linux, Windows Server, dispositivi IoT e cinque host designati come macchine GPU. Questa composizione permette di valutare la capacità del worm di muoversi tra sistemi operativi, servizi esposti e profili hardware differenti. L’obiettivo non è dimostrare una singola catena di exploit, ma verificare se un agente AI possa adattare il proprio comportamento a una rete complessa, con vulnerabilità distribuite, configurazioni diverse e risorse computazionali non uniformi.

La scelta di creare un ambiente dedicato risponde anche a esigenze di sicurezza della ricerca: un worm auto-replicante non può essere testato in reti reali o connessi a Internet senza rischi di fuoriuscita. FakeCorp diventa quindi un laboratorio realistico ma contenuto, nel quale misurare propagazione, fallimenti, generazioni di replica e capacità di sfruttare vulnerabilità note o appena divulgate.

Come funziona l’auto-replicazione agentica

Il worm AI opera attraverso un’architettura agentica distribuita. Una volta ottenuto accesso elevato su un host, il sistema prepara una copia del proprio codice, installa le dipendenze necessarie e avvia una nuova istanza operativa. Quando il target compromesso dispone di GPU, il worm può distribuire una copia completa del modello linguistico e trasformare la macchina in un nuovo nodo di ragionamento. Quando invece il dispositivo ha capacità limitate, come nel caso di alcuni host IoT o sistemi meno potenti, la replica può inoltrare le richieste di inferenza verso un nodo superiore già compromesso.

Questa architettura a livelli consente al worm di propagarsi anche in ambienti eterogenei, senza pretendere che ogni macchina ospiti autonomamente l’intero modello. Il comportamento ricorda una rete di comando distribuita, ma con una differenza sostanziale: il motore decisionale non è un server centrale controllato dall’attaccante, bensì una catena di agenti che sfruttano risorse interne alla rete vittima. Questa impostazione aumenta la resilienza del malware e riduce la dipendenza da infrastrutture esterne facilmente bloccabili.

Un agente che ragiona sui target invece di seguire script fissi

A differenza dei worm storici, il proof-of-concept non si limita a eseguire una lista rigida di exploit. L’agente esegue scansioni, enumera servizi, formula ipotesi sulle vulnerabilità presenti, consulta informazioni disponibili e genera strategie di attacco coerenti con il target osservato. Quando un tentativo fallisce, analizza l’errore, classifica il problema e modifica la strategia successiva. Questo comportamento rende l’attacco più flessibile rispetto ai malware tradizionali basati su routine fisse. Un worm classico può essere fermato patchando la vulnerabilità specifica che sfrutta; un worm agentico può cercare alternative, adattarsi alle configurazioni e costruire nuove catene operative. Il paper sottolinea proprio questa trasformazione: il codice fisso diventa meno importante della capacità del sistema di ragionare e sintetizzare logica d’attacco in tempo reale. Per i difensori, ciò significa che il rilevamento non può basarsi solo su indicatori statici o firme di exploit già noti, ma deve osservare comportamenti, sequenze operative e uso anomalo delle risorse.

I risultati degli esperimenti su FakeCorp

Nei 15 esperimenti indipendenti condotti su FakeCorp, il worm identifica in media 31,3 vulnerabilità, ottiene accesso elevato su 23,1 host e riesce a replicarsi su 20,4 macchine. Il tasso di replica sugli host compromessi raggiunge l’88%, mentre la copertura della rete complessiva si attesta intorno al 62%. In alcuni run la propagazione raggiunge circa 30 host entro 44 ore, mentre la profondità media dell’albero di infezione arriva a 5,1 generazioni, con picchi di sette.

Questi numeri indicano che il sistema non produce soltanto compromissioni isolate, ma riesce a costruire percorsi multi-generazionali attraverso host diversi. Il tasso di successo degli exploit tentati si colloca intorno al 44%, con fallimenti dovuti soprattutto a errori di sintassi, payload incompleti o stati corrotti dei target, più che a incapacità generale di ragionamento. Gli exploit locali Linux e alcune escalation risultano più affidabili, mentre le catene web e le escalation Windows mostrano maggiori difficoltà.

Le vulnerabilità sfruttate nel test

L’ambiente FakeCorp include vulnerabilità realistiche spesso osservate in reti aziendali. Il worm opera su servizi e sistemi esposti che simulano scenari concreti, includendo vulnerabilità storiche e configurazioni deboli. Tra i casi citati figurano famiglie note come SambaCry, Dirty Pipe, PrintNightmare, Drupalgeddon 2, vulnerabilità in Exim e iniezioni SQL. La ricerca non descrive il worm come un semplice archivio di exploit, ma come un sistema capace di combinare informazioni, stato del target e ragionamento generativo. Il punto critico è la capacità di adattare l’attacco al contesto, usando vulnerabilità disponibili quando presenti e cercando alternative quando una catena non produce risultato. Questo modello rappresenta una minaccia più dinamica rispetto ai malware preconfezionati, perché riduce il valore difensivo di una singola patch e aumenta l’importanza della riduzione complessiva della superficie esposta.

Il caso delle CVE post-cutoff

Uno degli elementi più preoccupanti riguarda lo sfruttamento di vulnerabilità divulgate dopo il cutoff di addestramento del modello. Il worm riesce a usare advisory pubblici a runtime per generare catene di attacco anche su CVE che il modello non poteva conoscere durante il training. Nel paper vengono citati casi come CVE-2026-39987 su Marimo, CVE-2026-31431 CopyFail e varianti DirtyFrag. L’agente legge la descrizione pubblica della vulnerabilità, interpreta le condizioni di sfruttamento e tenta di costruire un payload coerente. Questa capacità riduce drasticamente la finestra utile per la difesa. Quando un advisory viene pubblicato, non serve più attendere che un attaccante umano trasformi manualmente la descrizione in codice operativo: un sistema agentico può accelerare il processo di weaponization. Per i team di sicurezza, la conseguenza è chiara: ogni nuova divulgazione deve essere trattata come un rischio potenzialmente sfruttabile in ore, non in settimane.

GPU compromesse come infrastruttura di attacco

L’architettura del worm evidenzia un rischio specifico per organizzazioni che dispongono di server GPU. In molti ambienti, queste macchine sono trattate come risorse specialistiche destinate a ricerca, data science, training o inferenza, ma non sempre vengono segmentate con la stessa severità dei sistemi critici tradizionali. Il proof-of-concept mostra invece che un host GPU compromesso può diventare un acceleratore dell’attacco. Una volta installato il modello locale, la macchina può servire richieste di inferenza per altri nodi e sostenere la propagazione verso dispositivi meno potenti. Nei test separati di replica full-GPU, il successo raggiunge il 68,8%, mentre sale al 93,8% quando si esclude la fase di deploy dell’API locale. Questo indica che la parte più fragile resta la preparazione dell’ambiente, non la logica generale di propagazione. Per le aziende, i cluster AI e le workstation con GPU devono quindi essere considerati asset ad alto rischio anche dal punto di vista offensivo: se violati, possono fornire al malware la capacità cognitiva necessaria per espandersi.

La differenza rispetto a WannaCry e NotPetya

Il confronto con worm storici come WannaCry e NotPetya aiuta a comprendere la portata del cambiamento. Quegli attacchi si basavano su exploit specifici e su logiche di propagazione predefinite. Una volta identificata la vulnerabilità centrale, patch e blocchi mirati potevano ridurre drasticamente la diffusione. Un worm AI adattivo modifica questo equilibrio. Non dipende da un’unica falla, non segue una sola strada e non deve necessariamente comportarsi allo stesso modo su ogni host. Può valutare il target, scegliere una tecnica diversa, sfruttare configurazioni deboli, riutilizzare credenziali o tentare escalation alternative. La minaccia non è più definita soltanto dal codice che trasporta, ma dalla capacità di costruire codice, decisioni e strategie mentre si propaga. Questo rende più difficile prevedere tutti i percorsi possibili e aumenta il valore della difesa in profondità, della segmentazione e del monitoraggio comportamentale.

Le differenze rispetto agli attacchi AI precedenti

La ricerca si distingue anche da lavori precedenti su worm basati su AI o prompt auto-replicanti. Alcuni studi avevano mostrato la possibilità di propagare istruzioni malevole tra assistenti AI, email o ecosistemi di agenti. In quei casi, però, l’LLM era spesso il bersaglio o il mezzo di trasmissione del prompt. Nel lavoro di Toronto, invece, l’LLM diventa il motore operativo dell’attacco contro infrastrutture di rete ordinarie. Il worm non si limita a infettare altri agenti AI, ma compromette host Linux, Windows, dispositivi IoT e sistemi aziendali simulati. Questo spostamento è cruciale perché collega la sicurezza dei modelli alla sicurezza delle reti tradizionali. La minaccia non riguarda solo ambienti in cui agenti AI comunicano tra loro, ma qualsiasi infrastruttura che ospiti servizi vulnerabili e risorse computazionali sfruttabili.

Un nuovo modello economico per gli attaccanti

L’uso di LLM locali su risorse compromesse crea un’asimmetria economica rilevante. Gli attacchi basati su AI possono essere costosi quando dipendono da modelli commerciali, token, API e infrastruttura cloud. Questo costo può limitare la scala delle operazioni e introdurre punti di controllo esterni. Nel proof-of-concept di Toronto, invece, il costo viene trasferito alla vittima. Una volta catturato un host con GPU, l’attaccante dispone di potenza di inferenza gratuita per pianificare ulteriori compromissioni. Questo modello riduce le barriere operative e rende la propagazione potenzialmente più sostenibile nel tempo. Inoltre, l’assenza di API esterne riduce la visibilità dei provider e impedisce interventi centralizzati come sospensione delle chiavi, blocchi sugli account o filtri di sicurezza applicati dal fornitore del modello. La minaccia diventa quindi più autonoma, più distribuita e più difficile da interrompere con strumenti tradizionali.

Le implicazioni per i difensori

Per i team di sicurezza, il paper suggerisce una revisione urgente delle priorità difensive. Le macchine GPU devono essere segmentate e monitorate come infrastrutture critiche, non come semplici asset di calcolo. Le reti flat diventano particolarmente pericolose perché consentono a un singolo nodo compromesso di raggiungere molti sistemi laterali. Le credenziali amministrative riutilizzate rappresentano un acceleratore della propagazione e devono essere eliminate attraverso rotazione, vaulting e controlli di accesso granulari. Anche la pubblicazione di nuovi advisory deve essere trattata come evento operativo immediato: se un agente può convertirli rapidamente in catene di attacco, il tempo tra disclosure e sfruttamento si restringe. Le difese devono quindi puntare su segmentazione, zero-trust, logging centralizzato, controllo delle attività anomale e limitazione delle capacità di installare o eseguire infrastrutture di inferenza non autorizzate sugli endpoint.

I segnali comportamentali da monitorare

I ricercatori indicano alcune classi di segnali utili per rilevare comportamenti compatibili con un worm AI. Tra questi rientrano attività su porte non standard, avvio inatteso di server di inferenza, installazione automatica di dipendenze AI, aggiunta non autorizzata di chiavi SSH pubbliche, connessioni anomale tra host interni e pattern di scansione seguiti da tentativi di escalation. Un altro indicatore riguarda l’uso di GPU da parte di processi non previsti o su host che non dovrebbero eseguire workload di inferenza. In ambienti enterprise, questi eventi possono essere integrati in regole di detection e correlati con sistemi EDR, SIEM e strumenti di network monitoring. Il problema è che un worm agentico può modificare parte del proprio comportamento, rendendo insufficienti regole troppo rigide. Per questo la difesa deve concentrarsi su anomalie strutturali e sequenze operative, non soltanto su hash, nomi di file o firme statiche.

Le limitazioni dichiarate dal proof-of-concept

Il prototipo dei ricercatori evita deliberatamente alcune funzionalità tipiche del malware reale, come stealth avanzato, persistenza robusta, crittografia operativa, polimorfismo o tecniche di evasione sofisticate. Questa scelta serve a mantenere il sistema analizzabile e contenibile. Anche la replica su GPU mostra fragilità legate a dipendenze, configurazioni e stati dei target. Alcuni fallimenti derivano da errori del modello, bias di ragionamento o catene generate in modo incompleto. Queste limitazioni riducono il rischio immediato del proof-of-concept, ma non sminuiscono la dimostrazione principale: un agente AI locale può sostenere un ciclo autonomo di scansione, compromissione, escalation e replica. Con modelli più robusti, migliori strumenti di orchestrazione e maggiore ingegnerizzazione, capacità simili potrebbero diventare più affidabili.

Perché la ricerca non va letta come semplice allarme

Il lavoro dell’Università di Toronto non deve essere interpretato come una ricetta operativa per attaccanti, ma come un avvertimento scientifico alla comunità di sicurezza. I ricercatori scelgono un ambiente isolato, evitano di rilasciare capacità stealth e discutono le implicazioni difensive. Il valore principale del paper sta nel mostrare in anticipo una traiettoria plausibile: l’unione tra agenti AI, modelli open-weight, vulnerabilità pubbliche e risorse GPU compromesse può cambiare il ciclo di vita dei worm. Prepararsi ora permette di definire standard, ambienti di test sicuri, procedure di disclosure e contromisure prima che versioni più mature emergano in contesti ostili. Come accaduto in passato con altre classi di malware, la ricerca controllata può aiutare i difensori a comprendere la minaccia prima che diventi diffusa.

Una nuova fase per la sicurezza cibernetica

Il verme AI auto-replicante sviluppato dai ricercatori di Toronto segna una nuova fase nella sicurezza cibernetica. La minaccia non è più soltanto codice che esegue istruzioni predefinite, ma un sistema capace di ragionare, adattarsi, sfruttare risorse rubate e costruire strategie in tempo reale. La disponibilità di modelli open-weight locali rende questo scenario più accessibile, mentre la diffusione di infrastrutture GPU nelle aziende offre potenziali punti di accelerazione. Per i difensori, la risposta passa da segmentazione, controllo delle credenziali, isolamento dei cluster AI, monitoraggio dei workload di inferenza e patching molto più rapido delle vulnerabilità appena pubblicate. Il messaggio finale del paper è netto: gli avversari generativi non sono definiti da un exploit fisso, ma dalla capacità di sintetizzare nuovi percorsi d’attacco. La sicurezza delle reti dovrà evolvere di conseguenza.