ClingSTUN: il backdoor Linux che trasforma i server STUN legittimi in

FortiGuard Labs ha identificato ClingSTUN, un backdoor Linux back-connect proxy che abusa del protocollo STUN per stabilire connettività attraverso NAT senza server di coordinamento dedicati. Scoperto recentemente, il malware sfrutta oltre due dozzine di vulnerabilità note per l'accesso iniziale e l'autopropagazione, colpendo dispositivi embedded e IoT su cinque architetture hardware diverse. La tecnica rende inefficaci le difese basate sul blocco di infrastruttura malevola: i server STUN pubblici restano servizi legittimi, non controllati dagli attaccanti.

Come funziona l'abuso del protocollo STUN

ClingSTUN stabilisce un socket UDP, si lega a una porta locale casuale e invia richieste STUN binding standard a endpoint pubblici. Dopo lo scambio, il malware invia periodicamente il proprio group identifier e la mapped-port list agli stessi endpoint STUN. Secondo FortiGuard Labs, "no separate coordination-server registration was identified in this path".

Il protocollo STUN (Session Traversal Utilities for NAT), definito nell'RFC 5389, è progettato per consentire a endpoint dietro NAT di scoprire il proprio indirizzo IP pubblico e la porta mappata. ClingSTUN rovescia questo meccanismo legittimo: invece di negoziare connettività per applicazioni voIP o WebRTC, trasforma il sistema compromesso in proxy UDP raggiungibile dall'esterno. Gli attaccanti ottengono NAT traversal senza infrastruttura dedicata, sfruttando l'affidabilità e la disponibilità dei server STUN pubblici.

Questa scelta architettale presenta conseguenze operative immediate per i team di sicurezza. I blocchi basati su reputation di IP o domini — tecniche consolidate nel rilevamento di infrastruttura C2 tradizionale — falliscono perché gli endpoint contattati sono servizi legittimi. La fonte sottolinea esplicitamente che "these third-party services should not be automatically classified as attacker-controlled infrastructure".

La catena di infezione: exploit multi-vendor e persistenza su sistemi embedded

ClingSTUN non si limita al meccanismo di comunicazione. Il malware integra exploit per oltre due dozzine di vulnerabilità, suddivise in due categorie: flaw per exploit indiscriminato e flaw hardcoded per autopropagazione. I vendor interessati dall'exploit indiscriminato includono Avtech, EnGenius, D-Link, Hytec, Ivanti, Lantronix, Linear, MeiG, Realtek, Sunhillo, Tenda e TP-Link. Gli exploit hardcoded per l'autopropagazione riguardano invece dispositivi China Mobile, KGUARD, Linksys, LB-LINK, MVPower, Realtek e TBK.

Il supporto multi-architettura amplia la superficie di attacco ben oltre i server Linux tradizionali. I downloader del malware recuperano payload per AMD X86-64, ARM, Intel 80386, MIPS R3000 e PowerPC. Questo spettro copre router, gateway industriali, dispositivi IoT e sistemi embedded — infrastrutture spesso sottodimensionate sul piano della visibilità di sicurezza e della frequenza di patching.

La persistenza si implementa attraverso una combinazione di file nascosti e modifiche a script di sistema. Il malware si copia in due file nascosti con permessi eseguibili, poi appende comandi di avvio a tre script di inizializzazione di sistema. Questa tecnica è particolarmente efficace sui sistemi embedded dove i meccanismi di integrità del boot sono spesso assenti o disabilitati per convenienza operativa.

Tre varianti, stesso comportamento anti-concorrenza

FortiGuard Labs ha osservato tre varianti del botnet ClingSTUN che condividono un pattern comportamentale coerente. Tutte terminano processi di malware concorrenti, disabilitano il watchdog timer — meccanismo hardware o software progettato per riavviare il dispositivo in caso di malfunzionamento —, attivano il meccanismo di persistenza ed eseguono comandi remoti.

La terminazione dei processi concorrenti e la disabilitazione del watchdog timer indicano una logica di competizione per le risorse del sistema compromesso. Il watchdog timer, quando attivo, può causare il riavvio del dispositivo se un processo non risponde entro un intervallo definito; la sua disabilitazione impedisce che un'infezione instabile o conflittuale esponga la presenza del malware attraverso comportamenti anomali rilevabili.

Il malware ascolta inoltre pacchetti specifici che abilitano l'esecuzione remota di codice e l'attivazione dell'autopropagazione. Questa capacità di RCE remota, documentata dalla fonte primaria, completa il quadro di un backdoor progettato per l'accesso persistente e la diffusione autonoma all'interno di segmenti di rete vulnerabili.

