ClingSTUN Turns Compromised Linux Devices Into NAT-Traversing Proxies

ClingSTUN Linux backdoor uses STUN to bypass NAT, turns infected devices into proxies, persists via reboot and spreads with hardcoded exploits.

ClingSTUN Turns Compromised Linux Devices Into NAT-Traversing Proxies
Malware

Illustrative image generated with AI

A recently discovered Linux backdoor called ClingSTUN can convert compromised systems into back-connect proxies while using the legitimate Session Traversal Utilities for NAT protocol to navigate network address translation.

FortiGuard Labs attributes the malware’s initial access activity to exploits targeting two dozen vulnerabilities across devices from multiple vendors. Once installed, ClingSTUN can persist through reboots, accept remote commands and attempt to infect additional systems using seven hardcoded exploits.

The findings come from FortiGuard Labs and were reported by SecurityWeek. The available reporting describes ClingSTUN as recently discovered but does not provide an incident date or a precise disclosure date. It also offers no independently confirmed infection count.

Two exploit sets support access and further propagation

According to FortiGuard Labs, ClingSTUN’s operators have used exploits for two dozen vulnerabilities to obtain initial access. The targeted technology is associated with Avtech, EnGenius, D-Link, Hytec, Ivanti, Lantronix, Linear, MeiG, Realtek, Sunhillo, Tenda and TP-Link.

The malware carries a separate collection of hardcoded exploits for seven vulnerabilities. These target products associated with China Mobile, KGUARD, Linksys, LB-LINK, MVPower, Realtek and TBK.

Realtek appears in both groups. FortiGuard Labs also assesses that the operators are continuing to expand their exploit portfolio, although the available information does not identify additional vulnerabilities under development.

These figures describe vulnerabilities, not infected devices or individual victims. The reporting does not quantify how many systems were successfully compromised, how many exploitation attempts occurred or whether every listed exploit was observed succeeding in the wild.

No affected models, vulnerable firmware or software versions, or CVE identifiers are included in the available account. Consequently, administrators cannot determine exposure from the vendor names alone. Inventory checks need to be followed by vendor-specific vulnerability and support information for the exact products deployed.

Payloads cover five processor architectures

ClingSTUN’s delivery infrastructure uses downloaders to retrieve payloads compiled for AMD X86-64, ARM, Intel 80386, MIPS R3000, and PowerPC. That range is consistent with an operation designed to reach different classes of Linux-based hardware rather than one narrowly defined platform.

After execution, the malware copies itself into two hidden files and assigns executable permissions to them. It then modifies three system initialization scripts with startup commands, allowing the payload to run again when the device boots.

FortiGuard Labs identified three botnet variants with a common behavioral pattern. Each could terminate competing processes, disable a watchdog timer, establish persistence and run remotely supplied commands.

Stopping other processes may help the malware retain control of constrained devices or remove competing infections. Disabling a watchdog can prevent an embedded system from automatically recovering through a restart. The precise operational purpose of each action, however, may vary by target and is not independently established in the reporting.

Remote command execution materially expands the consequences of compromise. Operators are not limited to forwarding traffic: they can instruct the infected Linux system to execute additional code, subject to the access and privileges available to the malware.

STUN traffic gives the backdoor a path through NAT

STUN is commonly used by legitimate applications to determine how a device behind NAT appears to the public internet. ClingSTUN repurposes that mechanism for proxy connectivity.

The malware creates a UDP socket and binds it to a randomly chosen local port. It then sends standard STUN binding requests, which allow it to learn external IP address and port-mapping information associated with the connection.

Following those exchanges, ClingSTUN periodically transmits its group identifier and a list of mapped ports to the same STUN endpoints. FortiGuard Labs did not identify a separate registration with a coordination server along this particular communication path.

The backdoor also waits for specially structured packets. Those messages can direct it to execute code remotely or activate its self-propagation routine, according to the researchers.

This design gives operators a way to use compromised devices as back-connect proxies despite NAT boundaries. Traffic can consequently emerge from the victim’s internet connection, potentially concealing the operator’s origin and placing unwanted activity on the compromised network.

Public STUN infrastructure complicates detection. FortiGuard Labs says ClingSTUN uses legitimate third-party STUN services for address discovery, port mapping and continued NAT connectivity. Contact with those servers is therefore not sufficient, by itself, to classify the service as malicious or attacker-controlled.

Consequences extend beyond persistence on one device

An infected system can become both an access point and infrastructure for later activity. ClingSTUN can survive a reboot, receive remote commands and relay traffic on behalf of its operators.

Its propagation component creates another risk. A compromised device may attempt to exploit other reachable systems using the seven vulnerabilities embedded in the malware, potentially extending the operation beyond the original entry point.

The breadth of processor support also raises practical concerns for organizations operating mixed fleets of network appliances and embedded Linux devices. Such equipment may be less visible to endpoint monitoring than conventional servers and workstations.

FortiGuard Labs’ findings indicate substantial potential impact, but the available reporting assigns no formal severity rating or CVSS score to ClingSTUN itself. It does not name victims or provide a count of affected systems. The number of vulnerabilities used by the operation should not be interpreted as the number of successful compromises.

The listed companies are linked to vulnerabilities reportedly exploited by the malware or its operators. Their inclusion does not establish that every product from those vendors is affected.

Defenders should correlate STUN with host behavior

FortiGuard Labs recommends evaluating STUN activity in context. Blocking or flagging every connection to a public STUN server could create misleading alerts because the same infrastructure supports legitimate applications.

The researchers identify three signals that defenders should consider together:

  • suspicious process activity on the Linux host;
  • unexpected outbound UDP connections; and
  • repeated keepalive traffic.

Administrators can also review Linux systems for unexplained executable files in hidden locations and unauthorized commands added to initialization scripts. Unexpected changes involving watchdog processes or unexplained termination of other services merit investigation, particularly when they coincide with recurring UDP and STUN traffic.

Because ClingSTUN binds to a randomly selected local port, detection strategies should not depend on one fixed source port. Behavioral correlation is more useful: process execution, persistence changes, periodic network communication and abnormal listening behavior can collectively provide stronger evidence than a STUN request alone.

The available report does not provide specific patches, affected-version guidance, remediation commands or indicators of compromise. It therefore cannot support a universal patch list. Operators should identify the exact models and firmware versions in their environments, consult the relevant vendors’ security information and prioritize internet-exposed systems associated with the reported exploitation set.

If compromise is suspected, defenders should treat the device as more than a malware host. Its network connection may have been used as a proxy, and its access to neighboring systems may have supported further exploitation attempts. Investigation should preserve relevant process, startup-script, UDP-flow and device logs before remediation where operational procedures allow.

Security dossiers

Read next

Sources

This article is an original reworking based on the sources below.

Back to home

Latest Cybersecurity News

All cybersecurity news →