What happened
Researchers have identified a new IoT botnet, tracked as Cling, that conceals its command-and-control (C2) channel inside traffic designed to look like responses from Google's public STUN (Session Traversal Utilities for NAT) service — the same protocol video-calling apps and browsers use every day to find a device's public IP address and port. Because STUN exchanges are routine background noise on most networks, Cling's fake registration and command traffic blends in with legitimate activity instead of triggering alerts.
Cling spreads by exploiting known, unpatched vulnerabilities in internet-exposed routers, access points, repeaters, and video-recording equipment that run vulnerable Realtek SDK code, most notably CVE-2021-35394. Analysts also found exploit code for several other CVEs bundled into the sample, extending the malware's reach across a wide range of consumer and small-business network gear.
How the disguise works
STUN itself is harmless — it just tells a device its public IP and port so two systems can connect across NAT. Cling abuses that trust. Once it infects a device, it contacts 13 hardcoded STUN servers roughly every five seconds, collects the ports those services report back, and then sends a second, non-standard message: a "registration" packet that reports the mapped ports along with a tag describing how the device was compromised.
Most of the 13 servers simply ignore that bogus registration traffic — but researchers found one that didn't. It returned a malformed reply that failed to properly echo the request identifier, a telltale sign something unusual was happening. By feeding that one server a unique set of ports under controlled testing, researchers confirmed commands were arriving back at exactly those ports hours later — proof the "STUN" server was actually relaying instructions to infected devices. The operator hides those commands inside the 12-byte field STUN normally uses to match requests to replies.
The packets carrying commands even appeared to originate from Google's real STUN infrastructure. Researchers assess this is most likely IP spoofing rather than any compromise of Google's servers — packet lifetime values differed from genuine Google traffic, and there is no evidence Google's infrastructure was involved or compromised.
Why it matters
Once installed, Cling digs in: it copies itself to hidden locations, adds startup entries across multiple init mechanisms so it survives a reboot, and — in a particularly persistent move — replaces a device's standard download utility with a trojanized version that still performs the original function, meaning routine maintenance or future downloads can silently re-trigger the infection.
From there, infected devices become disposable infrastructure for the botnet's operator: pulling down additional payloads, relaying traffic, opening tunnels, running as proxies, or launching denial-of-service floods on command. Researchers observed attack instructions aimed at an internet provider, a university network, and gaming services, though no confirmed outage or total infection count has been published. The pattern echoes other recent IoT botnets that turn compromised edge devices into attacker-controlled proxy networks.
What to do
- Patch exposed devices. Prioritize routers, access points, repeaters, and IP cameras built on Realtek SDK code, especially anything still vulnerable to CVE-2021-35394 or the other CVEs bundled in this sample.
- Restrict inbound access to management interfaces on devices that can't be patched immediately, and segment IoT/edge devices away from critical network segments.
- Watch for the anomaly, not just the destination. Legitimate-looking traffic to a trusted service like Google STUN isn't automatically safe — flag frequent STUN requests with all-zero transaction identifiers, unexpected UDP "registration" messages, and devices that deviate from their normal communication baseline.
- Audit startup configuration and core utilities (init scripts, rc files, download tools) on exposed devices for unauthorized modifications, which can indicate persistence even after a reboot.