Nozomi Networks Labs has identified a botnet dubbed Cling that exploits internet-exposed IoT and networking devices and disguises its command-and-control traffic as legitimate STUN activity. Researchers said the malware was observed exploiting CVE-2021-35394, a remote code execution flaw in the Realtek Jungle SDK diagnostic component used across routers, access points, repeaters and other appliances. Interestingly, Cling also contains exploit code for several other command-injection vulnerabilities affecting routers and DVRs, allowing compromised devices to scan for and infect additional vulnerable systems.
Cling’s command-and-control design uses STUN-like exchanges to register infected devices and deliver operator commands, allowing the traffic to resemble normal NAT-traversal activity commonly generated by collaboration tools, browsers and real-time communications applications.
Nozomi said the malware encodes commands in STUN transaction IDs and, in observed activity, commands appeared to originate from an IP address associated with Google’s stun.l.google.com, making the traffic harder to distinguish from legitimate infrastructure. Researchers observed commands for further propagation, TCP tunneling, proxying and denial-of-service attacks, including floods against targets in South Korea and the U.S.
“We constantly monitor anonymized telemetry from sensors deployed in customer networks around the world. This visibility helps us track exploitation trends and identify cases where routine-looking activity leads to more interesting malware behavior,” Nozomi researchers detailed in a post last week. “In this case, we noticed a spike in attempts to exploit CVE-2021-35394, a remote code execution vulnerability affecting the Realtek Jungle SDK diagnostic component commonly compiled as UDPServer. Despite being a few years old, this vulnerability is widely abused in the wild because affected SDK components are embedded across many IoT and networking devices, including routers, access points, repeaters and other appliances, which often do not receive updates and remain unpatched and vulnerable for years.”
They added that most of these hits were consistent with opportunistic probing commonly seen around older but still-exploited IoT vulnerabilities. However, a subset of the activity stood out because the exploitation chain retrieved and executed a malware sample that did not follow the typical communication patterns associated with Mirai-like botnets.
STUN, defined in RFC-8489, is a protocol used to support NAT traversal by allowing an endpoint to discover its public IP address and NAT-mapped port. It is commonly used as part of protocols and frameworks such as ICE, TURN, SIP, and real-time communication applications. As a result, STUN and related ICE/TURN traffic is common in enterprise networks, especially from applications such as Microsoft Teams, Zoom, Cisco Webex, and WebRTC-based browser applications.
Nozomi’s analysis focused primarily on the MIPS sample, with supporting observations from related samples in the same activity cluster. Unless otherwise noted, the persistence, STUN C2, and command behavior.
The researchers found embedded exploit logic for several additional command-injection vulnerabilities, namely the Realtek SDK RCE (CVE-2014-8361), the LB-LINK routers RCE (CVE-2023-26801), the TBK DVR RCE (CVE-2024-3721), the Linksys RCE (CVE-2025-34037), the Eir D1000 router RCE (CVE-2016-10372), the FiberHome SR1041F router and China Mobile HG6543C4 RCE (CVE-2023-41011), and the MVPower CCTV DVR RCE (CVE-2016-20016).
The post mentioned that the Cling botnet uses traffic that looks like routine activity from public STUN servers, the kind of servers normally used to help devices work out their internet address. Infected devices regularly contact a hardcoded list of 13 such servers, most of which have clean reputations and appear on public lists. They then send each server a custom registration message that reveals how they were infected and where the operator can reach them. Afterward, the bot waits for commands from the operator. To a network monitor, the whole exchange looks harmless.
Because the registration message goes to every server on the list, the researchers reasoned that the operator must be able to see activity on at least one of them to track new bots and know where to send commands. They tested how all 13 servers responded to controlled requests, and one behaved differently from the rest, matching the quirk in the bot’s own traffic. That suggested the server was tailored to the botnet rather than being a genuine public service.
To confirm this, the researchers wrote a client posing as a newly infected device and gave each server a different set of details. Several hours later, the operator’s commands arrived at one of the details advertised only to the suspect server (145.249.115[.]184). This confirmed that the server was controlled by, or working with, the botnet operator.
The researchers monitored the botnet’s command traffic for several days. During that time, the operator repeatedly tasked infected devices with spreading across the internet by scanning for and attacking vulnerable systems. The bots were also told to launch flooding attacks against four targets: a South Korean internet service provider, a University of Chicago cluster, and two Minecraft servers.
The most notable finding was where the commands appeared to come from. The packets carrying them appeared to originate from an IP address belonging to Google’s well-known STUN service, so the operator was disguising commands as replies from one of the most recognizable servers on the internet.
The researchers know of no legitimate way to make a STUN server relay specific commands. They believe the operator is instead spoofing the source address through a network provider that fails to validate source addresses, and consistent differences in packet lifetime values between genuine replies and command-bearing ones support this. The tactic matters because defenders and firewalls tend to trust traffic from high-reputation infrastructure. A packet from an unknown host would raise suspicion, but the same packet appearing to come from Google is far easier to dismiss as background noise.
Nozomi detailed that organizations should start by reviewing their exposed IoT and networking devices, identifying internet-facing routers, access points, DVRs, and embedded appliances that may include vulnerable Realtek Jungle SDK components or other known command-injection flaws abused by the sample. It added that defenders should prioritize patching and exposure reduction, fixing devices affected by CVE-2021-35394 and the additional vulnerabilities listed in the propagation section. Where patching is not possible, Nozomi recommended restricting inbound access, removing unnecessary internet exposure, and placing devices in segmented network zones.
The company also advised hunting for suspicious connection patterns, such as repeated STUN Binding Requests sent at short intervals with the transaction ID set to all zeros, or non-STUN UDP datagrams sent to STUN endpoints. Assets should also be monitored for unexpected connections that deviate from the established baseline.
Nozomi noted that network-level monitoring is especially critical for embedded devices, where host telemetry is often limited or unavailable. Defenders should additionally check for compromised-device artifacts, including malware copies named .cling, persistence entries added to init scripts, and replaced wget binaries with companion wget.r and wget.p files. Finally, Nozomi recommended operationalizing the indicators of compromise and ATT&CK mapping to build detections, validate telemetry coverage, and support targeted hunting for Cling-like activity.
In conclusion, the Nozomi researchers identified that Cling shows how commodity IoT botnets are evolving beyond familiar Mirai-like patterns. Although Cling still spreads through exposed devices and command-injection vulnerabilities, its STUN-based command-and-control design sets it apart by making infected hosts communicate in ways that resemble legitimate NAT-traversal traffic.
“This abuse of STUN is effective because the surrounding traffic can blend into environments where collaboration tools, browsers, and real-time communication applications already generate legitimate STUN activity,” according to the post. “At the same time, the implementation choices observed in Cling create useful opportunities for detection: repeated Binding Requests with all-zero transaction IDs, custom UDP registration datagrams sent to the same STUN hosts, a non-conforming STUN server implementation, and host artifacts such as .cling copies or replaced wget binaries.”
The researchers suggested that for defenders, the main takeaway is that reputation alone is not enough when malware deliberately shapes its traffic around legitimate infrastructure or widely used protocols. Just as importantly, unpatched internet-facing devices should be treated as potential entry points into the wider network, not isolated edge systems. Monitoring should combine protocol-aware inspection, behavioral baselining, exposure reduction, and endpoint indicators so that suspicious deviations inside otherwise common traffic patterns are not missed.
Recently, Nozomi Networks Labs published research on weaknesses in industrial edge and field devices. It reported 12 vulnerabilities in the Siemens SCALANCE LPE9403 Local Processing Engine, an edge PC used in OT environments to aggregate telemetry and forward it to SCADA systems. Several of the flaws can be chained to give an attacker root-level control, which could let them manipulate telemetry, suppress alarms, or disrupt services.
Also, Nozomi disclosed 19 vulnerabilities in the Pepperl+Fuchs IO-Link Master ICE2-8IOL-K45P-RJ45, a device that links field-level sensors and actuators to higher-level industrial control systems. They include an authentication bypass and multiple OS command injection flaws that can execute commands with root privileges. Both findings show how a single compromised device sitting between field equipment and control systems can affect process visibility and control.
