La botnet NadMesh buca i server esposti (Ollama, ComfyUI) e fa strage di chiavi AWS

🛡️ Executive Summary

• NadMesh cerca servizi AI e piattaforme di automazione esposte, privilegiando endpoint MCP capaci di eseguire comandi senza adeguata autenticazione.
• Dopo l’accesso raccoglie chiavi AWS, token Kubernetes, credenziali Docker, file .env e informazioni sui modelli presenti nell’ambiente.
• Offuscamento, build con hash differenti e scansione adattiva rendono insufficienti le sole firme statiche e impongono controlli comportamentali.

Una nuova botnet sviluppata in Go sta scandagliando Internet alla ricerca di servizi AI self-hosted lasciati senza autenticazione o configurati con privilegi eccessivi. NadMesh, individuata da QiAnXin XLab all’inizio di luglio 2026, prende di mira ComfyUI, Ollama, Gradio, n8n e implementazioni del Model Context Protocol, ma estende i tentativi anche a Docker, Jenkins, Redis e Telnet. L’obiettivo principale non è utilizzare la potenza di calcolo per il cryptomining, bensì sottrarre chiavi AWS, token Kubernetes, credenziali Docker e inventari dei modelli. La minaccia sfrutta la velocità con cui laboratori e team di sviluppo pubblicano interfacce AI sperimentali senza applicare gli stessi controlli riservati alle applicazioni di produzione.

NadMesh trasforma i servizi AI self-hosted in punti di accesso al cloud

Il nome NadMesh deriva dalla stringa n4d mesh controller individuata nel codice. Il malware è compilato in Go, offuscato attraverso Garble e compresso con UPX. Ogni build riceve inoltre una quantità casuale di dati di riempimento, così che campioni funzionalmente identici producano hash differenti. Questa scelta complica il rilevamento basato su indicatori statici e permette agli operatori di distribuire numerose varianti senza modificare la logica centrale. La botnet non considera i servizi AI come un obiettivo isolato, ma come una porta verso l’ambiente più ampio nel quale sono eseguiti. Un’istanza Ollama o ComfyUI può condividere variabili d’ambiente, volumi Docker, file .env, directory utente e credenziali con applicazioni cloud o pipeline interne. Una compromissione apparentemente limitata a un’interfaccia per l’inferenza può quindi esporre account AWS, cluster Kubernetes e registry privati. Il rischio era già emerso nel caso del nodo malevolo di ComfyUI progettato per il furto di dati, ma NadMesh industrializza il processo attraverso una scansione continua e automatizzata dell’intera superficie pubblica.

La scansione adattiva combina Shodan e intervalli IP casuali

NadMesh mantiene una coda di indirizzi ottenuti da Shodan, utilizzando le informazioni già indicizzate per individuare host che espongono servizi e porte riconducibili agli strumenti AI. Quando la coda si esaurisce, il bot genera range IP casuali e continua l’esplorazione senza dipendere da una singola fonte. Il meccanismo non tratta tutti gli indirizzi allo stesso modo: le subnet nelle quali vengono trovati servizi vulnerabili o configurazioni interessanti vengono ricontrollate più frequentemente, mentre gli IP considerati promettenti ricevono una priorità superiore sulle porte associate all’intelligenza artificiale. Questo approccio adattivo trasforma la botnet in un sistema di discovery che apprende dalla distribuzione dei bersagli. Gli operatori possono concentrare le risorse dove la probabilità di ottenere credenziali è più elevata, evitando di consumare tempo su intervalli poco produttivi. La dashboard osservata dai ricercatori mostra centinaia di indirizzi impegnati ogni giorno nella distribuzione del malware e un volume crescente di scansioni, indice di una campagna già strutturata e non di una semplice sperimentazione.

Gli endpoint MCP con execute_command sono il bersaglio prioritario

