Skip to content
hacker_posts

Cling botnet hides C2 in STUN traffic, spreads via Realtek SDK flaw

Nozomi Networks says the Cling botnet rides a spike in CVE-2021-35394 Realtek SDK exploitation and tunnels its command channel through 13 public STUN servers to blend into normal traffic.

Published 3 min read
botnetiotcvethreat-intel

A Linux IoT botnet tracked as Cling is spreading through renewed exploitation of a four-year-old Realtek flaw and disguising its command-and-control as ordinary STUN traffic. Nozomi Networks, which named and analyzed the malware, says the C2 channel is the point of interest: Cling repurposes public STUN infrastructure — the same NAT-traversal protocol WebRTC and VoIP clients use — into a covert operator channel that is hard to spot on a flow record.

How it spreads

Nozomi observed a spike around September 5, 2026 in attempts to exploit CVE-2021-35394 (CVSS 9.8), a remote code execution flaw in the Realtek Jungle SDK that affects a long tail of consumer routers and IoT devices built on Realtek chipsets. The exploit sends a UDP packet beginning with orf; followed by shell commands; in observed attacks the payload used BusyBox wget to pull a binary, mark it executable, and launch it with an infection tag such as realtek.selfrep.

Once resident, Cling carries embedded exploits to self-propagate to other vulnerable hardware. Per Nozomi, the targeted flaws span multiple vendors:

CVE-2014-8361   Realtek SDK (miniigd SOAP) RCE
CVE-2016-10372  Eir D1000 router
CVE-2016-20016  MVPower CCTV DVR (JAWS)
CVE-2023-26801  LB-LINK routers
CVE-2023-41011  FiberHome / China Mobile devices
CVE-2024-3721   TBK DVR
CVE-2025-34037  Linksys devices

The STUN C2 trick

The malware sends STUN Binding Requests to 13 hardcoded public STUN servers roughly every five seconds. Rather than reaching an attacker-owned C2 directly, it uses the STUN exchange to register the infected host, learn its externally visible address, and poll for operator commands. Nozomi notes one network-detection tell: the bot uses an all-zero transaction ID in its STUN requests, rather than the random identifier RFC 8489 specifies — legitimate STUN clients randomize that field.

For persistence, the sample copies itself to /root/.cling and /usr/local/bin/.cling and appends both paths to /etc/inittab, /etc/init.d/rcS, and /etc/rc.d/rc.boot, covering SysV and BusyBox init systems.

Action checklist

  1. Patch or retire Realtek-SDK devices. CVE-2021-35394 was fixed upstream in 2021; devices still exposed are long past due. Where no firmware update exists, pull the device off any untrusted network.
  2. Block inbound exploit traffic to the affected services and restrict device management interfaces to trusted segments.
  3. Hunt for anomalous STUN: outbound STUN Binding Requests from embedded devices on a fixed ~5-second cadence, and STUN packets with an all-zero transaction ID, are strong leads per Nozomi.
  4. Check for the persistence artifacts — /root/.cling, /usr/local/bin/.cling, and additions to /etc/inittab, /etc/init.d/rcS, /etc/rc.d/rc.boot on Linux-based IoT hosts.

Context

Cling is the latest entry in a long line of Mirai-style IoT botnets that live off old, unpatched embedded flaws — CVE-2021-35394 has been a botnet staple since the year it was disclosed. What's worth flagging is the C2 design: abusing public STUN servers as a rendezvous layer is a credible evasion move, because STUN traffic to well-known resolvers looks benign to most network monitoring. Detection here leans on protocol-level anomalies, not destination reputation. Nozomi published the full analysis, including the behavioral indicators above; walk back to that writeup before building detections.

Related stories