Tutti gli articoli

Notizie13 ottobre 20266 min di lettura

Anthropic: piccoli modelli IA verso l’autoreplicazione sull’IoT

Una ricerca di Anthropic mostra modelli IA open-weight che si installano su dispositivi IoT e si propagano in laboratorio. Dati, limiti e difese per le aziende.

Cerchi luminosi blu su sfondo scuro, come un’interfaccia digitale

Il Frontier Red Team di Anthropic ha pubblicato una ricerca sui cosiddetti «AI worm»: malware che porta con sé i pesi di un modello linguistico e lo esegue direttamente sui dispositivi compromessi, senza appoggiarsi a un data center. La conclusione dei ricercatori è che i piccoli modelli open-weight (30 miliardi di parametri o meno) potrebbero essere, a pochi mesi di distanza, abbastanza capaci da replicarsi da soli su dispositivi IoT commerciali come box TV Android economici o forni connessi.

La notizia è stata ripresa da SecurityWeek, Security Affairs, The Register, BleepingComputer, The Hacker News, Dark Reading e Ars Technica. Non si tratta di una minaccia in circolazione: nessun replicatore autonomo completo è stato osservato, né in laboratorio né in rete. Il valore della ricerca per chi difende è nei numeri sui singoli passaggi e nelle contromisure.

Cosa hanno misurato i ricercatori

Anthropic divide la replicazione in quattro fasi: trovare i bersagli, ottenere l’esecuzione di codice, avviare l’inferenza sul nuovo dispositivo e propagarsi ad altri host. Secondo Ars Technica, gli agenti avevano a disposizione strumenti comuni di sfruttamento, come le reverse shell.

  • Modello distribuito su hardware economico. Gemma4-26B-A4B, quantizzato e diviso in parti, è stato eseguito su 15 box TV Android senza marca (circa 55 dollari l’uno, 4 GB di memoria ciascuno). Funziona, ma a 0,39 token al secondo.
  • Avvio dell’inferenza su hardware sconosciuto. Qwen3.5-9B è riuscito a installare e configurare l’inferenza di Llama3.1-8B su 8 dei 9 tipi di hardware provati, da una Jetson Nano a un Mac. È la fase che Anthropic considera meno studiata e più difficile: scegliere il software compatibile, installare le dipendenze, correggere errori specifici della piattaforma.
  • Ciclo completo. Su una rete chiusa di otto dispositivi Android emulati (istanze cloud con emulatore Android 15, secondo The Register), solo GLM-5.2 ha completato la replicazione da zero, propagando Llama3.1-8B a tutti gli otto nodi in 4 prove su 5 (sette su otto nella quinta). Gli altri modelli open-weight provati falliscono in modo sistematico; The Register nota che il rapporto non dice quanti fossero.
  • Apprendimento tra generazioni. Ogni copia lascia alla successiva note su cosa ha provato e cosa non ha funzionato. Il successo di Qwen3.5-9B in un compito di configurazione è salito dal 45% iniziale a valori tra il 61% e l’84% in sei generazioni. Affiancargli un modello più potente come consigliere (Opus 4.8) non ha dato miglioramenti misurabili.

I tempi restano lunghi: per l’avvio dell’inferenza BleepingComputer riporta 28–51 ore con Qwen3.5-9B (29–51 secondo Ars Technica) e 71–150 ore con Gemma4-26B-A4B. Il tempo di raddoppio stimato è di giorni; Mirai, nel 2016, raddoppiava in circa un’ora.

I limiti dello studio

Le fonti concordano su alcuni punti che ridimensionano il risultato:

  • lo sfruttamento è stato reso banale: i bersagli esponevano ADB (Android Debug Bridge) senza autenticazione. Anthropic considera i risultati un limite superiore rispetto al mondo reale e rimanda a studi precedenti per la capacità dei piccoli modelli di sfruttare vulnerabilità;
  • la replicazione completa è riuscita solo con GLM-5.2, che orchestrava il processo mentre sui bersagli girava un modello più piccolo;
  • secondo The Register era coinvolto anche un ambiente di lavoro costruito apposta, chiamato Memento.

