Mettere in sicurezza la tua infrastruttura AI prima che NadMesh svuoti i tuoi account cloud

Una strategia di difesa aziendale multimilionaria spesso crolla sotto il peso di un singolo container non autenticato. L'ho visto in prima persona lo scorso trimestre durante l'audit di un laboratorio di ricerca che aveva trascorso sei mesi a blindare i propri cluster Kubernetes, ma aveva lasciato un'istanza ComfyUI aperta per una demo nel fine settimana. Quella singola porta esposta sulla 8188 è stata sufficiente per bypassare ogni policy di rete che avevano messo in atto. La botnet NadMesh, scoperta all'inizio di luglio 2026, vive esattamente in quel divario tra gli standard di sicurezza aziendali e il ritmo frenetico del deployment dell'IA.

NadMesh è una famiglia di malware basata su Go che dà priorità all'identità rispetto alla potenza di calcolo pura. Mentre le botnet precedenti si concentravano sul dirottamento delle GPU per il mining di Monero, gli operatori dietro NadMesh comprendono che un segreto AWS rubato è più prezioso di qualche migliaio di hash al secondo. XLab di QiAnXin ha pubblicato venerdì un rapporto che descrive in dettaglio come questa botnet dia la caccia ai generatori di immagini, ai runner di modelli locali e ai costruttori di workflow che i team di ingegneria configurano rapidamente e proteggono con firewall troppo tardi.

Il costo architettonico della corsa all'oro dell'IA

Esiste un paradosso fondamentale nel moderno deployment dell'IA. Le organizzazioni investono pesantemente in ruoli IAM cloud e storage crittografato, eppure permettono agli sviluppatori di eseguire strumenti non autenticati come Ollama o n8n direttamente su internet pubblico. NadMesh sfrutta questa mancanza di attrito. La botnet utilizza un harvester Shodan per mantenere la sua coda di scansione rifornita di bersagli che eseguono ComfyUI, Open WebUI, Langflow e Gradio. Questi sono gli strumenti del moderno stack IA e raramente sono protetti di default.

Recentemente ho analizzato una cattura in cui uno sviluppatore ha distribuito un notebook Marimo per testare un nuovo modello. Hanno ignorato gli avvisi di sicurezza perché ne avevano bisogno solo per un'ora. Entro venti minuti, un bot NadMesh aveva scansionato l'IP, identificato il servizio e tentato un exploit. Questa velocità è possibile perché la botnet tratta internet come un database consultabile piuttosto che come un vasto territorio in cui vagare. Le subnet che producono colpi andati a segno vengono campionate nuovamente ogni cinque minuti. Se un bersaglio viene contrassegnato come pericoloso, la botnet ritorna ogni quindici minuti per eseguire prima una scansione ad alta priorità delle porte specifiche per l'IA.

Come l'harvester alimenta la coda

La logica di scansione è persistente. Una scansione completa riporta in cima alla coda ogni IP contrassegnato come pericoloso negli ultimi sette giorni. L'autore sa chiaramente che ricercatori e honeypot stanno osservando. Se un bersaglio assorbe dieci tentativi di deployment senza restituire un risultato, la botnet lo inserisce automaticamente in blacklist. Ciò impedisce alla flotta di sprecare risorse su esche. Quando la coda si esaurisce, i bot generano una subnet /24 casuale e continuano la caccia.

Entro la seconda settimana di luglio, gli IP sorgente distinti che diffondevano NadMesh sono aumentati verticalmente. XLab ha registrato un salto del conteggio da quasi zero a circa 139 al giorno. La dashboard dell'operatore, catturata il 10 luglio, rivendica un bottino di 3.811 chiavi AWS uniche. Questa discrepanza tra il piccolo numero di bot attivi e l'enorme volume di credenziali rubate suggerisce un motore di automazione altamente efficiente. L'operatore non ha bisogno di una botnet massiccia se ogni infezione produce una master key per un ambiente cloud.

La vulnerabilità all'interno del Model Context Protocol

Il Model Context Protocol (MCP) è il vettore primario nell'elenco delle priorità del controller. L'MCP è uno standard che consente ai modelli di IA di richiamare strumenti esterni e accedere a fonti di dati. Per progettazione, la prima specifica dell'MCP ha posto l'autenticazione al di fuori del protocollo principale. Un flusso di autorizzazione esiste da marzo 2025, ma la specifica lo descrive come opzionale. Molti sviluppatori lo saltano per risparmiare tempo durante la configurazione.

Censys ha contato oltre 21.000 servizi MCP raggiungibili entro maggio 2026. Circa 90 di questi pubblicizzavano uno strumento chiamato execute_command. Questo strumento è esattamente la chiamata in cima alla tabella degli exploit di NadMesh. La botnet utilizza un JSON-RPC tools/call per attivare questo comando. Nessun CVE è associato a questa attività perché il software si comporta esattamente come configurato. Il problema non è un bug nel codice. Il problema è un protocollo che consente l'esecuzione di comandi non autenticati per impostazione predefinita.

