ClingSTUN Backdoor Turns Unpatched IoT Devices Into Proxies Hidden in Public STUN Traffic

SINGAPORE - A Linux backdoor that turns unpatched routers, cameras and other internet-facing devices into remotely controlled proxy nodes is hiding its network traffic inside a protocol that video calls and web browsers use every day, according to research published on Monday by Fortinet's FortiGuard Labs. The malware, which FortiGuard calls ClingSTUN, leans on public STUN servers, which tell a device behind a router what its public address and port look like, so its keepalive traffic resembles ordinary VoIP and WebRTC sessions. For security operations teams, the research undercuts a familiar triage shortcut: trusting a connection because the server on the other end has a clean reputation.

FortiGuard analyst Vincent Li wrote that the campaign has run in three periods, each with its own download server, and gains a foothold through known, unpatched flaws. The first lasted two days and relied on a single command injection bug, CVE-2022-36553, in Hytec Inter HWL-2511-SS routers. The second added EnGenius and D-Link flaws, then command injection bugs in Linear, Realtek, TP-Link and AVTECH devices. By the third, FortiGuard's list had grown to 24 vulnerabilities, including the Ivanti Connect Secure pair CVE-2023-46805 and CVE-2024-21887 and flaws in Sunhillo, Lantronix and MeiG Smart equipment. "As we write this report, ClingSTUN continues to evolve," the company wrote. When SOCtember checked CISA's Known Exploited Vulnerabilities catalog on Tuesday morning, nine of the 24 were listed.

Once it lands, the malware behaves much like other IoT botnets, FortiGuard found. A downloader script in /tmp pulls builds for five processor families. The implant disables the watchdog timer, kills competing processes running from /tmp and /var/tmp, 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 so it starts at boot. It blanks its own command line and, when running as root, bind-mounts copies of process information from PID 1 over its own /proc entry so that it looks like the init process. It also carries hard-coded exploits for seven more vulnerabilities to spread on its own.

The network behavior is what sets it apart. ClingSTUN opens a UDP socket on a random port and sends standard 20-byte STUN binding requests to a list of public servers, 24 in the second version and 13 in the third, then periodically sends its group identifier and the list of mapped ports back to the same servers. "No separate coordination-server registration was identified in this path, and how the operator obtains the external mapping and delivers control traffic through NAT remains unverified," the report said. The implant listens for a 20-byte control packet that can trigger self-propagation or remote command execution, in which it opens an outbound TCP connection to an address named in the message, receives a command and runs it.

Nozomi Networks Labs, an operational technology security firm, published an analysis on October 1 of a botnet it calls Cling that appears to be the same family: both reports describe the same .cling file names and boot scripts, overlapping propagation exploits and overlapping STUN server addresses. Nozomi found it after a spike in attempts to exploit CVE-2021-35394, a Realtek Jungle SDK flaw, in its customer telemetry, and its work offers one answer to the question FortiGuard left open. The sample Nozomi studied sends binding requests about every five seconds to 13 servers with the transaction ID set to all zeros, which does not follow the STUN standard, and follows them with a custom registration message that carries an infection tag such as realtek.selfrep. When Nozomi fingerprinted the 13 servers, one, 145.249.115[.]184, answered with an all-zero transaction ID instead of echoing the request. The researchers then posed as an infected device and advertised different ports to each server; hours later, commands arrived on a port advertised only to that one.

Those commands were packed into the 12-byte transaction ID of what looked like a normal STUN reply, and the packets appeared to come from 74.125.250[.]129, an address that stun.l.google.com resolves to. Nozomi said the most likely explanation is source address spoofing from a network that does not validate source addresses, and that consistent differences in IP time-to-live values between real replies and command packets support that view. The command set covers payload execution, scanning, TCP tunnels, proxy relays and floods, and Nozomi received flood tasking against targets including a South Korean internet provider, a University of Chicago cluster and two Minecraft servers. "A UDP packet from an unfamiliar address carrying odd-looking bytes is suspicious; the same packet appearing to come from Google STUN after the infected host has already initiated STUN activity is much easier to dismiss as background NAT-traversal noise," Nozomi wrote.

For detection teams, the first lesson is what not to do. Li told Dark Reading that blocking public STUN servers indiscriminately could disrupt legitimate services, and collaboration tools depend on them. FortiGuard wrote that these services "should not be automatically classified as attacker-controlled infrastructure." The more useful signal is whether STUN traffic fits the device's role. Network sensors can flag routers, DVRs, cameras and other embedded devices that begin sending binding requests every few seconds to a dozen or more servers, requests with all-zero transaction IDs, non-STUN UDP payloads sent to ports 3478 and 19302, and supposed replies whose time-to-live values do not match earlier answers from the same server. A UDP packet followed by a new outbound TCP session or a burst of scanning from the same device deserves a look. Where teams can reach a device's shell, the host artifacts are concrete: .cling copies, new lines in the three boot scripts, wget.r and wget.p files left by the wget replacement Nozomi documented, and a process whose /proc entry mirrors PID 1. Nozomi published a YARA rule and indicators; FortiGuard listed download servers and file hashes.

Neither report estimated how many devices are infected. Li told Dark Reading that an infected device can make malicious traffic appear to come from the victim's public address. "This creates risks of IP blocklisting, reputational damage, bandwidth consumption, and operational disruption," he said, adding: "Depending on routing and segmentation, the device may also provide access to internal destinations it can reach." FortiGuard's advice is familiar: inventory internet-facing devices, patch flaws known to be exploited, and replace or isolate equipment that no longer receives updates.