STUN-based command-and-control (C2) is a way for malware to use traffic resembling a legitimate NAT-traversal protocol to register infected devices and deliver commands. Nozomi Networks Labs reported this behavior in one Cling MIPS sample: it used STUN exchanges to learn mapped ports, then listened for commands encoded in UDP packet transaction IDs. This is a specific malware finding, not evidence that ordinary STUN, WebRTC, or video-conferencing traffic—or every router using STUN—is malicious.
What is STUN, and what did the Cling sample do with it?
STUN, or Session Traversal Utilities for NAT, helps an endpoint learn the public-facing IP address and port that a server sees through a network address translator. Applications use STUN and related ICE or TURN traffic for legitimate connectivity, including real-time communications. In normal STUN use, a client sends a Binding Request and receives a response that reports the observed address and port. The IETF defines the protocol in RFC 8489.
In its October 1, 2026 analysis, Nozomi Networks Labs described a Cling MIPS sample that repurposed this pattern. It used STUN exchanges to discover mapped ports, sent custom registration messages, and then interpreted commands in UDP packets directed to those ports. The researchers’ observations apply to the analyzed sample; they do not establish how all Cling variants or all STUN traffic behave.
The reported exchange, step by step
- The sample periodically sent Binding Requests to a hard-coded list of 13 STUN servers, approximately every five seconds. Nozomi noted that the requests used an all-zero transaction ID, rather than the random value expected by RFC 8489.
- It recorded the public IP address and mapped port returned in Binding Success Responses.
- It sent custom UDP registration datagrams to the contacted endpoints, including mapped-port information and an infection-method tag. Nozomi said these datagrams did not conform to STUN and were ignored by conforming servers.
- It listened for UDP packets sent to previously mapped ports and read command data from the STUN transaction-ID field.
Nozomi also reported a response that used an all-zero transaction ID instead of echoing the request’s ID. In a controlled validation, researchers advertised different port sets to different endpoints and later received commands on a port advertised to the suspect endpoint. They inferred that endpoint was part of the botnet’s command infrastructure. The command packets appeared to come from an IP address associated with stun.l.google.com; Nozomi proposed source-address spoofing as the likely explanation, not Google operation of the C2 server.
#1 Best Overall
How does suspicious STUN-like traffic differ from normal STUN?
A STUN connection by itself is not an infection indicator. Defenders should look for a combination of protocol deviations and surrounding behavior rather than block or investigate every device that contacts a public STUN service.
| Signal | Ordinary STUN use | Behavior reported for the Cling sample |
|---|---|---|
| Transaction ID | A request uses a transaction ID that the response matches, as defined by RFC 8489. | Requests used all-zero IDs; Nozomi also observed a response that did not echo the request ID. |
| Datagrams after address discovery | Binding exchanges report the mapped address and port. | The sample sent custom registration datagrams that Nozomi said were not STUN-conformant. |
| Use of mapped port | STUN helps an application establish connectivity through NAT. | The sample listened for command packets on ports learned during its exchanges. |
| Payload meaning | STUN messages support NAT traversal; the transaction ID identifies a transaction. | The sample used the transaction-ID field to carry command data in UDP packets. |
These distinctions are based on Nozomi’s analysis of the sample and RFC 8489’s protocol definition. A single anomaly can have benign or unrelated explanations; an unusual pattern becomes more useful when corroborated by endpoint artifacts, exposure information, or other network evidence.
Rank #2
What could the malware do after establishing this channel?
Nozomi reported that the sample supported commands to download and execute payloads, scan for and exploit other systems, start or stop a TCP tunnel, start or stop a proxy relay, and launch a denial-of-service flood. Those capabilities could turn a compromised appliance into a foothold, relay, tunnel endpoint, or botnet node.
The same analysis described persistence behaviors in the sample: copies at /root/.cling and /usr/local/bin/.cling; references appended to init-related files; and replacement of wget with a copy of the malware while preserving the original executable and recording its location. Nozomi also described a single-instance check involving port 33957. These are sample-specific hunting clues, not universal indicators for every Cling infection.
What should router owners and defenders check?
Use network observations to identify suspicious behavior and host checks to seek corroboration. No single item below proves compromise.
Network indicators to investigate
- Repeated STUN Binding Requests with all-zero transaction IDs.
- Custom UDP registration datagrams sent to endpoints contacted for STUN.
- Responses that fail to echo the request transaction ID.
- Unexpected inbound UDP packets arriving at ports learned through the STUN exchanges.
Host artifacts from the analyzed sample
- Unexpected
.clingfiles at/root/.clingor/usr/local/bin/.cling. - Unexpected changes to init-related files.
- A replaced
wgetexecutable, including companion pathswget.randwget.p. - Use of port
33957in a single-instance check.
Practical response sequence
- Preserve evidence. If an appliance appears compromised, record relevant network observations and system state before making changes, where operationally safe. A reboot or reset may remove evidence.
- Identify the exact device and firmware. Check its model, hardware revision, firmware version, and vendor advisories. A vulnerability associated with a component or vendor does not prove that every product from that vendor is affected.
- Review exposure and patch status. Nozomi reported attempts to exploit CVE-2021-35394, a remote-code-execution flaw affecting the Realtek Jungle SDK diagnostic component commonly compiled as UDPServer. The report says affected SDK components appear in routers, access points, repeaters, and other embedded appliances, including some that remain unpatched. Follow the vendor’s instructions for the exact model and firmware; the cited reporting does not provide a complete model-by-model patch matrix.
- Correlate network and device evidence. Compare transaction IDs, registration traffic, and inbound packets with host files and startup changes. CISA’s communications-infrastructure guidance recommends practices such as maintaining device and firmware inventories, secure authentication, centralized logging, and baselines for normal network behavior; these support hardening and investigation but do not diagnose Cling on their own.
- Use an appropriate recovery path. If compromise is substantiated, follow the vendor’s recovery guidance or involve qualified incident responders. Do not assume that blocking STUN globally is a safe or complete fix; legitimate applications may rely on it, and the reported sample used multiple endpoints and behaviors.
What does the reported vulnerability activity establish?
Nozomi said its telemetry showed attempts to exploit CVE-2021-35394. Its example showed a UDP datagram beginning with orf;, followed by shell commands that downloaded and ran malware. The report also said the analyzed sample contained exploit logic for vulnerabilities associated with Realtek SDK, LB-LINK routers, TBK DVRs, Linksys, Eir D1000 routers, FiberHome SR1041F/China Mobile HG6543C4, and MVPower CCTV DVRs.
Rank #4
Exploit code in a sample does not establish that each listed product was successfully compromised or that every model from a named vendor is vulnerable. The available report describes a spike in observed attempts and one analyzed MIPS sample, but does not establish an incident-size or population-wide infection estimate. Verify model-specific exposure and remediation with the device vendor.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Recommended Free Tools
