In June, Backdoor.Turn Hid in Microsoft's TURN Relays. Now ClingSTUN Hides Behind Public STUN Servers on 31 Bugs' Worth of Linux Boxes.
On June 16, Symantec showed a ransomware crew hiding its command channel inside Microsoft Teams' TURN relays. On October 5, FortiGuard Labs showed a different, unnamed crew using public STUN servers to steer a Linux backdoor it plants through 31 known bugs in routers, cameras and VPN gateways. TURN and STUN are the same family of plumbing: the servers that help video calls get through home and office firewalls. Two dated sightings, 111 days apart, on two different platforms. That is the checkable claim in this post. The technique is spreading. Nobody has shown that the people are connected.
What FortiGuard found
The malware is called ClingSTUN. Vincent Li of FortiGuard Labs published the analysis on October 5: ClingSTUN: Linux Backdoor Abuses Public STUN Infrastructure. Credit for the work is his and Fortinet's.
ClingSTUN is a back-connect proxy. Once it is on a device, the operator can use that device as a relay for their own traffic, and can run commands on it. It is built for ARM, MIPS, PowerPC, Intel 386 and x86-64, which is the spread you build for when the targets are home routers, DVRs and cameras rather than servers.
It gets in through known bugs. FortiGuard lists 31 CVEs, from a Realtek SDK flaw from 2014 (CVE-2014-8361) to one from this year (CVE-2026-87827). Vendors include Realtek, D-Link, TP-Link, Linksys, MVPower, TBK, LB-LINK, KGUARD and China Mobile. Two of the 31 are not toys: CVE-2023-46805 and CVE-2024-21887, the Ivanti Connect Secure pair that hit enterprise VPN gateways in January 2024. An IoT botnet carrying an enterprise VPN chain is a sign it is trying anything with a reachable shell.
FortiGuard split the campaign into three periods, each with its own download server. The first, 124.163.212.119, delivered the malware through CVE-2022-36553 and lasted two days. Then 222.223.152.97 and 118.145.196.225 took over.
Persistence is old-school. The binary copies itself to /root/.cling and /usr/local/bin/.cling and adds start-up lines to /etc/inittab, /etc/init.d/rcS and /etc/rc.d/rc.boot. A reboot does not clean it.
FortiGuard did not name the operators. Neither will we.
Why STUN is a good hiding place
STUN is the protocol a device uses to ask a server on the internet one question: what do I look like from outside? The answer is the public address and port that the firewall or home router has assigned. Every video call, browser WebRTC session and VoIP phone does this. Google, telecoms and VoIP providers run free public STUN servers for exactly that reason.
ClingSTUN sends normal 20-byte STUN binding requests to public STUN servers. FortiGuard lists 24 of them, including one of Google's. That tells the bot which port its router has opened for it. It then periodically sends its group identifier and its list of mapped ports to the same STUN endpoints, and it listens for a 20-byte packet from the operator. When that packet arrives, the bot opens a separate outbound TCP connection to whatever address the packet names, and the proxy session runs over that.
What a defender sees is a box talking to well-known STUN servers in short UDP bursts. That looks like a video call. There is no long-lived connection to a sketchy server to flag.
One honest gap. A public STUN server answers questions; it does not pass messages along to third parties. FortiGuard's write-up describes the bot reporting its group ID and ports to those endpoints, but how the operator actually reads that report is not something we could work out from the published analysis. If you know, write to us and we will add it with credit.
The evolution, stated carefully
Here are the two observations side by side.
June 16, 2026: Symantec and Carbon Black disclosed Backdoor.Turn, a Go backdoor used by the DragonForce ransomware group. It fetched an anonymous Teams visitor token and routed its command traffic through Microsoft's own TURN relays, so the traffic looked like Teams. It ran on Windows inside a major US services company for one to two months.
October 5, 2026: FortiGuard Labs disclosed ClingSTUN, a Linux backdoor from operators nobody has named. It uses public STUN servers so its control channel blends in with call traffic, and it gets onto devices by working through a list of 31 public exploits.
What changed: the platform (Windows to embedded Linux), the protocol (TURN relay to plain STUN), the way in (an already-compromised enterprise network to mass exploitation of unpatched devices) and the scale (one victim to anything vulnerable on the internet). What stayed: the idea of parking command traffic behind real-time-communications servers that defenders whitelist because blocking them breaks calls.
What we are not claiming: that DragonForce wrote ClingSTUN, that ClingSTUN copied Backdoor.Turn, or that either crew knows the other exists. Neither vendor says so. Different language, different platform, different target set. The claim is about the technique, not the lineage. Two dated observations by two unrelated vendors make that a fact, not a forecast.
A correction to our June 25 post
Our June 25 post, Backdoor.Turn Got the Headlines. convoC2 Is the Version Anyone Can Run, called Backdoor.Turn "North Korea's custom Rust backdoor." That was wrong. Symantec attributes Backdoor.Turn to the DragonForce ransomware group and describes it as written in Go. Our own June 24 post had it right. The June 25 post also treated convoC2 as the same technique. It is not quite: convoC2, an open-source red-team tool, hides commands in Microsoft Teams chat messages and webhooks, not in TURN relays. Both abuse trust in Teams, but by different routes. We are flagging both errors here so the record is straight.
What our feed had, and what we added
Before writing, we checked our corpus for the three download-server addresses and one of the sample hashes. None were there. No first-party sighting, no third-party feed copy. So there is no lead to claim and we are not claiming one.
Today we ingested 24 records under the source manual-batch-stun-backdoor-2026-10, all citing FortiGuard's report: the 21 SHA-256 sample hashes at confidence 85, and the three download-server addresses at confidence 70. The addresses are payload hosts, not the control channel, one of them was only used for two days, and download hosts in residential and ISP space are often borrowed. So they sit below our own edge shield's 80 blocking floor. They still ship in the default CSVs, which start at confidence 30. If you pull with min_confidence=80, they will not be in your set. That is your setting, not ours.
What we left out on purpose: all 24 public STUN servers, including Google's. Those are abused services, not attacker infrastructure. Putting them on a blocklist would break video calls for every subscriber and would not stop the malware, which can switch to any of hundreds of others.
What to do, if you are a small shop
Step one: find the boxes nobody owns. Routers, NVRs, IP cameras and the old VPN appliance. Those are ClingSTUN's targets. If any of them has its admin page or UPnP open to the internet, close it today.
Step two: do not patch from the KEV list alone. We checked all 31 of FortiGuard's CVEs against CISA's Known Exploited Vulnerabilities catalog (version 2026.10.04). Ten are on it. Twenty-one are not, including the CVE-2022-36553 bug that started the campaign. A small shop that patches only what CISA lists will miss two-thirds of this botnet's way in. For cheap consumer gear with no fix, the fix is replacement.
Step three: check Ivanti. If you still run Ivanti Connect Secure or Policy Secure, CVE-2023-46805 and CVE-2024-21887 are in this kit. Those were patched in early 2024. If you are not on a fixed build, assume it is already compromised.
Step four: watch for STUN where it does not belong. A camera or a router has no reason to make WebRTC calls. Look for UDP to port 3478 or 19302 from your device network. On a laptop that is normal. On an NVR it is a red flag. If you have a separate network for devices, block outbound STUN from it entirely. Do not block STUN for your whole office, or Teams, Zoom and Meet will start failing.
Step five: look on the device. If you can get a shell on a suspect box, check for /root/.cling or /usr/local/bin/.cling, and for unfamiliar lines in /etc/inittab, /etc/init.d/rcS or /etc/rc.d/rc.boot. If you find them, reflash the firmware. Deleting the files is not enough when you do not know what else changed.
Step six: pull the hashes. The 21 sample hashes are in our feed. Point your endpoint or file-scanning tool at hashes.csv with your API key, or use FortiGuard's list directly.
The opinion
The point of a hiding place like this is that defenders cannot block it without hurting themselves. Teams relays, STUN servers, CDN front doors: we whitelist them because the business needs them, and attackers have noticed. Backdoor.Turn proved the idea on Windows with an anonymous Teams token. ClingSTUN shows it on the cheapest Linux boxes on the internet, with no custom zero-day, just a list of old bugs. We think it is about 80 percent likely that within six months a commodity botnet or open-source tool will use TURN or STUN for command traffic by default, the way DNS tunneling became standard a decade ago. The other 20 percent is that the scheme is fiddlier than it looks, which the unexplained operator side of ClingSTUN hints at. The defense does not depend on who is right. Know which of your devices should be making calls, and treat the ones that should not as a finding.
Was this useful? Rate this post. The widget is at the bottom of the page, and we read every response.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=clingstun-linux-backdoor-stun-c2-nat-traversal-spreads
Comments