Cling Malware: A Covert IoT Botnet Disguised as Google STUN Traffic
A newly identified Internet of Things (IoT) botnet, named Cling, has been raising considerable concern among cybersecurity experts. This botnet employs stealth tactics by disguising its command-and-control (C2) communications as legitimate Session Traversal Utilities for NAT (STUN) traffic. Specifically, packets associated with Cling mimic those that appear to originate from Google’s public STUN infrastructure.
This innovative technique enables attackers to manage compromised internet-facing devices without attracting undue attention. By blending their malicious activity into the routine NAT-traversal traffic typically used by platforms facilitating real-time communications, attackers can operate in a more discreet manner.
The campaign’s discovery was made by Nozomi Networks Labs during their investigation into an alarming increase in exploitation attempts targeting a critical remote code execution vulnerability identified as CVE-2021-35394. This flaw resides in the Realtek Jungle SDK diagnostic component, which is commonly compiled under the name UDPServer. The vulnerability is especially severe as it affects Realtek Jungle SDK versions ranging from 2.0 to 3.4.14B, allowing unauthenticated remote attackers to execute arbitrary commands on exposed devices.
Attackers exploit this vulnerability by sending User Datagram Protocol (UDP) packets that begin with the string orf;, followed by the shell commands intended for execution. In observed attacks, the payload typically employs BusyBox’s wget command to retrieve a malicious binary. After downloading, the malware makes the binary executable and subsequently launches it—with an infection-method tag like realtek.selfrep.
Once established, the Cling malware doesn’t stop at compromising the initially targeted device. It actively searches for additional vulnerable hardware by employing embedded exploits targeting various devices, including Realtek components, LB-LINK routers, TBK DVRs, Linksys equipment, Eir routers, FiberHome devices, and MVPower CCTV DVRs.
To ensure persistence, Cling copies itself into two locations on the infected device: /root/.cling and /usr/local/bin/.cling. Furthermore, it alters startup entries within critical system files, including /etc/inittab, /etc/init.d/rcS, and /etc/rc.d/rc.boot. This manipulation allows the malware to maintain control even after the device is rebooted.
An intriguing aspect of Cling’s operation is its method of hijacking the legitimate wget utility. It achieves this by relocating the original wget binary to wget.r, storing the original path in a file named wget.p, and then replacing wget with its malicious version. Consequently, every invocation of wget can lead to the malware being relaunched before the original utility is executed, ensuring that the compromised device remains under control.
Cling’s most distinctive and alarming capability is its use of STUN for establishing a C2 communication channel. Normally, STUN assists applications in discovering their externally mapped IP addresses and port numbers for NAT traversal, commonly utilized in applications like WebRTC, Microsoft Teams, Zoom, Cisco Webex, ICE, TURN, and various SIP applications. Given the widespread use of STUN, such traffic tends to be less scrutinized in both enterprise and consumer networks.
As part of its strategy, the botnet sends STUN Binding Requests to 13 public STUN servers approximately every five seconds. However, it does so using an all-zero transaction ID, which deviates from the random identifier typically expected as per RFC 8489. This behavior could lead researchers and security teams to overlook the payload as it masquerades as standard STUN traffic.
In their analysis, Nozomi researchers pinpointed IP address 145.249.115[.]184:3478 as a likely operator-controlled STUN server. Controlled registration experiments revealed that the ports advertised to this server subsequently received C2 instructions. Moreover, Cling stores commands and parameters within the 12-byte STUN transaction ID field, allowing for diverse operations such as payload downloads, internet scanning, exploration of other devices, TCP tunneling, proxy relaying, and even denial-of-service attacks.
Some packets observed in this complex network of command deliveries appeared to spoof IP address 74.125.250[.]129, associated with stun.l.google.com. Researchers suspect this was not legitimate traffic but rather UDP source-address spoofing. The differences in IP Time To Live (TTL) values between genuine STUN responses and the malicious command packets further support this hypothesis.
To combat the threat posed by Cling, defenders are urged to patch or isolate devices vulnerable to CVE-2021-35394, reduce unintended internet exposure, and monitor for repeated STUN Binding Requests with all-zero transaction IDs. Security teams should undertake thorough searches of embedded Linux systems for indicators related to Cling, including the presence of .cling, wget.r, wget.p, modified wget binaries, and any unexpected alterations to system initialization scripts.
As IoT devices become more prevalent and essential in daily operations, the threat represented by botnets like Cling signifies an evolving landscape in cybersecurity, one that necessitates constant vigilance and proactive defense strategies.