Doorway, botnet IoT con 59 exploit e 11.363 reclutamenti in un’ora

🛡️ Executive Summary

• CloudSEK scopre 41 GB di dati operativi della botnet Doorway: il materiale contiene un motore Rust da circa 21.870 righe di codice, 59 moduli di exploit, credenziali e registri delle compromissioni.
• Migliaia di dispositivi coinvolti: i log documentano 4.217 IP distinti associati a eventi di reclutamento e 7.369 autenticazioni MikroTik riuscite. Un registro degli operatori riporta 11.363 join e 58.920 download in un’ora.
• Router, telecamere e server diventano infrastrutture proxy: Doorway combina vulnerabilità note, credenziali riutilizzate, loader multipiattaforma e controllo automatizzato delle campagne, con evidenze anche su Openfire e Jenkins.

Doorway è una botnet progettata per compromettere router, telecamere IP, apparati degli operatori telefonici e server aziendali, utilizzando un’infrastruttura di attacco modulare capace di operare su dispositivi e architetture differenti. Un’indagine di CloudSEK, pubblicata il 28 ottobre 2026, ha ricostruito l’operazione attraverso 41 GB di dati esposti in due ambienti di distribuzione accessibili pubblicamente. Il materiale comprende 59 moduli di exploit, database di credenziali, codice sorgente Rust, malware multipiattaforma e registrazioni delle attività offensive. Gli operatori dichiarano 11.363 reclutamenti e 58.920 download di payload in una finestra di sessanta minuti, mentre altre evidenze documentano compromissioni di dispositivi MikroTik e servizi Java. La ricerca descrive un’organizzazione capace di misurare i risultati, modificare automaticamente le priorità e trasformare i sistemi esposti in una potenziale infrastruttura globale di proxy.

Doorway scoperta attraverso 41 GB di codice, credenziali e registri operativi

L’indagine The Doorway Botnet: Inside a Large-Scale IoT and Network Device Compromise Campaign, condotta dai ricercatori Lakshya Dubey e Ayush Panwar, parte dall’identificazione di due ambienti di staging esposti nell’ottobre 2026, contenenti copie identiche degli stessi file. Gli indirizzi 16.5.0[.]225 e 16.5.0[.]226 appartengono a un gruppo di sei indirizzi utilizzati dagli operatori, elemento che porta CloudSEK a considerarli componenti ridondanti di un’unica operazione anziché infrastrutture criminali indipendenti. Il cuore dell’attività è un motore denominato doorway, sviluppato in Rust, composto da circa 21.870 righe di codice originale, 59 moduli offensivi, 60 registrazioni interne e differenti modalità di compilazione. Il software integra Tokio, componenti TLS e sistemi di gestione concorrente delle connessioni, permettendo scansioni e attacchi su una grande quantità di dispositivi. Gli archivi contengono inoltre manuali operativi, file di configurazione, registri delle autenticazioni e malware destinati a differenti processori.

La ricostruzione copre attività di scansione comprese tra il 19 settembre e il 19 ottobre 2026. CloudSEK ha analizzato i file senza compilare né eseguire i componenti recuperati, evitando di interagire attivamente con le infrastrutture compromesse. Il materiale costituisce quindi una fonte diretta sul funzionamento dell’organizzazione, ma non permette di ricostruirne necessariamente ogni operazione.

Undicimila join in un’ora, ma i download non equivalgono a infezioni

I numeri dell’operazione richiedono una distinzione tra evidenze tecniche raccolte e metriche dichiarate dagli aggressori. CloudSEK ha identificato 4.671 registrazioni di join associate a specifici moduli, riferite a 4.217 indirizzi IP distinti. Separatamente, sono state osservate 7.369 autenticazioni riuscite contro dispositivi MikroTik, distribuite su 4.923 identità di apparati, e 1.060 registrazioni di abbonati PPPoE riconducibili a un singolo operatore Internet. Il registro gestionale della botnet riporta invece 11.363 join e 58.920 eventi di download di payload in sessanta minuti. Queste metriche mostrano l’intensità delle attività dichiarate dagli operatori, ma non devono essere interpretate automaticamente come 58.920 dispositivi infettati: un file può essere scaricato più volte, senza che il malware venga necessariamente eseguito.

I ricercatori distinguono pertanto i download dai beacon, segnali inviati dai dispositivi che permettono di confermare l’esecuzione di un componente. Gli errori di acquisizione presenti nel materiale rendono inoltre alcune conte inferiori al numero reale degli eventi verificatisi durante la campagna. La ricerca documenta anche 1.772 IP di potenziali vittime associati a informazioni geografiche, senza fornire nel testo una distribuzione sufficientemente dettagliata per stabilire la presenza di specifiche vittime italiane.

Leggi anche: Tengu evolve Mirai con proxy, IPFS e persistenza aggressiva

Router MikroTik, telecamere e server Java nel mirino di 59 moduli

