Malware
ClingSTUN: a router backdoor with two connections
ClingSTUN exploits old device vulnerabilities, queries public STUN services for its external address and receives commands over a separate TCP connection. The public service can remain legitimate, so investigation must follow the initiating process and the backdoor installed on the device.
In this article
When a router connects to a public server also used by video calls, should that connection draw attention? ClingSTUN uses precisely this kind of service. It asks public STUN servers for its external address and port, then waits for subsequent control traffic. The server answering the address question can continue providing a legitimate service while the device making the request already carries a backdoor.
Fortinet's FortiGuard Labs published its analysis on October 5. The Linux backdoor arrives through known vulnerabilities in Internet-facing devices, changes startup files, interferes with other processes and establishes a remote execution channel. The researchers divide their observations into three periods according to changes in malware-download sources. Their detailed analysis focuses on x86-64 samples from the second and third periods.
Public STUN returns an address. After a control datagram arrives, the device connects to a different TCP peer for commands. These connections need to be correlated through the process on the device. Blocking public STUN may interrupt legitimate voice or WebRTC features while leaving startup changes and execution authority intact. Investigation should follow the initiating process through to its later execution activity.
1 The old entry point was still exposed
The first entry FortiGuard recorded was CVE-2022-36553 in Hytec Inter HWL-2511-SS industrial routers. The CVE record describes versions v1.05 and earlier, identifies /www/cgi-bin/popen.cgi and classifies the flaw as command injection. Request input reaches system-command execution, providing an opportunity to download and start a program. The public record does not supply complete firmware source or a repair diff from which to identify a verified internal function or first-fixed commit.
Hytec provides a concrete response route for this model. Its October 26, 2023 advisory confirmed unauthorized access and malware infections, and called for firmware updates and tighter remote administration. At this check, the product page still offers firmware Ver. 111 and marks the model discontinued from sale. The advisory does not map each repair to a CVE. Support should confirm the hardware, installed release and package applicability before installation. A higher version number alone cannot supply that confirmation.
For a router of this model with no infection found, remove public administration access first, then install the firmware confirmed by the vendor. Where remote management remains necessary, restrict it to a controlled management network or explicitly authorized sources. Changing a port moves the service. Vulnerable command-processing code still handles requests that reach it. An upgrade requires a restart, so arrange an alternative for the device's collection or forwarding duties. Keep a failed upgrade isolated instead of returning a known affected release to public service. After recovery, verify the running version and check access restrictions and normal forwarding from the controlled management network.
Later periods expanded to older flaws in EnGenius, D-Link, Realtek, TP-Link and other devices, with additional targets in the third period. A firmware update closes only the entry points of its own product. Finding .cling, startup changes or the process disguise described below also requires removal of the installed program and configuration changes. Completing an upgrade and removing the intrusion need separate acceptance checks.
2 STUN tells a device what the outside sees
When traffic from a private device crosses NAT, the gateway changes its source address and port to externally usable values. The device knows the local port it bound, yet may not know what an outside server actually sees. A STUN Binding exchange returns that information. The server copies the source endpoint it received into a response, and the device reads it back. RFC 8489's operational overview explains this round trip, which voice and WebRTC applications also use when establishing connectivity.
Put the documentation endpoint 192.0.2.1:50000 into a response to see how it is recovered. A STUN message begins with a 20-byte header containing the message type, the length of the following content, the fixed value 0x2112A442 and a 12-byte transaction identifier. The identifier associates the response with an earlier request. The success response carries the external endpoint in XOR-MAPPED-ADDRESS. Its IPv4 address is XORed with the fixed value, and its port with the value's upper 16 bits. Repeating those operations recovers the original endpoint.
Documentation example: 192.0.2.1:50000
Address: 0xc0000201 XOR 0x2112a442 = 0xe112a643
Port: 0xc350 XOR 0x2112 = 0xe242
Attribute: 0020 0008 0001 e242 e112a643
Decoded: 192.0.2.1:50000These values come from an offline model that handles bytes in memory without sending packets. The XOR operation uses a public constant available to both ends and serves as field encoding. Recovering the endpoint answers what this particular STUN server saw. Whether another host can send traffic there, and whether the intervening NAT and filtering rules will admit it, depends on the actual connectivity conditions.
ClingSTUN creates a UDP socket on a random local port and sends Binding requests to public endpoints. The second period uses 24 endpoints and requires at least half of the exchanges to succeed before continuing. The third reduces the list to 13 and requires all to succeed. The program also periodically sends a group identifier and mapped-port list to those endpoints.
3 Commands arrive over a later TCP connection
NAT mapping, filtering behavior and connection state affect whether the control datagram arrives. The public analysis identifies no separate coordination-server registration and has not verified how the operator obtains the external mapping or delivers control traffic through NAT. Any further participation by the public STUN services in that coordination also lacks a confirmed execution record.
The analysis does follow execution after delivery. A retained UDP socket receives a 20-byte control datagram, and command 1 triggers a separate outbound TCP connection. Its destination comes from the control message. The program receives a command from that TCP peer and executes it. Public STUN answers the address query, while this later peer delivers commands. The standard STUN header and the reported control datagram both involve 20 bytes. Equal length supplies no reason to treat their format or purpose as identical.
This distinction changes network investigation. The three malware-download sources listed in the report can help establish whether a device fetched a program. Public STUN addresses require examination of the initiating process and legitimate business use. A subsequent unfamiliar TCP connection should be correlated with that process's UDP reception, child-process creation and execution traces. A destination-IP match alone cannot supply all three events: download, address discovery and command execution.
The samples also embed propagation code for seven vulnerabilities. That count describes available attack functions. The public report does not provide a successful outcome for every one of those paths on every affected device. After confirming infection, inspect the device's outbound activity and neighboring systems' records to determine what this particular host did and which additional assets need investigation.
4 The process listing has been altered too
Following the initiating process leads to another part of ClingSTUN's behavior. It copies itself to /root/.cling and /usr/local/bin/.cling, grants executable permissions and appends startup content to /etc/inittab, /etc/init.d/rcS and /etc/rc.d/rc.boot. The initialization system and files actually read on the device determine which changes take effect at boot. Recovery should compare the effective startup configuration with a trusted baseline and check the resulting startup after a reboot.
The program then clears its original argument memory, leaving an empty command line in tools such as ps. The Linux cmdline documentation explains that a process can modify that memory. An empty command line calls for checking the executable, startup source and connections. It does not by itself identify either a system task or an infection.
When UID is 0, indicating root identity, the sample copies selected process-information files from /proc/1/ to /tmp and bind-mounts /tmp over its own /proc/<pid>. PID 1 is the initial process, numbered 1. The proc filesystem exposes kernel process information. A bind mount makes another directory tree visible at the same access path. Tools reading that path may therefore receive copied PID 1 metadata. The running malware retains its actual process identity. The directory contents presented to the observer have changed.
Switching to another viewer that also relies on /proc may produce the same disguise. Preserve mount relationships together with process and network records, then examine the device from a trusted collection or recovery environment. The third-period downloader itself inspects /proc/mounts, unmounts non-proc filesystems placed over process directories and terminates the associated processes. It also terminates programs running from /tmp.
Other actions can affect stability. The sample attempts to stop watchdog timers through ioctl on /dev/watchdog and /dev/misc/watchdog. Its process-killing conditions involve temporary directories and mismatches between command lines and executable names, while exempting its own process group. Watchdogs ordinarily help handle an unresponsive device, and process termination may also disrupt maintenance tasks. Use the vendor's methods to verify watchdog and maintenance behavior during recovery, beyond checking that the network works again.
5 Let device evidence determine the recovery
If the only lead is a public STUN request, establish whether the device runs voice, video or another feature needing NAT coordination, and identify the process that sent it. Finding .cling, unexpected startup entries and an unusual mount over a process directory warrants isolation and preservation of those files, mount relationships and perimeter network records. Rebooting changes volatile evidence and may run the installed startup entries again. It should not be the first cleanup action.
Once a privileged backdoor is confirmed, recovery needs trusted firmware and inspected configuration. Close the exploited public entry, address the vulnerabilities of the specific model and examine remote-management accounts, credentials reachable by the device and unusual connections in adjacent networks. The model's official recovery instructions should establish whether factory reset covers the altered files and which settings survive reflashing. Keep devices isolated and arrange replacement when no usable repair and trusted recovery route can be obtained.
Egress rules can follow the device's actual job. An industrial gateway without voice, WebRTC or a similar feature generally has little reason to query a large set of public STUN endpoints continuously. Its configured destinations and normal records provide a starting allowlist. Where the functionality is needed, retain the necessary service, associate traffic with its application, test legitimate operation and watch whether the same process opens unfamiliar TCP connections.