Cling: IoT Backdoor Disguises C2 as STUN Traffic

1. Basic Information

• Article Title: A STUNning Disguise: Cling Malware Masquerades as Google
• Publisher: Nozomi Networks Labs
• Publication Date: 2026-10-01
• Updated Date: Unknown (Not stated in primary source)
• Reason for Report Revision: Technical review: Corrected the direction of C2 disguise, the registration procedure for 13 destinations, customer observations versus research client experiments, command reception and subsequent attack success, and the observation points required for UDP analysis.
• Original: A STUNning Disguise: Cling Malware Masquerades as Google
• Related Sources: Fortinet: ClingSTUN Linux Backdoor Abuses Public STUN Infrastructure, SecurityWeek: Linux Backdoor Abuses STUN Protocol, Exploits Dozens of Flaws, STUN: RFC 8489
• Related Malware, Threat Groups, CVEs, and Products: Cling, ClingSTUN, CVE-2021-35394, CVE-2014-8361, CVE-2023-26801, CVE-2024-3721, CVE-2025-34037, CVE-2016-10372, CVE-2023-41011, CVE-2016-20016, Realtek Jungle SDK, Linux IoT devices, STUN
• Severity: Critical (Linux malware that exploits known vulnerabilities to compromise internet-facing IoT devices and supports persistence, proxying, tunneling, scanning, and DoS. Its C2 traffic can resemble legitimate Google STUN traffic, so destination-only allowlists may fail to detect it. These capabilities do not establish successful DoS against targets or successful infection of additional devices.)

2. Executive Summary

Cling exploits known vulnerabilities to compromise internet-facing IoT devices and disguises its C2 traffic as legitimate STUN communication. It supports scanning, proxying, tunneling, payload downloading, and flooding attacks. Nozomi received propagation and flood commands through a research client, but did not demonstrate successful DoS against the specified targets or successful infection of additional devices.

3. Attack Flow

Below is the path and functionality centered on the MIPS sample analyzed by Nozomi. We distinguish between intrusion observations in customer telemetry and C2 validation via research clients.

From Realtek Device Compromise to STUN C2 Establishment

1. An attacker sends a UDP datagram starting with orf; to internet-facing Realtek Jungle SDK devices to exploit CVE-2021-35394.
2. The device fetches and executes the MIPS version of Cling using BusyBox wget, establishing persistence via a startup file and wget replacement.
3. Cling collects NAT mappings via STUN Bindings to 13 destinations and sends a custom UDP registration message containing the intrusion method and mapped port list to each of those same destinations. It is not configured to register exclusively with a separate dedicated server.
4. It receives commands embedded in the transaction ID of UDP packets resembling STUN responses, and has the capability to execute scanning, proxying, tunneling, downloading, and DoS attacks.

4. Attacker Position and Execution Location

• In this Realtek path, the remote attacker reaches the vulnerable UDP server from the internet. This is distinct from the reachability conditions of paths using other vulnerabilities.
• The malware and scanner operate on the compromised device, and subsequent scans and floods originate from the victim's network connection.

5. Victim and Administrator Perspective

Victims

• The device may be abused for external scanning, proxying, and DDoS while continuing normal operations.

Administrators

• Clues include STUN traffic at approximately 5-second intervals, all-zero transaction IDs, .cling, startup file additions, wget hash changes, and abnormal outbound scans.

6. Conditions for Success and Failure

Conditions for Success

• Reachability to vulnerable public IoT devices.
• Ability to execute the sample on the target architecture. Establishing C2 additionally requires UDP communication to STUN destinations and the reception of control packets through NAT mappings. Communication blocking alone does not rule out execution on the endpoint.

Failure Conditions and Risk Mitigation

• Restrict management and service reachability from the internet and update to vendor-patched or supported devices.
• Restrict unnecessary STUN traffic by device class, separating known legitimate WebRTC endpoints from IoT devices.
• If compromise is suspected, reflash with clean firmware or replace the device, and change configuration credentials.

7. What Happens Upon Success

• Infected devices can be abused as proxies, TCP tunnels, scanners, and DDoS nodes. Not all functions are necessarily executed on every device.
• Scanning and exploitation capabilities can be used to attempt propagation to vulnerable devices across the IPv4 address space. Assess command reception and successful infection of additional devices separately; receiving a command does not establish that another device was infected.

8. Observable Logs

• Email: No reports indicate that email was used for initial intrusion.
• Proxy / SWG / DNS: Since STUN in this sample uses UDP traffic destined for IP addresses, DNS and HTTP proxy logs alone may not capture transaction IDs. Use packet capture or network sensors capable of analyzing STUN.
• Endpoint / EDR: Check for .cling, wget.r, wget.p, startup file modifications, wget hash changes, and the Cling process.
• Identity / IdP: Identity logs alone do not provide material to identify this incident.
• SaaS / Cloud: Relevant SaaS/cloud audit logs are used to confirm associated authentication, configuration changes, and external API usage.
• Network: Verify STUN Bindings at approximately 5-second intervals, all-zero transaction IDs, custom UDP registration, one of the 13 destinations (145.249.115[.]184), and control packets with TTL differences. Execution of scans, proxies, TCP tunnels, and floods must be verified separately. Do not assume all public STUN destinations are attacker-controlled.

