Cling: il botnet che trasforma STUN in tunnel C2 nascosto nei dispositivi IoT

Attori di minaccia stanno sfruttando CVE-2021-35394, una vulnerabilità critica nel Realtek Jungle SDK con punteggio CVSS 9.8 secondo il National Vulnerability Database, per distribuire il botnet Cling. Nozomi Networks ha osservato uno spike di tentativi di exploit intorno al 5 settembre 2026. Il malware non introduce tecniche di propagazione inedite: il suo elemento distintivo è l'uso del protocollo STUN — normalmente impiegato per NAT traversal in applicazioni real-time — come canale di comando e controllo praticamente invisibile agli strumenti di detection tradizionali.

Come il protocollo STUN diventa un tunnel C2

Il Session Traversal Utilities for NAT (STUN) è definito nella RFC 8489 come protocollo per consentire a endpoint dietro NAT di scoprire il proprio indirizzo IP pubblico e aprire porte per comunicazioni in entrata. Le implementazioni legittime generano transaction ID casuali di 12 byte per ogni richiesta; il server STUN risponde facendo eco dello stesso identificativo.

Cling inverte questa logica. Il malware invia Binding Request con transaction ID sistematicamente azzerato a tredici server STUN hard-coded — la maggior parte servizi pubblici affidabili — con un intervallo di circa cinque secondi tra ogni pacchetto. Il server controllato dall'operatore, 145.249.115.184, risponde anch'esso con transaction ID azzerato anziché con l'echo standard. Questo disallineamento con la specifica RFC è l'unico indicatore di compromissione rilevabile nel traffico.

I comandi veri e propri sono nascosti nel campo transaction ID delle risposte STUN successive. Nozomi Networks osserva che questi pacchetti apparentemente originano da 74.125.250.129, l'indirizzo di stun.l.google.com. La fonte rileva però un TTL IP diverso rispetto alle risposte STUN autentiche, elemento che suggerisce spoofing UDP piuttosto che compromissione dell'infrastruttura Google.

"The operator is not merely hiding commands inside a STUN-looking packet, but they are making those commands appear as if they are legitimate replies from one of the most recognizable STUN services on the internet."

Nozomi Networks

L'architettura multi-meccanismo di Cling

Una volta ottenuto l'accesso iniziale tramite exploit RCE, Cling implementa persistenza su più livelli. Il malware copia se stesso in /root/.cling e /usr/local/bin/.cling, quindi appende riferimenti a /etc/inittab, /etc/init.d/rcS e /etc/rc.d/rc.boot. Il meccanismo alternativo è più insidioso: sostituisce il binario wget del sistema con il proprio eseguibile, spostando l'originale in wget.r. Quando un processo o un amministratore invoca wget, il malware esegue prima il proprio payload, poi delega al binario originale — un pattern che rende la detection basata su integrità dei file particolarmente complessa sui sistemi embedded Linux.

Fortinet FortiGuard Labs, nel report del 5 ottobre 2026 che denomina la minaccia ClingSTUN, conferma che il malware funziona da backconnect proxy backdoor. I sistemi infetti diventano nodi proxy remotamente controllabili, con capacità di tunneling e pivoting interno. La fonte sottolinea che il traffico STUN si confonde facilmente con comunicazioni VoIP e WebRTC legittime, rendendo inefficaci le regole di detection network-based generiche.

Il targeting multi-vendor e le vulnerabilità aggiuntive

Beyond CVE-2021-35394, il dossier documenta sette vulnerabilità hard-coded nel malware per self-propagation, coprendo vendor diversi: D-Link, Tenda, Ivanti, FiberHome, LB-LINK, Linksys, Eir, MVPower, TBK. Le CVE collegate nel dossier forniscono contesto verificabile per vulnerabilità storiche nel medesimo ecosistema: CVE-2014-8361 (Realtek), CVE-2016-10372 (Eir router), CVE-2016-20016 (MVPower DVR), CVE-2023-26801 (LB-LINK), e CVE-2023-41011 (FiberHome/China Mobile RCE) — quest'ultima citata esplicitamente dalla fonte primaria.