Il primo vettore tentato dalla botnet riguarda i server MCP che espongono il comando execute_command attraverso JSON-RPC. Il Model Context Protocol permette agli agenti AI di collegarsi a strumenti, filesystem, database e servizi esterni, ma un server pubblicato senza autenticazione può trasformare una funzione operativa in un endpoint di esecuzione remota. NadMesh invia richieste progettate per verificare se il comando sia disponibile e, in caso positivo, lo utilizza per avviare shell, scaricare il payload e ispezionare l’ambiente. Il problema non è intrinseco al protocollo: nasce dalla combinazione tra strumenti ad alto privilegio, assenza di controllo dell’identità e pubblicazione su Internet. Matrice Digitale aveva già evidenziato il rischio nel caso del tool poisoning contro server MCP e agenti AI, dove un componente apparentemente legittimo poteva manipolare istruzioni ed esfiltrare informazioni. NadMesh compie un passo differente ma complementare: non tenta di ingannare il modello, bensì cerca direttamente implementazioni MCP che consentono a un soggetto remoto di impartire comandi al sistema operativo.

Docker e Jenkins ampliano l’attacco oltre il perimetro AI

Se il vettore MCP non produce risultati, la botnet prova altre superfici frequentemente presenti negli stessi ambienti di sviluppo. Il traffico osservato indica docker_containers_api_rce come tecnica più utilizzata, seguita da jenkins_scripttext_rce. Un’API Docker accessibile senza autenticazione può permettere di creare container privilegiati, montare directory dell’host e leggere il filesystem sottostante. Jenkins può invece esporre console o endpoint capaci di eseguire script nel contesto del server di automazione. NadMesh tenta inoltre password Telnet deboli e accessi a Redis, ampliando il numero di sistemi potenzialmente reclutabili. Questa pluralità di vettori dimostra che la botnet non dipende da una singola vulnerabilità zero-day: sfrutta soprattutto servizi amministrativi e di sviluppo esposti per errore, configurazioni predefinite e interfacce nate per reti fidate. Gli ambienti AI risultano particolarmente vulnerabili perché spesso vengono creati come proof-of-concept, pubblicati temporaneamente per una demo e poi lasciati raggiungibili più a lungo del previsto.

Il malware cerca chiavi AWS, file .env e token Kubernetes

Dopo aver ottenuto l’esecuzione, NadMesh analizza variabili d’ambiente e file di configurazione alla ricerca di materiale riutilizzabile. Tra i percorsi controllati figurano directory AWS, file .env, configurazioni Docker e token montati nei container. Le chiavi AWS possono consentire l’accesso a storage, database, funzioni serverless e risorse di calcolo, in base alle policy assegnate all’identità compromessa. I token dei service account Kubernetes possono permettere di interrogare l’API del cluster, leggere secret o distribuire nuovi workload quando risultano associati a ruoli eccessivamente permissivi. Il file /.docker/config.json può contenere credenziali per registry pubblici o privati, aprendo la strada al furto di immagini o alla compromissione della supply chain. La dashboard dell’operatore avrebbe già registrato migliaia di chiavi AWS uniche, dato che conferma come l’obiettivo economico e operativo principale sia il credential harvesting. L’attività richiama il fenomeno del LLMjacking basato su credenziali cloud rubate, ma NadMesh non si limita ad abusare delle API dei modelli: costruisce un inventario più ampio delle risorse e delle identità disponibili.

Gli inventari dei modelli rivelano valore e struttura dell’ambiente

Oltre ai segreti di autenticazione, NadMesh cataloga i modelli installati o configurati sui sistemi raggiunti. Tra i nomi osservati compaiono DeepSeek, GLM e Kimi, inclusi riferimenti a modelli forniti attraverso servizi cloud. Questa raccolta permette agli operatori di capire se il bersaglio dispone di GPU, endpoint a pagamento, account con credito disponibile o applicazioni collegate a dati aziendali. L’inventario può essere usato per selezionare le macchine da monetizzare, individuare infrastrutture di interesse o preparare ulteriori abusi. Un server Ollama con modelli locali può indicare la presenza di hardware accelerato; un workflow n8n collegato a provider esterni può contenere token per email, database e CRM; un ambiente Gradio può esporre funzioni personalizzate con accesso a filesystem o repository. La botnet tratta quindi l’infrastruttura AI come una mappa delle capacità tecnologiche dell’organizzazione, non soltanto come una fonte di chiavi.

SSH, cron e directory temporanee garantiscono la persistenza