"Instead, defenders should assess STUN activity alongside suspicious process behavior, unexpected UDP connections, and recurring keepalive traffic" — FortiGuard Labs via SecurityWeek

Cosa fare adesso

Le raccomandazioni operative emergono direttamente dall'analisi di FortiGuard Labs e dalla natura tecnica del malware:

Monitorare il traffico STUN anomalo, non solo le connessioni TCP sospette. La maggior parte delle organizzazioni concentra il rilevamento C2 sul traffico TCP e sui domini noti. ClingSTUN dimostra che il coordinamento può avvenire interamente su UDP attraverso servizi pubblici legittimi. I team di sicurezza devono allargare l'ambito di analisi al traffico STUN con pattern ricorrenti o keepalive insoliti.

Correlare l'attività STUN con il comportamento del processo e delle connessioni UDP. La fonte raccomanda esplicitamente di valutare l'attività STUN in combinazione con processi sospetti, connessioni UDP inattese e traffico keepalive periodico. L'isolato rilevamento di query STUN non è indicatore sufficiente di compromissione.

Verificare la presenza di file nascosti e modifiche ai script di inizializzazione sui sistemi embedded. Il meccanismo di persistenza di ClingSTUN — file nascosti con permessi eseguibili e append a script di boot — è rilevabile attraverso controlli di integrità mirati ai sistemi Linux non tradizionali, spesso esclusi dalle politiche di hardening standard.

Rivedire la copertura di sicurezza dei dispositivi multi-architettura. Router, gateway industriali e dispositivi IoT che eseguono su ARM, MIPS o PowerPC richiedono lo stesso livello di visibilità e gestione delle patch dei server enterprise, non una copertura ridotta o differita.

Il paradosso della difesa: quando il malevolo è indistinguibile dal lecito

ClingSTUN rappresenta un'evoluzione nel design della resilienza operativa dei malware: non costruisce infrastruttura propria, non registra domini, non affitta server cloud compromissibili. Sfrutta invece servizi pubblici esistenti, affidabili e necessari per il funzionamento di applicazioni legittime. Il risultato è un'inversione del modello difensivo consolidato, dove la classificazione binaria "lecito/malevolo" di un endpoint diventa insufficiente.

La fonte non specifica l'identità degli operatori, la scala dell'infezione, la geografia delle vittime o eventuali funzionalità aggiuntive oltre al proxy backdoor. Non emerge inoltre se le vulnerabilità sfruttate siano state tutte patchate dai vendor interessati o se alcune rimangano sprovviste di correzione. Questi limiti lasciano aperti interrogativi sulla prosecuzione della campagna e sulla sua espansione a nuovi dispositivi.

Il messaggio per i team di sicurezza è inequivocabile: il perimetro di difesa si sposta dal "blocca il dominio malevolo" all'"analizza il comportamento del processo". In un panorama dove i server STUN pubblici fungono da coordinamento non intenzionale, la visibilità comportamentale diventa l'unica linea di difesa affidabile.

Domande frequenti

I server STUN sono stati compromessi dagli attaccanti?
No. I server STUN pubblici restano servizi legittimi e non sono sotto il controllo degli operatori di ClingSTUN. Il malware li abusa per la loro funzione nativa — scoprire IP e porte mappate — senza alterarne il funzionamento.

Perché i dispositivi embedded sono particolarmente esposti?
Supportano architetture diverse dai server standard (ARM, MIPS, PowerPC), ricevono patch con frequenza inferiore, spesso mancano di meccanismi di integrità del boot e sono esclusi dalle politiche di hardening enterprise.

Perché il rilevamento basato su reputation fallisce contro ClingSTUN?
Perché il malware non contatta infrastruttura dedicata. I blocchi IP o domini colpiscono servizi STUN legittimi essenziali per altre applicazioni, rendendo la tecnica incompatibile con le operazioni di rete normali.

Fonti

• https://www.securityweek.com/linux-backdoor-abuses-stun-protocol-exploits-dozens-of-flaws/
• https://thehackernews.com/
• https://thehackernews.com/2026/06/weekly-recap-new-linux-flaw-pan-os.html
• https://securitylab.github.com/advisories/GHSL-2026-140_7-Zip/
• https://thehackernews.com/2026/05/cert-in-mandates-12-hour-patching-for.html
• https://kb.cert.org/vuls/id/780781
• https://www.obsidiansecurity.com/blog/when-is-stdio-mcp-actually-a-vulnerability

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti