ClingSTUN: IoT devices turned into proxies with STUN

On 5 October 2026 FortiGuard Labs, Fortinet’s research team, published its analysis of a Linux backdoor it calls ClingSTUN. The malware gets into routers, cameras, video recorders and other internet-facing devices through known, unpatched vulnerabilities and turns them into remotely controlled proxy nodes. To stay reachable behind NAT it uses legitimate public STUN servers, the same ones that VoIP and WebRTC rely on.

The story was covered by The Hacker News, Dark Reading, Infosecurity Magazine and CSO Online. The Hacker News reports it as the “Cling” botnet and highlights exploitation attempts against the Realtek Jungle SDK; the other outlets use the name ClingSTUN.

What happened

According to the research as reported by Infosecurity Magazine, FortiGuard tracked the campaign across three periods, each with a different download server:

• first period, lasting two days: a single vulnerability, CVE-2022-36553, in Hytec Inter routers;
• second period: CVE-2025-34035 in EnGenius’s IoT cloud service and CVE-2024-23625 in D-Link’s UPnP service; then command injection flaws in Linear, Realtek, TP-Link, AVTECH and D-Link devices;
• third period: new entry points, up to 24 vulnerabilities in total. They include the Ivanti Connect Secure flaws CVE-2023-46805 and CVE-2024-21887 and newer bugs such as CVE-2026-36356 and CVE-2025-67038.

CSO Online also lists TP-Link Archer AX21 routers and AVTECH cameras among the targets, and mentions command injection, code injection and buffer overflow flaws. The sources do not name any victims.

Technical details

The device’s role. ClingSTUN is a back-connect proxy backdoor: the compromised device relays traffic on behalf of the operators and runs their commands. As Jason Soroko of Sectigo told CSO Online, a device does not need to hold sensitive data to be useful to an attacker.

How it uses STUN. The malware sends standard STUN binding requests to public servers (24 in the second version, 13 in the third) to discover its external address and port mappings and to keep NAT bindings open. It then periodically reports a group identifier and its mapped ports to the same servers. The traffic looks like ordinary VoIP and WebRTC communications. FortiGuard points out that how the operator obtains the mappings and pushes commands through NAT has not yet been verified, and warns against treating the STUN services as attacker infrastructure.

Persistence and concealment. Once installed, ClingSTUN:

• kills competing processes and disables the device’s watchdog timer;
• copies itself into hidden system locations;
• adds itself to startup by modifying /etc/inittab, /etc/init.d/rcs and /etc/rc.d/rc.boot (paths as reported by CSO Online);
• makes its /proc entry look like that of the system’s init process.

Execution and propagation. It supports remote command execution and carries exploits for seven more vulnerabilities, including flaws in Realtek’s SDK and in three DVR products, which it uses to spread to other devices. It is built for ARM, Intel 80386, MIPS, PowerPC and x86-64.

Public indicators. The articles we reviewed do not include hashes or addresses: the indicators of compromise are in FortiGuard Labs’ original research.

MITRE ATT&CK (mapped from the reported facts): T1190 (Exploit Public-Facing Application), T1105 (Ingress Tool Transfer), T1037.004 (Boot or Logon Initialization Scripts: RC Scripts), T1036 (Masquerading), T1059.004 (Unix Shell), T1090 (Proxy), T1210 (Exploitation of Remote Services).

Impact for European and Italian companies

The sources do not mention victims in Europe, but the affected devices are common here too: small-office routers, CCTV cameras and video recorders, network gear forgotten in a cabinet. Once such a device becomes a proxy, someone else’s traffic leaves through your connection, and your IP address can show up in the logs of attacks against third parties.

The presence of Ivanti Connect Secure on the list is a reminder that the same operator is not only after IoT: unpatched VPN gateways are a way into the corporate network. For entities in scope of NIS2, Article 21 requires vulnerability handling and security in the acquisition and maintenance of systems: out-of-support cameras and routers are part of the perimeter you need to manage.

Opinions differ on the approach. Louis Eichenbaum of ColorTokens recommends compensating controls and microsegmentation for devices that cannot be patched right away; John Gallagher of Viakoo argues instead that segmentation alone is not enough and calls for automated firmware remediation across multivendor IoT fleets.

What to do now

1. Inventory your internet-facing devices, with model, firmware version and vendor support status.
2. Patch first the devices affected by the CVEs listed above, and Ivanti Connect Secure in particular for CVE-2023-46805 and CVE-2024-21887.
3. Replace or isolate devices that no longer receive updates: no management interfaces and no UPnP exposed to the internet.
4. Filter outbound traffic from camera, DVR and IoT networks: allow only the destinations they actually need.
5. Look for STUN traffic where it makes no sense. A DVR or camera that regularly contacts public STUN servers, or opens unexpected UDP connections with recurring keepalives, should be checked. As Soroko puts it, what matters is the device’s behaviour, not the destination’s reputation.
6. On devices where you have a shell, check the startup entries in /etc/inittab and in the scripts under /etc/init.d/ and /etc/rc.d/, and see whether more than one process presents itself as init.
7. Compare your logs with the indicators of compromise published by FortiGuard Labs.

How ARXDOME helps

ARX Expose shows from the outside the open ports, recognised products and known vulnerabilities on your public services: this is where management interfaces and devices exposed by mistake show up. ARX Watch finds devices without a probe on the network, such as cameras and video recorders, and alerts you when a new one appears. ARX Sentry collects firewall logs and brings them into the SOC pages and the NOC map, including rejected connections and blocked outbound traffic. You cannot install an agent on IoT devices: visibility comes from the network and the firewall.

Last updated: 6 October 2026