9. Determining Attack Success

• Confirmed Malware Execution or Authentication Success: Public information: Nozomi reported a path leading to the exploitation of CVE-2021-35394 and the acquisition/execution of Cling in customer telemetry. C2 involvement was separately verified using a research client simulating an infected terminal. Criteria: Correlate processes, files, and traffic on the target terminal; do not treat download requests alone as successful execution.
• Confirmed Subsequent Compromise: Public information: Propagation and flood commands along with their targets were received on the research client. No successful DoS on the target side or successful additional infection has been demonstrated. Criteria: Verify the execution of scans/proxies/floods by the organization's compromised devices via traffic and processes, distinguishing this from the actual realization of victim impact.

10. Investigation Playbook

• Starting Point of Investigation: All-zero STUN from IoT devices, periodic bindings, mass scans, and detection of .cling.
• Initial Verification: Check device model, firmware, public ports, CVE applicability, communication destinations, and uptime.
• Endpoint / Server Investigation: Preserve flash/filesystem images, startup files, wget, processes, and cron-equivalent settings.
• Authentication / Cloud Investigation: Verify changes to management credentials and management logs.
• Tracking Subsequent Operations: Track internal/external scan targets, proxy usage, DoS targets, and devices using identical credentials.
• Containment: After network isolation, reflash with clean firmware or replace devices, change credentials, and narrow exposure.
• Distinction of States: Differentiate exploit attempts, binary acquisition, execution, STUN registration, command reception, and subsequent scans/DoS.

11. Defense and Detection Ideas

• Single Event: Generate alerts for STUN traffic with all-zero transaction IDs from IoT devices.
• Time-Series Correlation: Correlate recurring STUN traffic at roughly 5-second intervals with subsequent custom UDP traffic or scans.
• Threat Hunting: Search for .cling, wget.r, wget.p, startup file modifications, and relevant hashes.
• Log Limitations: EDR or other host telemetry may be unavailable on embedded devices, making it difficult to investigate flash modifications and collect process information.
• Priority Mitigations: Prioritize firmware updates/device replacement, external reachability restrictions, IoT segment isolation, and egress control.

12. Facts / Inference / Hypothesis

Facts

• Nozomi Networks observed the acquisition and execution of the MIPS version of Cling, initiated by the exploitation of CVE-2021-35394 against internet-facing Realtek Jungle SDK devices.
• The analyzed MIPS sample possesses scanning and exploitation functions utilizing multiple known vulnerabilities, copying itself to /root/.cling or /usr/local/bin/.cling and appending entries to startup files. It also replaces wget with the malware, retaining the original binary as wget.r.
• The analyzed MIPS sample sends binding requests with all-zero transaction IDs to 13 destinations at approximately 5-second intervals, and sends custom UDP registration messages to each of those same destinations. Legitimate STUN servers do not process this registration, and Nozomi verified the C2 involvement of 145.249.115[.]184 from the list.
• Using a research client that advertised disjoint port sets to different servers, Nozomi confirmed that 145.249.115[.]184 was involved in the botnet's C2 activity. Nozomi assessed subsequent command packets that appeared to come from Google STUN IP addresses as likely source-spoofed, based in part on differences in IP TTL values.
• Commands include execution/download, scanning, TCP tunneling, proxying, scanner termination, and multiple DoS floods.

Inference

• Allowing legitimate STUN infrastructure based solely on destination allowlists may result in overlooking C2 activity unless combined with all-zero transaction IDs, periodicity, and host-side file modifications.

Hypothesis

• Command packets that appeared to come from Google STUN IP addresses were likely sent using spoofed source IP addresses. The actual transmission path has not been independently verified.

13. MITRE ATT&CK Mapping

14. Unknowns and Additional Investigation

• Total infection count across the botnet, operating actors, and compromise duration.
• Actual transmission paths of packets masquerading as Google STUN IPs.
• Whether each listed exploit was used in all samples and campaigns.

15. Impact on SOCs and Organizations

Routers, cameras, and embedded Linux devices running end-of-life firmware or exposing management interfaces may provide similar entry points. Because STUN is also legitimately used by technologies such as WebRTC, correlate traffic intervals, transaction IDs, device types, startup-file changes, and changes to wget hashes rather than relying solely on destination blocking.

16. Summary by Target Audience

• For SOCs: Correlate all-zero STUN transaction IDs, ~5-second intervals, .cling, wget replacements, and scans/floods.
• For Administrators: Reduce internet exposure, update vulnerable firmware or replace devices, and check for modified startup files and wget.
• For Users: Keep home and branch routers and IoT devices up to date, and replace end-of-support products.