Cling is an IoT botnet whose analyzed sample used STUN-like traffic to register compromised devices and deliver commands. Nozomi Networks Labs reported that command packets appeared to come from an IP address resolving to Google’s public STUN service, but assessed UDP source-address spoofing—not Google’s participation—as the most likely explanation. The report does not establish that Google was hacked or knowingly relayed commands.
What Cling is, and what researchers observed
Nozomi Networks Labs published its technical analysis on October 1, 2026, after finding related activity in customer telemetry. Its investigation focused primarily on a MIPS sample with SHA-1 hash 3b0ac6aaabb3bf8058ca14f9c8ccc613cfa3ea71. The report describes that sample and related observations; it does not give a victim count or estimate how widespread Cling is.
In the activity it observed, Cling attempted to exploit CVE-2021-35394, a remote-code-execution vulnerability in the Realtek Jungle SDK diagnostic component often compiled as UDPServer. The captured payload began with orf; and was followed by shell commands. One example used BusyBox wget to download a binary, make it executable, and run it with a replication-method argument.
Nozomi says affected SDK components appear in routers, access points, repeaters, and other appliances. The analyzed sample also contained exploit logic associated with LB-LINK, TBK DVR, Linksys, Eir D1000, FiberHome/China Mobile, and MVPower vulnerabilities. CVE-2021-35394 is therefore one reported route, not the only one; the report does not mean that every internet-exposed device, or every device from a named vendor, is vulnerable.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →#1 Best Overall
How the STUN-like command channel works
STUN, specified in IETF RFC 8489, helps an endpoint discover its public IP address and the port assigned by a network address translator (NAT). It is common in real-time communications and other NAT-traversal settings. Cling repurposes parts of that familiar exchange for bot registration and command delivery.
Registration and mapped ports
In the analyzed sample, the bot periodically sent STUN Binding Requests to a hardcoded list of 13 STUN servers, approximately every five seconds. The requests used all-zero transaction IDs. The bot recorded the externally observed ports returned in responses and sent custom registration datagrams containing mapped ports and an infection-method tag. Those registration datagrams were not conforming STUN messages; Nozomi says conforming servers ignored them in its testing.
Rank #2
Commands in transaction-ID bytes
The bot then waited for UDP packets addressed to its mapped ports. Operators could encode commands in the 12-byte STUN transaction ID field. The key distinction is that STUN supplies a familiar-looking context, while the command-bearing packets and custom registration messages are not simply ordinary, valid STUN exchanges.
What the controlled test showed
Nozomi compared responses from the listed servers and found one that returned an all-zero transaction ID instead of echoing the request ID. In a controlled test, researchers advertised different port sets to different servers; several hours later, a port advertised only to 145.249.115[.]184 received commands. They identified that host as involved in the botnet’s C2 activity based on this test. That is the researchers’ finding, not independent confirmation of who owned or operated the infrastructure.
Why the packets looked like Google traffic—and what that does not prove
Nozomi reported that the source IP address on command packets was 74.125.250[.]129, which resolves to stun.l.google.com. An address resolving to Google’s public STUN service is not, by itself, proof that Google sent or relayed a packet. The researchers said they knew of no legitimate mechanism that would make a STUN server relay a chosen transaction ID, and judged UDP source-address spoofing the most likely explanation. They also noted consistent TTL differences between legitimate STUN responses and the command packets.
That assessment does not establish where spoofed packets originated or prove the exact method used. It does make the headline distinction important: the traffic appeared to have a Google STUN source address; the report does not show that Google was compromised, involved, or knowingly used as a command relay.
Rank #4
Nozomi summarized the technique this way: “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 Labs, October 1, 2026.
What the analyzed sample could do
The following are capabilities reported for the analyzed sample, not a guarantee that every Cling variant supports or uses each one.
| Capability | Reported use |
|---|---|
| Execute a payload | Run a downloaded payload on the compromised device. |
| Propagate | Scan for and exploit other systems; the report also observed self-propagation commands. |
| Manage scanning | Start or stop the scanner. |
| Relay traffic | Start or stop a TCP tunnel, or start or stop a proxy relay. |
| Flood a target | Carry out a denial-of-service flood against a specified target for a set duration. Nozomi observed flood instructions, including instructions naming four IP-and-port targets; those instructions do not establish that attacks succeeded. |
Persistence artifacts to check on embedded Linux devices
In the analyzed sample, persistence included copies at /root/.cling and /usr/local/bin/.cling, plus references added to SysV/BusyBox initialization files. The sample also used a wget replacement arrangement: it moved the genuine utility to wget.r, recorded its location in wget.p, and replaced wget with itself. When invoked, the replacement could re-execute the malware and then call the original utility.
These are sample-specific hunting leads, not proof that every infection will leave every artifact. Embedded devices may provide limited host telemetry, so network monitoring can be important alongside any filesystem or startup-script checks available to responders.
How to reduce exposure and investigate suspicious activity
Reduce the chance of compromise
- Inventory internet-facing routers, access points, DVRs, and embedded appliances, and identify whether they contain affected components.
- Apply vendor fixes where available. Reduce internet exposure and restrict inbound access to management and diagnostic interfaces to the networks and users that need them.
- Where a device cannot be patched, isolate it from less-trusted networks and limit its allowed communications. NIST SP 1800-15 describes Manufacturer Usage Description (MUD) as a way for a network to permit only communications an IoT device needs for its intended function and prohibit other traffic. This is general IoT security guidance, not a Cling-specific fix, and support depends on the network equipment and implementation.
Look for network behavior that merits investigation
- Repeated STUN Binding Requests with all-zero transaction IDs.
- Non-STUN UDP datagrams sent to STUN endpoints.
- STUN or other outbound UDP activity that differs from the device’s normal baseline.
These behaviors are indicators to investigate, not conclusive proof of Cling on their own. Validate an indicator against the asset’s expected role and surrounding evidence before blocking it; legitimate applications can also use STUN.
Quick Recap
Check host evidence and contain carefully
- On an affected or suspected embedded Linux device, check for the reported
.clingcopies, altered SysV/BusyBox startup files, and thewget.randwget.pcompanion files. - Correlate host findings with device identity, outbound traffic, and any available network logs. Preserve relevant evidence before making changes if an incident investigation is underway.
- Restrict the device’s network access while assessing it, then patch or replace it as appropriate. Network segmentation can limit exposure and traffic, but it does not remove malware from an infected device.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