La capacità di proxy backconnect espone le organizzazioni a rischi di pivoting interno: un dispositivo IoT compromesso su un segmento di rete perimetrale può diventare punto di ingresso per movimento laterale. I target DoS osservati includono il cluster Università di Chicago (192.170.240.137:53), un ISP sudcoreano e server Minecraft — un mix che suggerisce operatori interessati sia a distruzione mirata che a servizi commerciali.

Cosa fare adesso

• Verificare la presenza di firmware patchato per CVE-2021-35394 su tutti i dispositivi che utilizzano Realtek Jungle SDK, prioritizzando router e DVR esposti a internet.
• Ispezionare attivamente i sistemi embedded Linux per la persistenza via sostituzione binari di sistema, con particolare attenzione all'integrità di wget e degli script di init.
• Analizzare il traffico STUN in uscita alla ricerca di transaction ID azzerati in Binding Request ripetuti verso server non standard o con pattern temporali rigidi di circa 5 secondi.
• Correlare le comunicazioni STUN con il TTL IP delle risposte: una discrepanza rispetto ai valori attesi dai server pubblici noti indica probabile spoofing e traffico C2.

Perché STUN cambia il paradigma della detection

La scelta del protocollo STUN non è casuale. A differenza di canali C2 basati su DNS over HTTPS, TLS su porte non standard o protocolli proprietari, STUN gode di legittimità strutturale: è permesso dalla maggior parte dei firewall aziendali, non richiede autenticazione, e il suo traffico è numericamente dominante in ogni rete che ospiti applicazioni WebRTC o VoIP. L'abuso di infrastrutture pubbliche come server STUN di Google aggiunge un layer di plausibilità che sfida i modelli comportamentali tradizionali.

Il campione MIPS analizzato da GBHackers presenta hash SHA-1 3b0ac6aaabb3bf8058ca14f9c8ccc613cfa3ea71. Il malware non cifra le comunicazioni: si nasce nella banalità apparente del protocollo. Per i difensori, questo significa che la profilazione del traffico deve scendere al livello di implementazione — transaction ID, pattern temporali, anomalie nel TTL — piuttosto che fermarsi alla mera presenza di pacchetti STUN.

Il dossier non quantifica la scala dell'infezione, né attribuisce l'operazione a un gruppo specifico. Non emerge inoltre se lo spike del 5 settembre 2026 si sia evoluto in campagna continuativa o rappresenti un'onda isolata. Ciò che resta documentato è un salto di qualità nell'occultamento del C2: non più protocolli mascherati, ma protocolli completamente autentici usati in modo tecnicamente anomalo.

Fonti

• https://thehackernews.com/2026/10/realtek-jungle-sdk-exploit-attempts.html
• https://github.com/SecOpsNews/news/issues/74727
• https://blog.netmanageit.com/realtek-jungle-sdk-exploit-attempts-deliver-cling-botnet-with-stun-based-c2/
• https://www.guardianmssp.com/2026/10/05/realtek-jungle-sdk-exploit-attempts-deliver-cling-botnet-with-stun-based-c2/
• https://www.scworld.com/brief/cling-botnet-exploits-realtek-sdk-flaw-uses-stun-for-c2
• https://gbhackers.com/cling-malware-masquerades-as-google-stun-traffic/
• https://news.lavx.hu/article/cling-botnet-hides-command-traffic-inside-stun-protocol-exchanges
• https://nvd.nist.gov/vuln/detail/cve-2014-8361
• https://nvd.nist.gov/vuln/detail/cve-2016-10372
• https://nvd.nist.gov/vuln/detail/cve-2016-20016
• https://nvd.nist.gov/vuln/detail/CVE-2023-26801
• https://nvd.nist.gov/vuln/detail/CVE-2023-41011