Cling hides its commands in traffic that looks like a video call

On October 1, 2026, Nozomi Networks Labs published a Linux botnet it calls Cling. Four days later FortiGuard Labs described a strain it calls ClingSTUN. The two write-ups don’t cite each other. They do describe the same hiding places on a device, the same boot scripts, and the same idea: talk to the public servers that video calls use, so the botnet’s traffic looks like a call setting itself up. This post treats them as one campaign and keeps the places they disagree.

It doesn’t arrive in an email, and it doesn’t install from a link on a phone. It gets into routers, cameras, recorders and similar boxes that are reachable from the internet and still carry years-old flaws.

What STUN is, when it isn’t a botnet

When a video call or a browser call has to reach someone behind a home router, the computer first asks a public server a simple question: what address do I look like from the outside, and which port did you see? That question is STUN, Session Traversal Utilities for NAT, specified in RFC 8489. Zoom, Teams, Webex and ordinary browser calls all do it. The servers that answer are mostly legitimate, and a lot of them are meant to be used by anyone.

Cling uses that question as its phone book. Nozomi’s sample asks about every five seconds. The surrounding traffic can sit in the same noise as a real call.

How it gets in

Nozomi found it while watching attempts to exploit CVE-2021-35394, a remote-code flaw in the Realtek Jungle SDK. The component shows up in routers, access points, repeaters and other appliances, and a lot of them never receive an update, which is why a flaw from 2021 is still being sprayed at the internet. Most of what Nozomi saw was the usual probing. A slice of it downloaded a bot that didn’t behave like a typical Mirai copy.

The sample Nozomi took apart also carries exploits for seven more known flaws, so a box that is already in the botnet can go looking for the next one. The oldest of those is a Realtek bug, CVE-2014-8361. Others hit DVRs and a handful of router brands. Fortinet, looking at its own samples, listed 24 published flaws used as ways in, across equipment from Realtek, D-Link, TP-Link, Tenda, Ivanti, EnGenius and others, and said the list was still growing on October 5. Its copy carries seven hardcoded exploits for spreading, overlapping the set Nozomi found. Fortinet splits the campaign into three stretches, each with a different place the installer was downloaded from, and says the malware was still changing as they wrote.

None of this is a new kind of break-in. Nozomi says so directly. The new part is how the bot stays in touch afterward.

Commands that look like call setup

Nozomi’s account of the command channel has four steps.

1. The bot sends a STUN binding request to 13 servers. A normal request carries a random transaction ID, a number the server is supposed to echo back so the client can match the reply to the question. Cling sets that ID to all zeros, which the standard doesn’t allow. At the time Nozomi wrote, those servers had clean reputations, and most of them appear on public lists of STUN servers.
2. Each server answers with the public address and port it saw. That opens a temporary path back through the router.
3. The bot then sends each server a registration message that is not STUN at all. It includes the ports it just learned, and a tag for how that bot was infected, such as the Realtek path. Conforming servers ignore it. In Nozomi’s test, none of the 13 answered.
4. The bot waits. Orders arrive later as UDP packets whose transaction ID, the field that should be random, instead encodes the command.

The commands Nozomi lists are the usual botnet menu: download and run something, scan and exploit more devices, open a tunnel, relay traffic as a proxy, or flood a target for a set time. Over several days of watching, Nozomi received scan tasks and flood tasks aimed at a South Korean internet provider, a University of Chicago cluster, and two Minecraft servers.

One server in the list of 13 didn’t behave like the others. A conforming STUN server echoes the transaction ID it was sent. This one answered with all zeros, the same value the bot uses. Nozomi then pretended to be a new bot, but told each server a different set of ports. Hours later, commands showed up on a port that had been advertised only to that one server. That is Nozomi’s evidence that the operator can see registrations arriving there, and can use them to learn where the new bot is.

The packets carrying those commands claimed to come from an address that stun.l.google.com resolves to. Nozomi says it knows of no legitimate way to make a STUN server repeat a transaction ID the attacker chose. The traffic is UDP and one-way. Their most likely explanation is that the sender faked Google’s address, from a network that doesn’t check whether packets really come from where they claim. They point at a consistent difference in hop-count values between genuine STUN replies and the command packets. This is not a report that Google’s service was broken into. It is a report that a packet can wear a trusted return address. A strange packet from a strange host gets looked at. The same packet, after the device has already been talking to Google’s STUN service, is easy to file under “video call.”

Fortinet’s October 5 account matches the STUN idea and stops short of that last claim. Its newer build also uses 13 public endpoints, down from 24 in the build before, and after the binding exchange it sends those servers a group identifier and the list of mapped ports. Fortinet says it did not find a separate coordination server in that path, and that how the operator learns the external mapping and then delivers commands through the router was still unverified in the sample they had. Their bot listens for a short packet that can trigger a remote command or tell it to spread. Two labs, one week, the same disguise, and a disagreement about how much of the return path they could prove.

What it does to the box

Both reports say the malware copies itself to /root/.cling and /usr/local/bin/.cling, and adds those copies to the boot scripts /etc/inittab, /etc/init.d/rcS and /etc/rc.d/rc.boot, so a reboot starts it again.

Nozomi also found a second hold on the device. It moves the real wget aside, remembers where that copy went, and puts itself in wget’s place. The next time anything on the box downloads a file, including a scheduled job or another attacker, the malware runs first, then performs the download so the caller doesn’t notice. Fortinet describes a further disguise: the program clears its own command line so a process listing looks empty, and it can cover its own process information with a copy of what the system’s first process looks like.

Fortinet’s conclusion matches Nozomi’s on the point that matters for blocking: the public STUN servers should not automatically be treated as attacker infrastructure. The signal is the device, and the shape of the traffic, not the fact that a STUN server exists.

What to check

1. Take old routers, cameras and recorders off the open internet. Update the firmware if the maker still ships it. If the device is years out of support, replace it or don’t let the internet reach it. A guest network is a smaller version of the same idea. The flaws in these reports are public and old. Patching is the whole fix for a box that can still be patched.
2. STUN from a laptop during a call is normal. STUN from a camera, a DVR or a router that isn’t in a call is not. Nozomi’s specific oddity is a binding request every few seconds with an all-zero transaction ID, or a non-STUN packet sent to a STUN port. You don’t need to block STUN to act on that. Blocking it would break real calls.
3. If you can look at the device, the file names are plain. .cling on disk, boot scripts that mention it, or a wget that has been moved aside to wget.r with a wget.p beside it. Most people can’t log into a camera. Unplugging it is the check that doesn’t require that.

Phones and ordinary home PCs are not how this one spreads.

Sources

• A STUNning Disguise: Cling Malware Masquerades as Google, Nozomi Networks Labs, October 1, 2026.
• ClingSTUN Linux Backdoor Abuses Public STUN Infrastructure, FortiGuard Labs, October 5, 2026.
• RFC 8489, Session Traversal Utilities for NAT, IETF.