The Register è la testata più critica e parla di una minaccia che ancora non esiste. Su Ars Technica il ricercatore Xiaohan Fu osserva che lo studio non dimostra che un modello sceglierebbe da solo di replicarsi, e chiede di pubblicare prompt e configurazioni per renderlo riproducibile.

La proiezione di Anthropic è condizionata: se i piccoli modelli continuano a migliorare al ritmo storico, raggiungeranno il livello di GLM-5.2 entro la fine del 2026, e i replicatori basati sui pesi «potrebbero essere possibili poco dopo».

Perché conta per chi difende

La differenza rispetto alle botnet tradizionali è l’adattabilità. Mirai e Kimwolf (oltre due milioni di dispositivi infettati, soprattutto box TV Android) sono scritte per tipi di dispositivo ed exploit precisi; un agente IA, secondo Anthropic, può capire da solo un hardware che non conosce. Secondo Ars Technica i pesi potrebbero viaggiare con il malware o essere riscaricati da un hub pubblico di modelli, e diventare parte del payload.

Le stesse caratteristiche lo rendono però visibile. Secondo il calcolo riportato da SecurityWeek, una botnet grande come Kimwolf ospiterebbe circa 133.000 copie del modello da 26 miliardi di parametri, con una potenza complessiva pari al massimo a circa 40 GPU Nvidia H100. E spostare file di più gigabyte tra dispositivi che di norma non si parlano lascia tracce.

Impatto per le aziende europee e italiane

Box TV, schermi delle sale riunioni, telecamere, elettrodomestici connessi: in molte aziende sono sulla stessa rete dei computer, spesso con credenziali di fabbrica. È lo stesso perimetro sfruttato oggi dalle botnet IoT classiche, e la ricerca non cambia le priorità: semmai ne aumenta l’urgenza.

Per i soggetti NIS2, l’articolo 21 chiede gestione degli asset, delle vulnerabilità e della sicurezza nella catena di fornitura: i dispositivi IoT non gestiti rientrano nel perimetro. Anthropic indica come leva di lungo periodo produttori e regolatori (niente password predefinite, aggiornamenti obbligatori del firmware, certificazioni più severe) e cita il Regno Unito, che ha già vietato le password predefinite sui dispositivi IoT. Nell’Unione europea va nella stessa direzione il Cyber Resilience Act, che tra i requisiti essenziali mette la configurazione sicura come impostazione predefinita.

Cosa fare subito

  1. Fai l’inventario dei dispositivi IoT e consumer sulle reti aziendali, compresi box TV e dispositivi portati da fornitori o dipendenti. Togli quelli senza marca o senza aggiornamenti.
  2. Chiudi ADB di rete (di solito sulla porta TCP 5555) e verifica che non sia raggiungibile né da Internet né dalla rete interna.
  3. Cambia le credenziali di fabbrica e disattiva Telnet e gli altri servizi di gestione non usati.
  4. Segmenta: dispositivi IoT in una rete separata, senza traffico verso i server e, dove possibile, nemmeno tra di loro.
  5. Filtra il traffico in uscita dell’IoT, consentendo solo le destinazioni necessarie, compresi i download da hub pubblici di modelli.
  6. Cerca le anomalie indicate dalla ricerca: trasferimenti di file di grandi dimensioni verso o da dispositivi IoT, traffico continuo tra dispositivi che non comunicano di solito, scansioni partite da un dispositivo IoT.
  7. Prevedi la quarantena: nella bonifica di Mirai citata da Anthropic, isolare gli abbonati infetti e guidarli nella pulizia ha eliminato il 92% delle infezioni in 14 giorni, contro il 74% senza avviso.

Come aiuta ARXDOME

ARX Watch trova sulla rete i dispositivi senza sonda, come box TV, telecamere e stampanti, ascoltando le richieste DHCP e le tabelle dei vicini, e avvisa quando ne compare uno nuovo. ARX Expose mostra dall’esterno le porte aperte e i servizi esposti per errore, come un ADB raggiungibile da Internet. ARX Sentry porta i log dei firewall nelle pagine del SOC e nella mappa del NOC, con le connessioni rifiutate e il traffico in uscita bloccato, anche quello dei dispositivi IoT.

Ultimo aggiornamento:

Hai domande?

Parliamo delle esigenze della tua azienda, senza impegno.

Contattaci

Articoli correlati