Malware News Linux Backdoor Abuses STUN Protocol, Exploits Dozens of Flaws

[Brownie2019]

Content source

https://www.securityweek.com/linux-backdoor-abuses-stun-protocol-exploits-dozens-of-flaws/

ClingSTUN operates as a back-connect proxy backdoor, sets up persistence, and contains exploits for self-propagation.
A recently discovered Linux backdoor turns infected systems into proxies that use the Session Traversal Utilities for NAT (STUN) protocol and contains exploits for self-propagation, FortiGuard Labs reports.

Dubbed ClingSTUN and functioning as a back-connect proxy backdoor, the malware targets two dozen vulnerabilities for initial access and sets up persistence to ensure malware execution during the boot sequence.

The malware’s operators were seen indiscriminately exploiting Avtech, EnGenius, D-Link, Hytec, Ivanti, Lantronix, Linear, MeiG, Realtek, Sunhillo, Tenda, and TP-Link flaws, and appear to be expanding their portfolio with other exploits as well.

Additionally, the backdoor includes a self-propagation mechanism containing hardcoded exploits for seven China Mobile, KGUARD, Linksys, LB-LINK, MVPower, Realtek, and TBK vulnerabilities.

The ClingSTUN backdoor relies on downloaders to fetch malware payloads for different architectures, including AMD X86-64, ARM, Intel 80386, MIPS R3000, and PowerPC.

Across three variants of the botnet, FortiGuard Labs observed the same behavior related to killing competitors’ processes, terminating a watchdog timer, setting up the persistence mechanism, and executing remote commands.
For persistence, ClingSTUN copies itself to two hidden files with executable permissions, then appends startup commands to three system initialization scripts.

Additionally, it establishes a UDP socket, binds to a random local port, and sends standard STUN binding requests to set up endpoint connections.

“After completing the STUN binding exchanges, ClingSTUN periodically sends its group identifier and mapped-port list to the same STUN endpoints. No separate coordination-server registration was identified in this path,” FortiGuard Labs says.

The malware was also seen listening to specific packets that allow its operators to perform remote code execution and trigger the self-propagation mechanism.

“A notable feature is its abuse of legitimate public STUN servers to discover external IP addresses and port mappings, thereby helping maintain NAT connectivity. These third-party services should not be automatically classified as attacker-controlled infrastructure. Instead, defenders should assess STUN activity alongside suspicious process behavior, unexpected UDP connections, and recurring keepalive traffic,” FortiGuard Labs notes.

 

[Bot]

Hi Brownie2019, the important distinction is that STUN is not the initial vulnerability. ClingSTUN first gains code execution by exploiting known flaws in exposed routers, cameras, gateways and other embedded-Linux appliances. It then uses STUN to discover the public IP address and UDP port assigned by NAT, helping the operator reach the infected device from outside. A patched Linux desktop is not at risk merely because it supports WebRTC or STUN.

The clever part is the camouflage. Public STUN services are normal infrastructure, so their addresses should not automatically be blocklisted. Nozomi’s analysis of the same Cling family found operator commands encoded in the normally random STUN transaction-ID field, with some packets apparently spoofed to resemble replies from Google’s STUN service. That does not indicate Google’s servers were compromised.

Practical defensive measures would be:

• Inventory Internet-facing appliances from the affected vendors and match the exact model and firmware against the vulnerabilities listed in FortiGuard’s original analysis.
• Disable WAN-side administration and unnecessary port forwarding; put management behind a VPN or strict allowlist.
• Replace devices that no longer receive security updates.
• Segment IoT and network appliances, permitting only the outbound services they actually need.
• Investigate recurring STUN-like UDP traffic from devices that have no legitimate reason to use it, especially when accompanied by regular keepalives, scanning or unexpected executable processes. Blocking all STUN globally would be a rather blunt hammer and could break voice, video and WebRTC applications.
• In the sample Nozomi examined, useful host indicators included /root/.cling, /usr/local/bin/.cling, and modifications to /etc/inittab, /etc/init.d/rcS and /etc/rc.d/rc.boot. Those are variant-specific clues, not a complete cleanliness test.

If an appliance is confirmed compromised, simply rebooting it is inadequate because the malware modifies startup files. Isolate it, use the vendor’s supported recovery or firmware-reflash procedure, patch it before reconnection, and change its administrative credentials from a trusted device. The proxy function matters too: the victim’s connection can be abused to scan, relay malicious traffic or conduct attacks while making that traffic appear to originate from the victim.

Sources

• A STUNning Disguise: Cling Malware Masquerades as Google