NadMesh inserisce chiavi pubbliche controllate dall’attaccante nei file ~/.ssh/authorized_keys, ottenendo un accesso che può sopravvivere alla rimozione del processo iniziale. Crea inoltre job in /etc/cron.d/ e deposita componenti nascosti in /dev/shm, /var/tmp e /tmp. L’uso di /dev/shm permette di eseguire file da un’area di memoria temporanea, mentre le directory /tmp e /var/tmp sono spesso scrivibili e meno controllate rispetto ai percorsi di sistema. La combinazione di più meccanismi indica che gli operatori prevedono tentativi di pulizia e vogliono mantenere almeno un canale di rientro. Il controller dispone anche di un endpoint canary utilizzato per verificare nuove build prima della distribuzione estesa. Questo elemento rivela una gestione organizzata del ciclo di sviluppo: il gruppo testa i campioni, controlla che comunichino correttamente e solo in seguito li distribuisce su larga scala. L’offuscamento con Garble, la compressione e il padding casuale completano una strategia pensata per ridurre l’efficacia delle firme e allungare il tempo necessario all’analisi.

Le porte AI pubbliche devono essere trattate come interfacce amministrative

Le organizzazioni devono verificare l’esposizione delle porte 8188 per ComfyUI, 11434 per Ollama, 7860 per Gradio e 5678 per n8n, senza limitarsi a cercare queste sole combinazioni. Molti servizi possono essere pubblicati su porte differenti, dietro reverse proxy o attraverso tunnel temporanei. Qualsiasi interfaccia capace di eseguire workflow, caricare nodi, accedere al filesystem o richiamare strumenti deve essere considerata equivalente a un pannello amministrativo. L’accesso pubblico dovrebbe essere eliminato quando non indispensabile; in caso contrario servono autenticazione forte, restrizioni IP, proxy con controllo dell’identità e logging completo. Gli endpoint MCP devono applicare autorizzazioni per singolo tool e non esporre funzioni generiche di shell. I container devono essere eseguiti senza privilegi, con filesystem ridotti e secret forniti attraverso sistemi dedicati anziché variabili permanenti. La separazione tra ambiente AI e credenziali cloud riduce l’impatto anche quando un servizio viene compromesso.

Gli indicatori di rete vanno accompagnati dalla rotazione dei segreti

Il traffico verso 209.99.186.235 e il dominio cdnorigin.net deve essere investigato, insieme alla comparsa di file sospetti nei percorsi temporanei, nuove chiavi SSH e cron job non autorizzati. Tuttavia, la rimozione del malware non è sufficiente quando NadMesh ha già letto le credenziali. Tutte le chiavi AWS presenti sull’host devono essere revocate e sostituite, verificando in CloudTrail le operazioni eseguite dall’identità compromessa. I token Kubernetes devono essere invalidati e i service account riesaminati, mentre le credenziali Docker richiedono la rotazione e il controllo degli accessi ai registry. È opportuno verificare anche file .env, webhook, API key dei provider AI e segreti collegati ai workflow n8n. Le organizzazioni che hanno esposto tool come LiteLLM o componenti simili dovrebbero applicare lo stesso approccio, considerando le criticità già emerse con le vulnerabilità in LiteLLM che esponevano servizi AI e ambienti hosting.

NadMesh sfrutta il divario tra velocità dell’AI e disciplina infrastrutturale

La campagna mostra un paradosso ormai evidente: gli strumenti AI vengono distribuiti con enorme rapidità, ma spesso senza la maturità operativa riservata a database, VPN e console cloud. Un’interfaccia nata per testare un modello viene esposta su Internet, un container eredita le credenziali dell’host e un server MCP riceve strumenti capaci di eseguire comandi generici. NadMesh non ha bisogno di inventare una nuova classe di exploit per approfittarne. Automatizza la ricerca, prova più vettori e raccoglie tutto ciò che consente di spostare l’attacco dal servizio AI al cloud sottostante. La difesa richiede quindi un cambio di classificazione: ComfyUI, Ollama, Gradio, n8n e MCP non sono semplici strumenti di produttività, ma componenti infrastrutturali che possono custodire privilegi, dati e accessi critici. Pubblicarli senza autenticazione equivale a esporre una console amministrativa connessa direttamente ai segreti dell’organizzazione.