Kalyxo

Kalyxo / Incident notes

A router emits three violet pulses toward a layered system view that conceals a dark process silhouette.

ClingSTUN campaign evolves across vulnerable Linux devices

Published

Fortinet traces three download periods for a persistent IoT backdoor and describes a Linux process-concealment technique. Its STUN command path remains unresolved.

A campaign with changing entry points

FortiGuard Labs’ October 5 analysis describes ClingSTUN as a persistent Linux back-connect proxy installed on internet-facing devices through known vulnerabilities. Researchers divide the activity into three periods, each tied to a different malware download source. The later period adds a broader set of router and IoT entry points, including command-injection and authentication-bypass flaws. This is a timeline of observed infrastructure and techniques, not a count of victims. (FortiGuard Labs analysis)

The report also follows three downloader generations. In the third, the downloader inspects /proc/mounts and can unmount process-related mounts and terminate processes. When the backdoor runs as root, it copies selected process metadata from PID 1 and bind-mounts it over its own /proc/<pid> directory, making its process details appear different to local inspection tools.

STUN traffic needs context

ClingSTUN contacts public STUN endpoints to learn mapped addresses and ports and maintain NAT bindings. Fortinet found that the malware periodically sends a group identifier and mapped-port list to those endpoints, but did not identify a separate coordination-server registration. The report says how an operator obtains the mapping and delivers control traffic through NAT remains unverified. Public STUN traffic alone therefore does not establish that a legitimate STUN provider relayed commands.

Nozomi’s October 1 report analyzes a MIPS sample with a different observed path: a custom registration datagram sent to 13 STUN endpoints, followed by command packets sent to mapped ports. Nozomi’s experiment did not establish that a legitimate Google STUN service relayed those commands. These analyses share STUN-related behavior, but their reported command-delivery observations should not be collapsed into one confirmed mechanism. (Nozomi Networks Labs analysis)

For defenders, investigate unusual STUN-like UDP activity from exposed routers and Linux-based IoT devices alongside persistence changes, unexpected process termination, and firmware exposure. Do not classify a public STUN service as attacker-controlled infrastructure from the destination address alone.

Sources

  1. ClingSTUN Linux Backdoor Abuses Public STUN Infrastructure
  2. A STUNning Disguise: Cling Malware Masquerades as Google

Follow Kalyxo via RSS

Privacy choices