Inventariare il modello e l'identità

Quando un bot compromette con successo un host, non si limita a installare un miner. Cataloga l'ambiente. Il feed di intelligence dietro la dashboard di NadMesh mostra inventari di modelli DeepSeek, GLM e Kimi. Questi inventari sono spesso contrassegnati con un identificatore ":cloud". Ciò indica che il bot sta guardando oltre la macchina locale e identificando a quali servizi IA remoti l'host può accedere.

Ciò che un bot invia alla base è l'identità dell'organizzazione. Estrae le chiavi cloud dalle variabili d'ambiente, estrae i token degli account di servizio Kubernetes e recupera i contenuti di ~/.aws/config. Prende di mira anche i file .env e ~/.docker/config.json. I ricercatori sono chiari sul movente. L'operatore cerca le credenziali cloud e i privilegi del cluster piuttosto che l'host stesso. In un'architettura moderna, l'host è un bene usa e getta, ma le credenziali forniscono un accesso persistente al piano dei dati.

Persistenza tramite tripla ridondanza

Rimuovere NadMesh da un sistema compromesso è difficile a causa dei suoi meccanismi di persistenza ridondanti. L'agente mantiene tre modi separati per sopravvivere a un riavvio. Se un amministratore trova ed elimina una voce, le altre due rimangono per scaricare una nuova copia del malware. È come cercare di spegnere un incendio che ha tre fonti di combustibile indipendenti. Ogni build del malware passa anche attraverso l'offuscamento Garble e l'impacchettamento UPX con padding casuale. Ciò significa che ogni agente ha un hash di file unico. Un team di sicurezza non può fare affidamento su un singolo hash per trovare le infezioni nella propria rete.

Cinque versioni build della botnet sono attualmente in circolazione. La più comune è 33.8-GO-TITAN. L'operatore utilizza un endpoint canary per testare le nuove build su una piccola fetta della flotta prima di un rilascio ampio. Questo è un livello di maturità DevOps che rispecchia le legittime software company che prendono di mira. Il successo per l'operatore viene misurato su una allowlist di risultati che esclude il raccolto di Ollama e AWS. Ciò suggerisce che il punteggio sulla dashboard mostri solo una frazione dell'operazione totale.

Azioni difensive per il perimetro esposto

La maggior parte di ciò che NadMesh lancia è mirato alle funzionalità di amministrazione lasciate richiamabili su internet pubblico. Ciò include API Docker aperte sulla porta 2375, console di script Jenkins e istanze Redis non autenticate. Nessuna patch chiude questi buchi perché sono scelte di configurazione. Per proteggere il tuo ambiente, devi spostare questi servizi dietro autenticazione o rimuoverli completamente da internet pubblico. Dai priorità alle quattro porte che il job di scansione di NadMesh mette al primo posto: 8188 (ComfyUI), 11434 (Ollama), 7860 (Gradio) e 5678 (n8n).

Esiste anche un breve elenco di vulnerabilità che richiedono una patch immediata. CVE-2026-39987 è un difetto di esecuzione di codice remoto pre-autenticazione nei notebook Marimo. La CISA lo ha aggiunto al catalogo delle vulnerabilità sfruttate note ad aprile. Anche CVE-2026-41176 è critico, poiché consente ai chiamanti non autenticati di attivare l'interruttore di autenticazione sui server RC rclone. Poiché le configurazioni di rclone spesso contengono credenziali cloud, questo è un bersaglio ad alta priorità per NadMesh.

Se trovi indicatori di compromissione, isola immediatamente l'host. Cerca file di persistenza in /etc/cron.d/.sys_monitor e file nascosti in /dev/shm/.a o /tmp/.a. Revocare le credenziali è l'unico percorso sicuro da seguire. Se un host è compromesso, presumi che ogni chiave AWS, token di cluster e file .env che ha toccato sia ora nelle mani dell'operatore. Ruotare le chiavi non è sufficiente se il malware è ancora presente per rubare quelle nuove. Devi eliminare la persistenza prima di emettere le sostituzioni. Controlla i tuoi log per attività dall'IP 209.99.186[.]235 o connessioni al dominio cdnorigin[.]net. L'obiettivo è verificare dove sono state utilizzate le identità rubate mentre erano attive.

Fonti: NIST Cybersecurity Framework, MITRE ATT&CK (Resource Development, Initial Access), QiAnXin XLab NadMesh Report, Censys MCP Census 2026.

Disclaimer: Questo articolo è solo a scopo informativo ed educativo e non sostituisce un audit di cybersecurity professionale o un servizio di risposta agli incidenti.