ClingSTUN: Linux-Backdoor missbraucht öffentliche STUN-Dienste
ClingSTUN nutzt ungepatchte Router und IoT-Geräte als Proxy-Knoten. Admins sollten Firmware, Internetzugänge und verdächtige Prozesse prüfen, öffentliche STUN-Server aber nicht pauschal blockieren.
Internetexponierte Linux-Router und IoT-Geräte mit ungepatchter Firmware sollten jetzt auf bekannte Sicherheitslücken und Kompromittierung geprüft werden. FortiGuard Labs beschreibt im Bericht vom 5. Oktober 2026 die Backdoor ClingSTUN, die unter anderem Realtek-SDK-Komponenten, TP-Link Archer AX21 sowie Geräte von D-Link und EnGenius angreift. Ein universelles ClingSTUN-Update gibt es nicht: Entscheidend sind die jeweiligen Herstellerkorrekturen und tatsächlich erreichbaren Dienste.
Die Meldung bedeutet nicht, dass jeder Linux-Server oder jede Videokonferenzanwendung betroffen ist. Gepatchte Geräte ohne die genannten verwundbaren Komponenten sind durch diese dokumentierten Einstiegspfade nicht betroffen. Bei exponierten Altsystemen reicht ein späteres Wartungsfenster dagegen nicht als erste Reaktion: Erreichbarkeit und Patchstand gehören kurzfristig geprüft, verdächtige Geräte isoliert.
Bekannte Schwachstellen öffnen den Einstieg
Fortinet beobachtete zunächst Angriffe auf Hytec-Inter-Router HWL-2511-SS über CVE-2022-36553. Später erweiterte die Kampagne ihre Einstiegspunkte deutlich. Die Forscher nennen unter anderem Realtek SDK mit CVE-2021-35394, TP-Link Archer AX21 mit CVE-2023-1389 und EnGenius EnShare mit CVE-2025-34035. Es handelt sich um die Ausnutzung bekannter Fehler, nicht um eine neu entdeckte allgemeine Linux-Schwachstelle.
Die Downloadskripte holen Varianten für ARM, Intel 80386, MIPS R3000, PowerPC und AMD x86-64. Damit beschränkt sich die Suche nicht auf klassische Server. Router, Kameras und Videorekorder können ebenso als dauerhaft erreichbare Proxy-Knoten missbraucht werden. Eine vollständige Zuordnung aller OEM-Geräte und Firmwarestände liefert der Bericht nicht.
Persistenz über versteckte Dateien und Startskripte
Die technische Analyse beschreibt Kopien nach /root/.cling und /usr/local/bin/.cling. Einträge in /etc/inittab, /etc/init.d/rcS und /etc/rc.d/rc.boot sollen die Malware beim Booten erneut ausführen. ClingSTUN beendet außerdem konkurrierende Prozesse und manipuliert den Watchdog. Ein Neustart allein ist deshalb keine belastbare Bereinigung.
Unter Root-Rechten kann die Malware Prozessinformationen verschleiern: Sie kopiert ausgewählte Informationen von Prozess 1 und überlagert ihr eigenes Verzeichnis unter /proc durch einen Bind-Mount. Eine scheinbar unauffällige Prozessliste schließt den Befall somit nicht aus. Netzwerkdaten und Veränderungen der Startkonfiguration müssen gemeinsam bewertet werden.
STUN-Verkehr ist kein automatischer Schadensnachweis
STUN hilft legitimen Anwendungen, externe IP-Adressen und Portzuordnungen hinter NAT zu ermitteln. ClingSTUN missbraucht öffentliche Dienste für solche Binding-Anfragen und zum Erhalt der NAT-Zuordnung. Der Verkehr kann daher zwischen normaler VoIP- und WebRTC-Kommunikation untergehen. Fortinet beschreibt zunächst 24 öffentliche Endpunkte, in einer späteren Variante 13.
Nach dem Austausch sendet die Malware Gruppenkennung und zugeordnete Ports an dieselben Endpunkte. Wie der Betreiber diese Zuordnung erhält und Steuerverkehr durch NAT zustellt, bleibt laut Fortinet unbestätigt. Beschrieben ist hingegen die Verarbeitung eines Steuerpakets, das eine zusätzliche ausgehende TCP-Verbindung für den Empfang und die Ausführung von Befehlen auslösen kann.
Gesicherte Beobachtung und offene Fragen trennen
- Fortinet belegt Persistenz, Fernbefehle und sieben fest eingebaute Exploits zur Selbstverbreitung in den analysierten Varianten.
- SecurityWeek bestätigt die Kernaussagen als Bericht über Fortinets Analyse, nicht als eigene Untersuchung sämtlicher Opfer.
- The Hacker News ergänzt ältere Nozomi-Beobachtungen zu Cling und das aktuelle Fortinet-Update. Abweichende Details zur Steuerung sind keine bestätigte Erklärung des Fortinet-Befunds.
- Legitime öffentliche STUN-Server dürfen nicht pauschal als angreiferkontrollierte Infrastruktur eingestuft werden. Eine belastbare Opferzahl nennt Fortinet nicht.
Welche Prüfungen jetzt Priorität haben
- Geräteinventar mit Modell, Firmware, Supportstatus und extern erreichbaren Diensten abgleichen, besonders bei den konkret genannten Herstellern und Komponenten.
- Verfügbare Sicherheitsupdates für die jeweils vorhandenen Schwachstellen priorisieren. Nicht mehr unterstützte Geräte ersetzen oder wirksam isolieren.
- Unnötige Fernverwaltung und Portfreigaben entfernen. Erforderliche Verwaltungszugänge auf vertrauenswürdige Netze begrenzen.
- Versteckte Cling-Dateien, veränderte Startskripte und ungewöhnliche Mounts mit dem bekannten Sollzustand vergleichen.
- Wiederkehrende UDP-Anfragen mit unerwarteten Prozessen und anschließenden TCP-Verbindungen korrelieren, statt STUN allein zu blockieren.
- Bei Befallsverdacht Netzwerkzugang einschränken, Spuren sichern und eine vertrauenswürdige Wiederherstellung planen. Ein Firmwareupdate allein beweist keine Entfernung der Persistenz.
Passende Anleitungen auf S-EDV
- Netzwerkdokumentation und IPAM: Gerätebestand und Zuständigkeiten als Grundlage der Betroffenheitsprüfung erfassen.
- Netzwerksegmentierung mit VLANs und Firewall-Regeln: IoT-Geräte von schützenswerten Unternehmensdiensten trennen.
