Ravie LakshmananOct 05, 2026Vulnerability / Malware
Threat actors have been observed attempting to exploit a now-patched critical security flaw impacting the Realtek Jungle software development kit (SDK) to deploy a botnet malware called Cling.
“Cling is notable not because it introduces a new propagation technique, but because it repurposes ordinary STUN behavior into a practical command-and-control channel,” Nozomi Networks said in a report published last week. “The result is a botnet whose traffic can resemble legitimate NAT-traversal activity while still supporting propagation, proxying, tunneling and denial-of-service commands.”
The operational technology (OT) security company said it observed a spike in attempts to exploit CVE-2021-35394 (CVSS score: 9.8), a critical remote code execution (RCE) flaw in Realtek Jungle SDK starting around September 5, 2026, with a subset of the activity delivering Cling.
An analysis of the malware sample has found it to embed exploit logic for various command injection and RCE vulnerabilities impacting routers and DVRs from multiple vendors –
- Realtek SDK RCE (CVE-2014-8361)
- Eir D1000 router RCE (CVE-2016-10372)
- MVPower CCTV DVR RCE (CVE-2016-20016)
- LB-LINK routers RCE (CVE-2023-26801)
- FiberHome SR1041F router / China Mobile HG6543C4 RCE (CVE-2023-41011)
- TBK DVR RCE (CVE-2024-3721)
- Linksys RCE (CVE-2025-34037)
“The single-instance check to only run one copy involves binding a socket with SO_REUSEADDR to port 33957 and exiting cleanly if it fails,” Nozomi Networks said. “The sample copies itself to /root/.cling and /usr/local/bin/.cling. Both executables are appended to /etc/inittab, /etc/init.d/rcS, /etc/rc.d/rc.boot, thus achieving persistence on SysV and BusyBox init systems.”
An alternative persistence mechanism involves identifying the wget binary on the infected system and then replacing it with the malware, but not before moving the original to another location. This, in turn, causes the malware to be executed when a legitimate process invokes the “wget” command.
A notable aspect of Cling is its abuse of harmless-looking STUN traffic and public STUN infrastructure to register infected hosts, receive operator commands, and make malicious activity less obvious from a network monitoring perspective.
STUN, short for Session Traversal Utilities for Network Address Translation (NAT), is a standardized network protocol that’s designed to assist devices behind a NAT or firewall in establishing peer-to-peer real-time communications.
Specifically, the malware follows a four-step process for command-and-control (C2) communications –
- Send a STUN Binding Request to a hard-coded list of 13 STUN servers roughly every 5 seconds. The transaction ID is set to all zeros instead of a random value, as per the specification.
- Record the externally observed ports returned by those servers upon receiving a Binding Success Response message containing the public IP address of the endpoint and the associated port numbers.
- Sends a custom registration message (i.e., a UDP datagram) to each server that includes the mapped ports and a tag denoting how the device was infected (e.g., realtek.selfrep, selfrep.router).
- Poll for UDP packets that encode operator commands in the STUN transaction ID field.
“From a network monitoring perspective, the activity appears as innocuous interaction with STUN servers,” Nozomi Networks said. “Given that the custom registration message is sent to every STUN server in the list, it is apparent that the operator requires visibility into at least one of the servers, in order to track new bots joining the swarm to know where to send commands to.”
It’s worth noting these registration messages do not conform to the STUN protocol definition, causing legitimate STUN servers to drop the packet. However, one of the 13 servers (“145.249.115[.]184”) is said to have returned an all-zero transaction ID instead of echoing the transaction ID of the original Binding Request in the Binding Success Response.
This unusual behavior, per Nozomi, suggests the STUN server is tailored to the bot’s own STUN traffic and that it’s used to send operator-issued commands to the infected device by embedding them within the STUN transaction ID field.
The commands allow the threat actor to recursively scan and spread the scale of the botnet in a worm-like fashion, spawn/stop a TCP tunnel, launch/stop a proxy, and perform a denial-of-service (DoS) attack against a specified target for a given time duration. Some of the targets of the flooding attacks are below –
- 112.151.157[.]222:8080 (South Korean ISP)
- 192.170.240[.]137:53 (University of Chicago cluster)
- 23.81.40[.]193:25565 (Minecraft)
- 147.185.221[.]129:25565 (Minecraft)
“The most interesting part of the C2 traffic is where the commands appeared to come from,” Nozomi Networks explained. “The packets carrying operator commands originate from 74.125.250[.]129, an IP address that stun.l.google.com resolves to.”
“In other words, the operator is not merely hiding commands inside a STUN-looking packet, but they are making those commands appear as if they are legitimate replies from one of the most recognizable STUN services on the internet.”
Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.