Benvenuto su Hackerpunk — Hacking News Live 24h, la fonte in tempo reale per tutte le news di cybersecurity, cybercrime e Deep AI. Aggiorniamo costantemente le nostre notizie 24 ore su 24 con report tecnici, indagini digitali e analisi sugli attacchi più recenti.
I tentativi di exploit dell’SDK Realtek Jungle diffondono la botnet Cling con un C2 basato su STUN
Ravie Lakshmanan, 5 ottobre 2026, Vulnerabilità / Malware
Sono stati osservati attori malintenzionati che tentavano di sfruttare una falla di sicurezza critica, ora corretta, che interessava il kit di sviluppo software (SDK) Realtek Jungle per distribuire un malware botnet denominato Cling.
«Cling è degno di nota non perché introduca una nuova tecnica di propagazione, ma perché riutilizza il normale comportamento STUN trasformandolo in un pratico canale di comando e controllo», ha affermato Nozomi Networks in un rapporto pubblicato la scorsa settimana. «Il risultato è una botnet il cui traffico può assomigliare a una legittima attività di attraversamento NAT, pur supportando comandi di propagazione, proxy, tunneling e denial-of-service».
L’azienda specializzata nella sicurezza delle tecnologie operative (OT) ha dichiarato di aver osservato un picco nei tentativi di sfruttare la vulnerabilità CVE-2021-35394 (punteggio CVSS: 9,8), una vulnerabilità critica di esecuzione remota di codice (RCE) presente nel Realtek Jungle SDK, a partire dal 5 settembre 2026 circa, con una parte di tale attività finalizzata alla diffusione di Cling.
Un’analisi del campione di malware ha rivelato che esso incorpora una logica di exploit per varie vulnerabilità di iniezione di comandi e RCE che interessano router e DVR di diversi produttori -
- RCE dell’SDK Realtek (CVE-2014-8361)
- Router Eir D1000 RCE (CVE-2016-10372)
- RCE del DVR CCTV MVPower (CVE-2016-20016)
- Router LB-LINK RCE (CVE-2023-26801)
- Router FiberHome SR1041F / RCE del DVR China Mobile HG6543C4 (CVE-2023-41011).
- RCE del DVR TBK (CVE-2024-3721)
- RCE di Linksys (CVE-2025-34037)
«Il controllo di istanza singola, volto a garantire l’esecuzione di una sola copia, prevede il binding di un socket con SO_REUSEADDR alla porta 33957 e l’uscita corretta in caso di fallimento», ha affermato Nozomi Networks. «Il campione si copia in /root/.cling e /usr/local/bin/.cling. Entrambi gli eseguibili vengono aggiunti a /etc/inittab, /etc/init.d/rcS e /etc/rc.d/rc.boot, garantendo così la persistenza sui sistemi di init SysV e BusyBox».
Un meccanismo alternativo di persistenza consiste nell’identificare il binario wget sul sistema infetto e sostituirlo con il malware, ma non prima di aver spostato l’originale in un’altra posizione. Ciò, a sua volta, fa sì che il malware venga eseguito quando un processo legittimo richiama il comando «wget».
Un aspetto degno di nota di Cling è il suo abuso del traffico STUN, apparentemente innocuo, e dell’infrastruttura STUN pubblica per registrare gli host infetti, ricevere comandi dall’operatore e rendere le attività dannose meno evidenti dal punto di vista del monitoraggio di rete.
STUN, acronimo di Session Traversal Utilities for Network Address Translation (NAT), è un protocollo di rete standardizzato progettato per aiutare i dispositivi situati dietro un NAT o un firewall a stabilire comunicazioni peer-to-peer in tempo reale.
Nello specifico, il malware segue un processo in quattro fasi per le comunicazioni di comando e controllo (C2):
- Invia una richiesta di binding STUN a un elenco predefinito di 13 server STUN all’incirca ogni 5 secondi. L’ID della transazione è impostato su tutti zeri anziché su un valore casuale, come previsto dalle specifiche.
- Registra le porte osservabili dall’esterno restituite da tali server al ricevimento di un messaggio di risposta di successo del binding contenente l’indirizzo IP pubblico dell’endpoint e i numeri di porta associati.
- Invia a ciascun server un messaggio di registrazione personalizzato (ovvero un datagramma UDP) che include le porte mappate e un tag che indica come il dispositivo è stato infettato (ad es. realtek.selfrep, selfrep.router).
- Interroga i pacchetti UDP che codificano i comandi dell’operatore nel campo ID transazione STUN.
«Dal punto di vista del monitoraggio di rete, l’attività appare come un’interazione innocua con i server STUN», ha affermato Nozomi Networks. «Dato che il messaggio di registrazione personalizzato viene inviato a ogni server STUN presente nell’elenco, è evidente che l’operatore necessiti di visibilità su almeno uno dei server, al fine di tracciare i nuovi bot che si uniscono allo sciame e sapere dove inviare i comandi».
Vale la pena notare che questi messaggi di registrazione non sono conformi alla definizione del protocollo STUN, il che fa sì che i server STUN legittimi scartino il pacchetto. Tuttavia, si ritiene che uno dei 13 server («145.249.115[.]184») abbia restituito un ID di transazione composto interamente da zeri invece di ripetere l’ID di transazione della richiesta di binding originale nella risposta di successo del binding.
