ClingSTUN: dispositivi IoT trasformati in proxy tramite STUN

Il 5 ottobre 2026 FortiGuard Labs, il gruppo di ricerca di Fortinet, ha pubblicato l’analisi di una backdoor Linux che chiama ClingSTUN. Il malware entra in router, telecamere, videoregistratori e altri dispositivi esposti su Internet sfruttando vulnerabilità note e non corrette, e li trasforma in nodi proxy controllati a distanza. Per restare raggiungibile dietro il NAT usa server STUN pubblici e legittimi, gli stessi che servono a VoIP e WebRTC.

La notizia è stata ripresa da The Hacker News, Dark Reading, Infosecurity Magazine e CSO Online. The Hacker News la presenta come botnet “Cling” e mette in evidenza i tentativi di sfruttamento del Realtek Jungle SDK; le altre testate usano il nome ClingSTUN.

Cosa è successo

Secondo la ricerca riportata da Infosecurity Magazine, FortiGuard ha seguito la campagna in tre periodi, ognuno con un server di download diverso:

• primo periodo, durato due giorni: una sola vulnerabilità, CVE-2022-36553, nei router Hytec Inter;
• secondo periodo: CVE-2025-34035 nel servizio cloud IoT di EnGenius e CVE-2024-23625 nel servizio UPnP di D-Link; poi vulnerabilità di command injection in dispositivi Linear, Realtek, TP-Link, AVTECH e D-Link;
• terzo periodo: nuovi punti d’ingresso, fino a 24 vulnerabilità in totale. Tra queste ci sono anche le falle di Ivanti Connect Secure CVE-2023-46805 e CVE-2024-21887 e vulnerabilità più recenti come CVE-2026-36356 e CVE-2025-67038.

CSO Online cita tra i bersagli anche i router TP-Link Archer AX21 e le telecamere AVTECH, e parla di vulnerabilità di command injection, code injection e buffer overflow. Le fonti non nominano vittime.

Dettagli tecnici

Il ruolo del dispositivo. ClingSTUN è una backdoor di tipo back-connect proxy: il dispositivo compromesso inoltra traffico per conto degli operatori ed esegue i loro comandi. Come osserva Jason Soroko di Sectigo, sentito da CSO Online, un dispositivo non deve contenere dati sensibili per essere utile a un attaccante.

L’uso di STUN. Il malware invia richieste binding STUN standard a server pubblici (24 nella seconda versione, 13 nella terza) per scoprire il proprio indirizzo esterno e la mappatura delle porte, e per tenere aperte le associazioni del NAT. Poi comunica periodicamente agli stessi server un identificativo di gruppo e le porte mappate. Il traffico somiglia a quello di normali comunicazioni VoIP e WebRTC. FortiGuard precisa che non è ancora verificato come l’operatore ottenga le mappature e faccia arrivare i comandi attraverso il NAT, e avverte di non considerare i servizi STUN come infrastruttura degli attaccanti.

Persistenza e occultamento. Dopo l’installazione ClingSTUN:

• termina i processi concorrenti e disattiva il watchdog del dispositivo;
• si copia in percorsi di sistema nascosti;
• si aggiunge all’avvio modificando /etc/inittab, /etc/init.d/rcs e /etc/rc.d/rc.boot (percorsi riportati da CSO Online);
• fa sembrare la propria voce in /proc quella del processo init del sistema.

Esecuzione e propagazione. Supporta l’esecuzione di comandi da remoto e contiene exploit per altre sette vulnerabilità, tra cui falle dello SDK di Realtek e di tre prodotti DVR, con cui si diffonde ad altri dispositivi. È compilato per ARM, Intel 80386, MIPS, PowerPC e x86-64.

Indicatori pubblici. Gli articoli consultati non riportano hash né indirizzi: gli indicatori di compromissione sono nella ricerca originale di FortiGuard Labs.

MITRE ATT&CK (mappatura dai fatti riportati): T1190 (Exploit Public-Facing Application), T1105 (Ingress Tool Transfer), T1037.004 (Boot or Logon Initialization Scripts: RC Scripts), T1036 (Masquerading), T1059.004 (Unix Shell), T1090 (Proxy), T1210 (Exploitation of Remote Services).

Impatto per le aziende europee e italiane

Le fonti non citano vittime in Europa, ma i dispositivi colpiti sono comuni anche in Italia: router di piccoli uffici, telecamere e videoregistratori di videosorveglianza, apparati di rete dimenticati in un armadio. Un dispositivo così, trasformato in proxy, fa uscire dalla tua connessione il traffico di qualcun altro: il tuo indirizzo IP può comparire nei log di attacchi diretti a terzi.

La presenza di Ivanti Connect Secure nell’elenco ricorda che lo stesso operatore non punta solo all’IoT: i concentratori VPN non aggiornati sono porte d’ingresso alla rete aziendale. Per i soggetti NIS2, l’articolo 21 chiede la gestione delle vulnerabilità e la sicurezza nell’acquisizione e nella manutenzione dei sistemi: telecamere e router fuori supporto rientrano nel perimetro da gestire.

Sul metodo le opinioni divergono. Louis Eichenbaum di ColorTokens suggerisce controlli compensativi e microsegmentazione per i dispositivi che non si possono aggiornare subito; John Gallagher di Viakoo ritiene invece che la segmentazione da sola non basti e punta sull’aggiornamento automatico del firmware su parchi IoT di più produttori.

Cosa fare subito

1. Fai l’inventario dei dispositivi esposti su Internet, con modello, versione del firmware e stato del supporto del produttore.
2. Aggiorna per primi i dispositivi colpiti dalle CVE citate e, in particolare, Ivanti Connect Secure per CVE-2023-46805 e CVE-2024-21887.
3. Sostituisci o isola i dispositivi che non ricevono più aggiornamenti: niente interfacce di gestione e niente UPnP esposti su Internet.
4. Filtra il traffico in uscita delle reti di telecamere, DVR e IoT: consenti solo le destinazioni di cui hanno bisogno.
5. Cerca traffico STUN dove non ha senso. Un DVR o una telecamera che contatta a intervalli regolari server STUN pubblici, o apre connessioni UDP inattese con keepalive ricorrenti, va controllato. Come dice Soroko, conta il comportamento del dispositivo, non la reputazione della destinazione.
6. Sui dispositivi dove hai una shell, controlla le voci di avvio in /etc/inittab e negli script di /etc/init.d/ e /etc/rc.d/, e verifica se c’è più di un processo che si presenta come init.
7. Confronta i tuoi log con gli indicatori di compromissione pubblicati da FortiGuard Labs.

Come aiuta ARXDOME

ARX Expose mostra dall’esterno porte aperte, prodotti riconosciuti e vulnerabilità note sui servizi pubblici: è lì che compaiono interfacce di gestione e dispositivi esposti per errore. ARX Watch trova sulla rete i dispositivi senza sonda, come telecamere e videoregistratori, e avvisa quando ne compare uno nuovo. ARX Sentry raccoglie i log dei firewall e li porta nelle pagine del SOC e nella mappa del NOC, con le connessioni rifiutate e il traffico in uscita bloccato. Sui dispositivi IoT non si installa un agent: la visibilità passa dalla rete e dal firewall.

Ultimo aggiornamento: 6 ottobre 2026