A router contacting a public STUN server may be supporting a legitimate application. It may also be running a backdoor. The destination alone cannot tell you which.

On October 5, FortiGuard Labs published its analysis of ClingSTUN, a Linux back-connect proxy backdoor delivered through vulnerabilities in Internet-facing devices. The useful defensive question is how to connect unexpected network activity to the process, firmware exposure, and boot changes behind it. FortiGuard analysis

Exploitation Comes Before STUN

FortiGuard reports an initial-access portfolio spanning routers, cameras, and other appliances, including Hytec, D-Link, EnGenius, Realtek-based devices, TP-Link, and Ivanti products. Its table lists 24 CVE identifiers for delivery. A separate analysis identifies seven hardcoded exploits for self-propagation. These are different stages: an exploit observed delivering malware and an exploit present in a propagation routine do not establish identical deployment or success rates.

The report describes architecture-specific payloads for x86-64, ARM, Intel 80386, MIPS, and PowerPC. This is primarily an appliance and IoT exposure story, rather than evidence that every Linux desktop has acquired a new remotely exploitable weakness. The published analysis does not establish a victim count or named operator. FortiGuard analysis

Some entry points are years old. One reported target is TP-Link Archer AX21 command injection, CVE-2023-1389. TP-Link released remediation guidance in 2023 and directs owners to firmware for their exact hardware revision. A Linux distribution update on an administrator’s workstation does not patch that router. TP-Link advisory

What STUN Actually Provides

Session Traversal Utilities for NAT lets a client discover the externally mapped address and port associated with its connection. It also supports connectivity checks and keeping NAT bindings alive. STUN is a component of NAT traversal, not a universal firewall bypass. Whether another endpoint can reach a mapped socket depends on the network’s mapping, filtering, and firewall behavior. RFC 8489

FortiGuard describes ClingSTUN binding a UDP socket to a random local port and sending standard STUN Binding requests to public endpoints. The analyzed variants differ in endpoint count and required successful exchanges. Afterward, the malware periodically sends a group identifier and mapped-port information to the same endpoints.

There is an important evidence boundary: FortiGuard has not verified how the operator obtains the external mapping and delivers control traffic through NAT. The analysis identifies no separate coordination-server registration in that path. It does describe a control datagram that, once received, can trigger an outbound TCP connection to a supplied endpoint, receive a command, and execute it. That establishes malware capability; it does not prove that arbitrary inbound commands pass through every NAT configuration. FortiGuard analysis

Public STUN servers contacted by the malware should therefore not automatically become a list of attacker-controlled command servers. Blocking them across the company may disrupt legitimate communications while leaving the exploited appliance and persistence intact.

Hunt for the Process and Its Boot Changes

The strongest investigation combines network observations with host evidence. FortiGuard identifies executable copies at /root/.cling and /usr/local/bin/.cling, with startup commands appended to /etc/inittab, /etc/init.d/rcS, and /etc/rc.d/rc.boot. These paths are relevant to the analyzed samples and device environments; their absence on a systemd-based server is not evidence of cleanliness.

The malware also clears its command-line arguments. When running as root, it can bind-mount /tmp over its own /proc/<pid> directory using selected metadata copied from PID 1. That can mislead process inspection. Other reported behavior includes terminating competing processes and manipulating watchdog devices. FortiGuard analysis

For a device with an authorized Linux shell, these are illustrative, read-only starting points:

Terminal window
# Inspect reported file locations and startup references.
ls -l /root/.cling /usr/local/bin/.cling
grep -nF '.cling' /etc/inittab /etc/init.d/rcS /etc/rc.d/rc.boot


# Inspect current UDP sockets and mount records.
ss -uanp
cat /proc/self/mountinfo

Root may be needed to see protected files and process owners. Missing files or commands are normal on some embedded firmware. These checks have not been validated against live ClingSTUN samples, and a compromised operating system can conceal evidence. Do not execute a suspicious file to identify it. Preserve it through your incident-response process and compare its hash with the original report.

For network monitoring, prioritize a device that has no documented STUN requirement but starts recurring outbound UDP exchanges, especially alongside a recent exploit alert, unusual executable, boot-file change, or subsequent outbound TCP session. Record the source device, timestamps, destinations, and available process attribution. A protocol label or periodic traffic alone is a hunting lead, not a ClingSTUN verdict.

Close the Entry Point, Then Recover the Device

The following controls are operational recommendations based on the reported attack path:

OwnerActionEvidence of success
Device or platform administratorMatch model, hardware revision, firmware, and support status to vendor guidance; apply the supported security update. Replace unsupported equipment.Record the installed version after reboot and confirm it meets the relevant advisory.
Network administratorRemove unnecessary WAN management and externally exposed services. Restrict required administration to approved management paths.From an authorized external test point, confirm removed services are unreachable and approved management still works.
Network administratorSegment appliance networks and restrict outbound access to documented service requirements, including UDP where practical.Test intended functions and verify denied unexpected egress in firewall logs.
SOC or incident responderCorrelate exploit attempts, STUN activity, persistence artifacts, and download infrastructure from the report.Produce a timeline tied to specific devices; do not treat a public STUN destination alone as confirmation.

If compromise is suspected, isolate the device while preserving necessary evidence and coordinating service impact. Obtain firmware and recovery instructions through a trusted vendor channel. Restore from a known-good state using the vendor-supported recovery procedure, and replace the device if its integrity cannot be established. Reapply only reviewed configuration and rotate credentials accessible to the compromised device from a trusted system.

An update closes a vulnerability; it does not establish that an existing backdoor has disappeared. Removing .cling alone also leaves the entry point and possible additional changes unresolved. Before reconnecting, verify firmware, exposed services, startup configuration where accessible, and expected network behavior. MFA on an administrative login does not repair a remotely exploitable command-injection path.

ClingSTUN’s distinctive feature is its use of ordinary connectivity infrastructure after exploitation. The practical defense remains specific: patch or replace the affected appliance, reduce its exposure, and investigate why that particular device is making those connections.

Sources