- Nozomi Networks found the Cling botnet spreading through CVE-2021-35394, a Realtek Jungle SDK flaw, and sending commands that appear to come from a Google STUN address.
- Many teams wave through traffic from well-known addresses. Nozomi says reputation alone is not enough when malware shapes its traffic around trusted services.
- Inventory exposed routers and DVRs, patch them or limit access, and add checks for odd STUN behavior and Cling's file traces.
A famous name gets less scrutiny
Security teams cannot inspect every packet. They lean on shortcuts, and one common shortcut is reputation: traffic from a well-known service is assumed to be routine. A botnet called Cling is built to exploit that habit.
The lesson here is that a trusted address is a claim, not proof. Cling's operator appears to be borrowing Google's name so that orders to infected devices read as background noise.
What Nozomi Networks found
Nozomi's researchers watch anonymized telemetry from sensors in customer networks. Those sensors recorded a jump in attacks on CVE-2021-35394. The flaw lets an attacker run commands remotely on a device through a diagnostic service in the Realtek Jungle SDK, a software kit that device makers build into their products. Nozomi says that service is commonly compiled as UDPServer. The Hacker News reports the spike began around September 5, 2026.
The SDK is embedded in routers, access points, repeaters and other appliances. Nozomi says these devices often go unpatched for years. Most of the activity looked like opportunistic probing. A smaller subset delivered Cling.
How the infection works
The attacker sends a UDP packet that starts with "orf;" followed by shell commands. The vulnerable device runs them. In the captured attempt, the device used BusyBox wget to download a program, marked it executable and ran it.
Nozomi stresses that Cling brings no new way of spreading. The sample also carries exploits for other flaws, including CVE-2023-41011 in a FiberHome SR1041F router and China Mobile HG6543C4.
It is built to stay. It copies itself to hidden .cling files and adds them to startup files, so it survives a reboot. It also swaps the system's wget tool for itself and keeps the original as wget.r. Any later call to wget, even from a routine job, restarts the malware.
How the Google disguise works
STUN is a standard protocol that lets a device learn its public address and port. Teams, Zoom, Webex and browser-based calls use it, so it is common in company networks.
Cling's bot sends STUN requests to a hardcoded list of public STUN servers. The servers reply with the bot's public port. The bot then sends each server a custom registration message and waits. Commands arrive in a field called the transaction ID, which is normally a random value.
To a network monitor, this looks like harmless contact with STUN servers. Nozomi notes the registration message sits outside the STUN definition, so proper servers ignore it.
How the researchers found the control server
Nozomi sent controlled test requests to all 13 servers and compared the replies. A well-behaved server copies the request's ID straight back. One server, 145.249.115[.]184, sent back zeros. The bot's own requests also use zeros, so Nozomi suspected that server was tailored to the botnet.
The team then posed as an infected device and told each server a different set of ports. Several hours later, commands reached a port advertised only to the suspect server. Over several days, Nozomi saw orders to spread to other vulnerable systems and to flood targets.
Why the source address matters
The command packets carried the sender address 74.125.250[.]129. That is an address stun.l.google.com resolves to. Nozomi says it knows of no legitimate way to make a STUN server relay a chosen transaction ID.
Its most likely explanation is forged sender addresses. The operator may use a network that does not check them. Think of a letter with a bank's return address written in by the sender. Differences in packet TTL values between real replies and command packets support this view.
If the addresses are forged, Google's servers need not be compromised. That is our inference, not a finding from Nozomi.
Nozomi describes the effect on the analyst on shift. An odd packet from an unfamiliar address is suspicious. The same packet apparently from Google STUN is easier to dismiss as background noise.
One limit applies. Nozomi's analysis focused mainly on one MIPS sample, with supporting observations from related samples.
What to ask your team
First, do we know which internet-facing routers, access points and DVRs run Realtek Jungle SDK components? Patch CVE-2021-35394 and the other flaws Nozomi lists. If a device cannot be patched, cut its exposure to the internet and place it in a separate network zone.
Second, can our monitoring flag repeated STUN requests with all-zero transaction IDs, or non-STUN UDP sent to STUN servers? Nozomi's point is that these devices often give little data from the device itself, so the network is where to watch them.
Third, do our rules treat traffic from well-known addresses as safe by default? And can we search for .cling files and wget.r and wget.p files on devices?
A famous return address is not an identity. Judge the behavior, not only the name.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Nozomi Networks.
