Cling IoT Botnet Hides C2 Traffic Inside Google-Like STUN Communications

Severity

Medium

A newly identified IoT botnet known as Cling is using the STUN protocol to disguise its command-and-control (C2) traffic as legitimate network communication. The technique allows attackers to remotely control compromised internet-facing devices while making the traffic resemble normal STUN activity commonly used by real-time communication applications.

The campaign was identified by Nozomi Networks Labs while investigating exploitation attempts against CVE-2021-35394, a critical remote code execution vulnerability in the Realtek Jungle SDK diagnostic component commonly exposed as UDPServer. The vulnerability affects Realtek Jungle SDK versions 2.0 through 3.4.14B and allows unauthenticated attackers to execute commands on exposed devices.

How?

Attackers exploit CVE-2021-35394 by sending specially crafted UDP packets beginning with orf;, followed by shell commands. Observed payloads use BusyBox wget to download the Cling malware, make it executable, and launch it with an infection tag such as realtek.selfrep.

After gaining access, Cling can spread to additional vulnerable devices by using embedded exploits targeting various routers, DVRs, cameras, and other embedded systems, including equipment from Realtek, LB-LINK, TBK, Linksys, Eir, FiberHome, and MVPower. GBHackers Security

Cling establishes persistence by placing copies of itself at /root/.cling and /usr/local/bin/.cling. It also modifies system startup files such as /etc/inittab, /etc/init.d/rcS, and /etc/rc.d/rc.boot so the malware can restart after the device reboots.

The malware also replaces the legitimate wget utility with itself. The original wget binary is renamed and stored separately, allowing Cling to execute whenever the wget command is used before passing the request to the legitimate utility.

The most notable feature is Cling’s use of STUN for C2 communication. STUN is normally used to determine a device’s public IP address and port for NAT traversal and is commonly used by applications such as WebRTC, Microsoft Teams, Zoom, Cisco Webex, and other real-time communication services.

Cling sends STUN Binding Requests to 13 public STUN servers approximately every five seconds. However, instead of using the random transaction identifiers normally expected by the STUN protocol, the malware uses an all-zero transaction ID.

The malware records the external ports returned by these servers and sends a custom registration packet containing the collected port information and infection tag. It then waits for commands delivered through UDP packets.

Researchers identified 145.249.115[.]184:3478 as a likely attacker-controlled or colluding STUN server. Cling stores commands and parameters inside the 12-byte STUN transaction ID field, allowing the attackers to instruct compromised devices to download additional payloads, scan the internet, exploit other vulnerable devices, create TCP tunnels, act as proxies, and conduct denial-of-service attacks.

Some malicious command packets appeared to originate from 74.125.250[.]129, an address associated with Google’s stun.l.google.com. However, researchers believe this is likely the result of UDP source-address spoofing rather than Google’s infrastructure being compromised. Differences in IP TTL values between legitimate STUN responses and the malicious packets supported this assessment.

IOCs

IOC Type	Indicator	Description
SHA-1 hash	3b0ac6aaabb3bf8058ca14f9c8ccc613cfa3ea71	Cling malware sample targeting MIPS-based devices
SHA-1 hash	08636d09d9ffd1713bd6bcb965ad40b6ce3de1aa	Related Cling malware sample targeting MIPS-based devices
Loader URL	hxxp://118.45.196[.]225:800/mipsel	Loader host serving a MIPSEL payload
Loader URL	hxxp://120.193.219[.]210:800/mipsel	Loader host serving a MIPSEL payload
Loader URL	hxxp://58.211.144[.]243:800/mipsel	Loader host serving a MIPSEL payload
IP address	145.249.115[.]184	STUN server identified as a suspected colluding server in Cling’s registration and command-delivery workflow
File path	/usr/local/bin/.cling	Cling executable copy used for persistence
File path	/root/.cling	Cling executable copy used for persistence
File path	/usr/bin/wget.r	Relocated legitimate wget binary after malware replacement
File path	/usr/bin/wget.p	File storing the path to the relocated legitimate wget binary
File path	/bin/wget.r	Relocated legitimate wget binary after malware replacement
File path	/bin/wget.p	File storing the path to the relocated legitimate wget binary
File path	/usr/local/bin/wget.r	Relocated legitimate wget binary after malware replacement
File path	/usr/local/bin/wget.p	File storing the path to the relocated legitimate wget binary
File path	/sbin/wget.r	Relocated legitimate wget binary after malware replacement
File path	/sbin/wget.p	File storing the path to the relocated legitimate wget binary
File path	/usr/sbin/wget.r	Relocated legitimate wget binary after malware replacement
File path	/usr/sbin/wget.p	File storing the path to the relocated legitimate wget binary

Conclusion

Cling demonstrates how IoT malware can abuse legitimate network protocols to make malicious C2 traffic harder to distinguish from normal communications. By combining exploitation of exposed devices with STUN-based C2, self-propagation, and persistence mechanisms, the botnet can maintain control of compromised IoT infrastructure while reducing the visibility of its network activity.

Source

https://gbhackers.com/cling-malware-masquerades-as-google-stun-traffic/