Per trasformare un dispositivo IoT esposto in un'arma con cui sferrare attacchi DDoS oggi bastano una password debole, un servizio di gestione raggiungibile da Internet e qualche componente open-source riciclato. Il fattore critico si è spostato dalla complessità del malware alla velocità con cui gli attaccanti riescono a produrne di nuovo, assemblarlo e distribuirlo su larga scala.

A documentare questa dinamica è il team di Nozomi Networks Labs, che ha esaminato due famiglie di malware scritte in linguaggio Golang e individuate sul campo nel corso della primavera. I due campioni, chiamati Apex2 e c2c/meow, illustrano la rinuncia alla sofisticazione a favore di rapidità, riutilizzo del codice e scalabilità.

Partecipa agli ItalianSecurityAwards 2026 ed esprimi il tuo voto premiando le soluzioni di cybersecurity che reputi più innovative

Le botnet derivate da Mirai continuano a dominare il panorama delle minacce IoT, ma il vero elemento di novità riguarda i tempi. L'adozione di Golang insieme a componenti open-source pronti all'uso, infrastrutture standard e di un elevato grado di automazione ha ridotto drasticamente lo sforzo richiesto per costruire un malware DDoS capace di orchestrare le ondate di traffico che saturano un bersaglio online fino a renderlo irraggiungibile. Il risultato è un flusso costante di botnet semplici ma efficaci, pronte a colpire i sistemi Linux e IoT lasciati esposti, la cui sicurezza è spesso trascurata, come gli attaccanti sanno bene.

I ferri del mestiere

Apex2 si presenta come l'evoluzione diretta della precedente botnet Apex, di cui conserva le somiglianze strutturali. Colpisce sia macchine Windows sia Linux e, in quest'ultimo caso, supporta un'ampia gamma di architetture di processore, dai comuni x86 fino ai chip tipici dei dispositivi embedded come ARM, ARM64 e MIPS. La catena di infezione osservata dagli honeypot di Nozomi inizia con una serie di connessioni Telnet, seguite da attacchi brute force per forzare le credenziali di accesso. Una volta ottenuto l'accesso, il malware viene scaricato ed eseguito sul dispositivo.

Da quel momento il campione contatta il server di Comando e Controllo, si registra, comunica sistema operativo e architettura dell'host attraverso un protocollo in chiaro e resta quindi in attesa delle istruzioni con cui l'operatore avvia o interrompe le ondate di traffico che compongono un DDoS. Il repertorio comprende flood HTTP e HTTPS pensati per aggirare le protezioni di servizi come Cloudflare, diverse varianti di flood UDP, incluse quelle mirate ai server di Discord e di gaming, e flood TLS con configurazioni studiate per tenere aperte il più a lungo possibile le connessioni verso il bersaglio. Curiosamente, durante l'esecuzione il malware stampa messaggi di stato che descrivono ogni azione compiuta e questo torna utile agli sviluppatori nella fase di analisi del codice.

Il secondo campione, c2c/meow, racconta la stessa tendenza dal versante opposto. È stato identificato tramite un honeypot SSH e al momento della scoperta il file non risultava dannoso per nessuno dei motori antivirus di VirusTotal. Rispetto ad Apex2, si tratta di una botnet autonoma molto più semplice, ottenuta mettendo insieme uno scanner, una logica di comando e controllo essenziale, un meccanismo di persistenza e alcuni moduli di flooding configurabili.

La sigla c2c deriva dal percorso qwiklabs/c2c trovato nel campione, forse un tentativo di mimetizzarsi dietro terminologie che ricordano ambienti di formazione o laboratori cloud legittimi, forse un semplice residuo dell'ambiente di sviluppo; meow è invece il nome con cui il file veniva scaricato sui sistemi bersaglio. Entrambi risultano più utili come indicatori di una singola campagna che come etichette stabili di una famiglia, perché tendono a cambiare da un'ondata all'altra.

Il binario analizzato non contiene un modulo di auto-propagazione. A cercare le vittime provvede uno scanner SSH separato, anch'esso scritto in Golang, che individua su Internet gli host raggiungibili e protetti da credenziali deboli. La separazione tra la fase di scansione e quella di esecuzione del payload mantiene il malware semplice e, allo stesso tempo, consente alla campagna di operare su vasta scala quando i dispositivi vulnerabili sono abbastanza numerosi.

Una volta in esecuzione, il campione si collega a un server di Comando e Controllo codificato al suo interno e scambia messaggi su una connessione TCP in chiaro: si autentica con una stringa fissa lasciata nel codice e comunica nome host e utente del sistema infetto. Segue una routine di escalation dei privilegi che verifica la possibilità di usare sudo senza password; in caso affermativo il malware si rilancia con privilegi più alti, si copia in una cartella di sistema e crea un finto servizio systemd battezzato CPU Frequency Daemon, così da apparire come un normale componente di gestione della frequenza del processore e sopravvivere ai riavvii.

Anche c2c/meow, nonostante la semplicità, mette a disposizione diversi metodi di attacco, ciascuno con durata e porte configurabili. Si va dai flood ICMP a quelli UDP diretti verso un indirizzo o un dominio, fino a numerose varianti di flood HTTP costruite su librerie differenti e ad attacchi che agiscono direttamente sui pacchetti TCP. La loro efficacia, osservano i ricercatori, diventerebbe concreta solo se la botnet raggiungesse dimensioni sufficienti. Restano comunque assenti le funzioni tipiche dei progetti più maturi, come la firma dei comandi, la scoperta dinamica dei server di comando e controllo o l'offuscamento del protocollo di comunicazione.

Indicazioni per la difesa

Il messaggio che i due casi lasciano a chi si occupa di difesa riguarda il metro con cui si misura il rischio. La sofisticazione non è l'unico parametro; anche un malware elementare può produrre danni rilevanti quando viene distribuito su larga scala, e la rapidità con cui nascono nuove varianti impone di adeguare i tempi di rilevamento e risposta. Per questo Nozomi indica come indispensabili le tecniche di analisi scalabili (machine learning, LLM), capaci di classificare grandi volumi di campioni, isolare le deviazioni dalle famiglie note e trasformarle rapidamente in regole di detection utilizzabili.

Sul fronte pratico, le contromisure suggerite partono dalla riduzione dell'esposizione. I ricercatori raccomandano di limitare la raggiungibilità da Internet dei servizi di gestione, in particolare Telnet e SSH su dispositivi IoT, sistemi Linux embedded e apparati di edge, ricorrendo dove possibile a VPN, allowlist e jump host anziché esporre i servizi direttamente in rete. A ciò si aggiungono l'eliminazione delle credenziali predefinite, deboli o riutilizzate a favore dell'adozione di autenticazione robusta per gli accessi amministrativi. È indicato inoltre il monitoraggio dei tentativi di brute-force e degli accessi anomali, come i login riusciti da aree geografiche inattese o da infrastrutture cloud seguiti subito da comandi di download.

Un ulteriore livello riguarda il monitoraggio de traffico in uscita dai dispositivi IoT e Linux, da ispezionare alla ricerca di comportamenti riconducibili a un server di comando e controllo, come sessioni TCP in chiaro verso porte insolite o comunicazioni JSON impreviste. Sono inoltre caldeggiate la segmentazione dei sistemi IoT e dei dispositivi Linux a bassa affidabilità, da separare rispetto alle reti aziendali critiche, e la limitazione della connettività in uscita allo stretto necessario, per abbassare la capacità di un dispositivo compromesso di raggiungere liberamente l'infrastruttura controllata dagli attaccanti.