Cling Malware Masquerades as Google STUN Traffic to Control Compromised IoT Devices

A newly identified IoT botnet, Cling, disguises its command-and-control communications as legitimate STUN traffic, including packets that appear to originate from Google’s public STUN infrastructure.

The technique enables attackers to manage compromised internet-facing devices while blending activity into routine NAT-traversal traffic used by real-time communications platforms.

Nozomi Networks Labs discovered the campaign while investigating a rise in exploitation attempts targeting CVE-2021-35394, a critical remote code execution flaw in the Realtek Jungle SDK diagnostic component commonly compiled as UDPServer.

Cling Malware Masquerades as Google STUN Traffic

The vulnerability affects Realtek Jungle SDK versions 2.0 through 3.4.14B and permits unauthenticated remote attackers to execute arbitrary commands on exposed devices.

Attackers exploit the flaw by sending UDP packets beginning with orf;, followed by shell commands. In observed attacks, the payload used BusyBox wget to retrieve a malicious binary, make it executable, and launch it with an infection-method tag such as realtek.selfrep.

Cling then targets additional vulnerable hardware using embedded exploits for flaws affecting Realtek devices, LB-LINK routers, TBK DVRs, Linksys equipment, Eir routers, FiberHome devices, and MVPower CCTV DVRs.

Once deployed, the MIPS-based malware establishes persistence by copying itself to /root/.cling and /usr/local/bin/.cling. It appends startup entries to /etc/inittab, /etc/init.d/rcS, and /etc/rc.d/rc.boot, allowing execution to survive reboots on BusyBox and SysV-style embedded Linux devices.

Cling also hijacks wget by moving the legitimate binary to wget.r, storing the original location in wget.p, and replacing the original executable with itself. Each later invocation of wget can therefore relaunch the malware before the legitimate utility is called.

Cling’s most distinctive capability is its STUN-based C2 channel. STUN normally helps applications discover their externally mapped IP addresses and ports for NAT traversal, and is widely used by WebRTC, Microsoft Teams, Zoom, Cisco Webex, ICE, TURN, and SIP applications.

This makes STUN traffic less likely to immediately attract attention in enterprise or consumer networks. The bot sends STUN Binding Requests to 13 public STUN servers roughly every five seconds, but uses an all-zero transaction ID rather than the random identifier expected under RFC 8489.

It records the external ports returned by the servers, transmits a custom registration datagram containing those ports and an infection tag, and waits for commands delivered through UDP packets.

Nozomi researchers identified 145.249.115[.]184:3478 as a likely operator-controlled or colluding STUN server. Controlled registration experiments showed that ports advertised only to that host later received C2 instructions.

The malware stores commands and parameters inside the 12-byte STUN transaction ID field, enabling payload downloads, internet scanning, exploitation of new devices, TCP tunneling, proxy relaying, and denial-of-service floods.

Some command packets appeared to originate from 74.125.250[.]129, associated with stun.l.google.com. Researchers said the behavior was likely UDP source-address spoofing rather than traffic generated by Google’s infrastructure, supported by differences in IP TTL values between legitimate STUN responses and malicious command packets.

Defenders should patch or isolate devices exposed to CVE-2021-35394, reduce unnecessary internet exposure, and monitor for repeated STUN Binding Requests with all-zero transaction IDs.

Security teams should also hunt embedded Linux systems for .cling, wget.r, wget.p, altered wget binaries, and unexpected modifications to init scripts.

Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

Cut every SOC alert investigation by 21 min. Power your SOC with instant IOC context for immediate response: Integrate TI Lookup in your SOC