Doorway integra quattro grandi categorie di attacco: iniezione di comandi senza autenticazione, attraversamento dei percorsi e scrittura arbitraria di file, manipolazione delle configurazioni e utilizzo di credenziali predefinite oppure precedentemente esposte. Il motore riconosce il dispositivo attraverso una richiesta HTTP iniziale, controlla le caratteristiche della risposta e seleziona soltanto i moduli compatibili con il bersaglio. Il sistema utilizza anche criteri per ridurre le interazioni con ambienti sospetti di essere honeypot. Una risposta che presenta troppe caratteristiche identificative differenti oppure un numero anomalo di intestazioni Server può indurre il motore a scartare il bersaglio. La scelta evidenzia una capacità di selezione preventiva che riduce attività superflue e potenziali rilevamenti.

Tra gli obiettivi identificati compaiono router MikroTik e RouterOS, apparati ottici ONU, telecamere IP e servizi aziendali basati su Openfire, Jenkins, Tomcat e ActiveMQ. La ricerca documenta 20 host Jenkins con esecuzione remota di codice confermata e 16 caricamenti di plugin Openfire su venti bersagli non appartenenti a laboratori di test. La presenza di servizi Java amplia considerevolmente la superficie offensiva: Doorway non è limitata a dispositivi domestici o firmware embedded, ma può aggredire anche applicazioni di infrastruttura esposte su Internet. Questo elemento si collega ai precedenti attacchi contro Openfire, sfruttato per compromettere server attraverso plugin malevoli, sebbene le campagne rimangano distinte.

MikroTik trasformati in proxy SOCKS e dati degli abbonati PPPoE

L’indagine individua nella compromissione di MikroTik RouterOS uno degli elementi più concreti della costruzione di una possibile rete proxy. Le 7.369 autenticazioni riuscite e le modifiche alle configurazioni SOCKS mostrano che gli operatori avevano ottenuto accesso amministrativo a numerosi dispositivi, predisponendo funzionalità che possono consentire l’instradamento del traffico attraverso router di terzi. L’analisi comprende strumenti collegati a CVE-2023-30799, vulnerabilità conosciuta come FOISted, oltre a procedure alternative per scaricare componenti attraverso le funzioni di RouterOS. Uno dei payload è stage2.so, una libreria MIPS32 che invia un segnale ICMP verso l’infrastruttura ostile e tenta successivamente di aprire una shell remota attraverso la porta TCP 4444.

La presenza dell’exploit non prova però che questo specifico componente sia stato distribuito con successo su larga scala. Il registro tecnico conservato da CloudSEK documenta tre tentativi contro RouterOS 6.48.6 senza beacon positivi. Le autenticazioni riuscite e le configurazioni SOCKS costituiscono evidenze più solide della compromissione rispetto alla sola disponibilità del payload. Il recupero di 1.060 registrazioni PPPoE associate a un ISP suggerisce inoltre la possibilità che gli operatori abbiano ottenuto visibilità su informazioni di gestione degli abbonati. Non è dimostrato che tali dati siano stati commercializzati. Il caso richiama le operazioni di proxyjacking che hanno trasformato 143 dispositivi edge in proxy residenziali, confermando l’interesse criminale per gli apparati di rete come infrastrutture di transito.

Loader multipiattaforma e payload firmati per il dispositivo bersaglio

Doorway non distribuisce indiscriminatamente un singolo eseguibile. La catena di infezione comprende loader intermedi, piccoli dropper specifici per architettura e client finali, con versioni destinate a Linux e Windows. Il codice utilizza differenti meccanismi di recupero dei file, tra cui wget, curl, TFTP, FTP, connessioni TCP e condivisioni NFS, per adattarsi ai programmi presenti sul dispositivo compromesso. Nel caso di Openfire, il componente ofvalid.jar identifica sistema operativo e architettura, invia un beacon di esecuzione e recupera un client compatibile. Per ActiveMQ, la famiglia di loader wtg83 impiega script shell e PowerShell, oltre a configurazioni XML che permettono di avviare processi attraverso componenti Java. I client finali sono organizzati in pacchetti differenti, ma i protocolli completi di comando e controllo non risultano ricostruiti dal materiale disponibile.

Un elemento significativo riguarda la protezione dei collegamenti utilizzati per il download. Doorway può applicare firme HMAC associate all’indirizzo IP del bersaglio, impedendo che un URL intercettato venga normalmente riutilizzato da un’altra macchina. Il meccanismo ostacola alcune forme di acquisizione e analisi dei payload, senza impedire il blocco dell’infrastruttura malevola. I file documentano anche una componente denominata DARKLANTERN, associata a router ZBT e apparati di rete correlati. CloudSEK riporta 18 compromissioni attribuite a questa componente, otto delle quali confermate indipendentemente attraverso beacon. Il nome e l’interesse per questi apparati trovano un precedente nell’indagine sulle backdoor DarkLantern e SpeakingStone individuate nei router ZBT.

Il modello Watcher organizza scansioni e attacchi come un servizio industriale

La caratteristica organizzativa più insolita emerge dal documento WATCHER-BRIEF.md, che descrive un sistema di coordinamento delle attività simile alla gestione operativa di una piattaforma informatica. Gli operatori utilizzano cinque sessioni concorrenti, obiettivi di produzione, soglie prestazionali e controlli ricorrenti sull’efficacia delle differenti famiglie di exploit. Quando una categoria di bersagli produce pochi risultati, il sistema modifica le priorità, indirizzando risorse verso servizi più promettenti, come ActiveMQ, oppure verso nuovi gruppi di dispositivi individuati nelle scansioni. Sono previste procedure di escalation, registrazione degli avvisi e direttive per interrompere o riorganizzare attività che non producono risultati.

CloudSEK individua collegamenti con strumenti LLM, ma non identifica il modello di intelligenza artificiale utilizzato dagli operatori e non dimostra che tutte le decisioni siano prese autonomamente da agenti AI. L’evidenza principale riguarda l’esistenza di un ciclo operativo basato sui risultati, nel quale scoperta, sfruttamento, misurazione e riallocazione delle risorse vengono gestiti in maniera sistematica. Questa impostazione rende Doorway differente da una semplice raccolta di exploit eseguiti in sequenza: il gruppo tratta la compromissione dei dispositivi come un processo continuativo da ottimizzare.

Come riconoscere Doorway nelle reti aziendali e degli operatori

CloudSEK pubblica indicatori che possono essere utilizzati per il monitoraggio del traffico e le indagini retrospettive. Tra le infrastrutture osservate figurano 45.90.13[.]169 come server di distribuzione dei payload, 45.90.13[.]11 per le condivisioni NFS e 45.205.1[.]9 come destinatario principale dei beacon ICMP e delle connessioni di shell. Sono segnalati anche 176.98.182[.]21 e 184.174.96[.]216. Un indicatore particolarmente riconoscibile è l’intestazione HTTP User-Agent: Hello World, utilizzata dal motore durante le richieste iniziali di identificazione dei dispositivi. La sua presenza, soprattutto quando associata a scansioni ripetute di apparati esposti, può aiutare a individuare l’attività di ricognizione. Da sola, tuttavia, non dimostra una compromissione.

La difesa richiede soprattutto di rimuovere le interfacce amministrative dei router e delle telecamere dall’esposizione diretta su Internet, sostituire credenziali predefinite o condivise, limitare Telnet e UPnP e mantenere aggiornati i servizi Java. Sui sistemi MikroTik è opportuno verificare servizi SOCKS inattesi, account amministrativi sconosciuti, modifiche alle porte di gestione e accessi anomali alle informazioni PPPoE. Le organizzazioni devono inoltre ricercare connessioni ICMP e TCP verso gli indirizzi identificati, controllare eventuali plugin Openfire non autorizzati e verificare i servizi Jenkins, ActiveMQ, Tomcat, Confluence, ManageEngine, Mirth e LiteLLM accessibili dall’esterno. I controlli devono distinguere i semplici tentativi di scansione dalle evidenze di autenticazione riuscita, caricamento di payload ed esecuzione effettiva.

Continua con:

Botnet JDY fuori controllo: 1.500 router bucati per anticipare le patch di sicurezza

Evooo1Bot trasforma router in proxy SOCKS5 e nodi DDoS

Doorway dimostra che la compromissione IoT è diventata un processo industriale

L’indagine di CloudSEK evidenzia un cambiamento importante nella gestione delle botnet. La forza di Doorway non risiede necessariamente nello sviluppo di vulnerabilità sconosciute, ma nell’integrazione di tecniche note all’interno di un sistema capace di selezionare bersagli, apprendere credenziali, distribuire malware e misurare i risultati. La combinazione di 59 moduli offensivi, loader multipiattaforma e registri gestionali rende l’operazione sufficientemente flessibile da colpire dispositivi domestici, infrastrutture degli operatori e servizi aziendali. Le evidenze sulle autenticazioni MikroTik, sulle compromissioni Openfire e Jenkins e sui beacon dei dispositivi dimostrano che l’attività supera la semplice preparazione di un arsenale offensivo. Restano invece non confermati l’identità degli operatori, il modello economico della rete proxy, l’estensione complessiva delle infezioni e il comportamento completo dei client finali. Per aziende, fornitori di connettività e amministratori italiani, il rischio è direttamente collegato alla presenza di apparati di rete esposti, credenziali deboli e applicazioni server non aggiornate. Non esistono nel rapporto elementi sufficienti per quantificare le vittime italiane, ma la varietà dei prodotti coinvolti rende la minaccia rilevante anche per le infrastrutture nazionali. Doorway rappresenta soprattutto l’industrializzazione della compromissione dei dispositivi connessi: ogni router o server vulnerabile può diventare una risorsa operativa per gli aggressori, mentre la gestione automatizzata trasforma migliaia di attacchi individuali in un’infrastruttura criminale coordinata.