Angreifer nutzen GSocket, ein legitimes Open-Source-Werkzeug für Fernzugriff, um kompromittierte Linux-Server auch dann unter Kontrolle zu halten, wenn Administratoren die Schwachstellen schließen, über die sie eingedrungen sind. In einem Bericht von Microsoft vom 11. November wurden mehrere Angriffe beschrieben, bei denen das Werkzeug die Behebung in den Anwendungen überstand. Verteidiger müssen deshalb den Host untersuchen und die Persistenz entfernen, nicht nur die ursprüngliche Schwachstelle beheben.
Besonders betroffen sind Webanwendungen und Hosting-Umgebungen. Die Telemetriedaten von Microsoft Defender for Endpoint zeigten von März bis August 2026 einen Anstieg der Geräte mit GSocket-bezogenen Erkennungen um 356,2 %, wobei die Entwicklung von Monat zu Monat unterschiedlich verlief. Gemessen werden damit Geräte mit Erkennungen, nicht die Zahl bestätigter erfolgreicher Angriffe.
BleepingComputer berichtete am 12. November unter Berufung auf Microsoft, dass 87,1 % der erkannten Vorfälle Webanwendungen und Hosting betrafen. Anteile von 63,9 % entfielen auf PHP-Webanwendungen und cPanel-Hosting, 24,3 % auf Apache. Am stärksten ins Visier genommen wurden Bildung und Forschung, gefolgt von Technologie und Kommunikation, Industrie und Behörden.
Wie der Zugriff einen Patch überdauert
Microsoft beobachtete, wie Angreifer über aus dem Internet erreichbare Anwendungen Befehle unter dem Konto des Webdienstes ausführten und anschließend GSocket installierten. Da der Relay-Client unabhängig von der verwundbaren Anwendung läuft, entfernt ein Patch dieser Anwendung weder den Client noch die Mechanismen, die ihn neu starten.
GSocket leitet den Datenverkehr über das Global Socket Relay Network, einen gemeinsam genutzten öffentlichen Dienst. Der kompromittierte Server und der Angreifer bauen jeweils eine ausgehende Verbindung zu einem Relay auf, das beide über einen Ende-zu-Ende-verschlüsselten Kanal miteinander verbindet. Der Server benötigt weder einen eingehenden Lauschdienst noch eine öffentliche IP-Adresse. Network Address Translation, mit der Systeme eine externe Adresse gemeinsam nutzen, verhindert die Verbindung nicht.
So erhalten Angreifer Fernzugriff, ohne einen eigenen Command-and-Control-Server zu betreiben, also jene Infrastruktur, über die kompromittierte Systeme normalerweise gesteuert werden. Sie können sich ohne Kenntnis der IP-Adresse oder des Hostnamens des kompromittierten Servers wieder verbinden. Es gibt daher keine angreiferkontrollierte Adresse oder Domain, die Verteidiger blockieren könnten, wenngleich Organisationen den Zugriff auf das Relay-Netzwerk selbst einschränken können.
Eingehende Firewall-Regeln erfassen diesen ausgehenden Datenverkehr nicht. Ausgangsfilterung und Überwachung können das.
Microsoft erklärte, dass mehrere voneinander unabhängige Bedrohungsakteure GSocket übernommen haben. Das Bereitstellungsskript kann Prozesse umbenennen, Dateien in speicherbasierten Verzeichnissen ablegen und Mechanismen installieren, die einen Neustart überstehen sollen. Forscher beobachteten, dass Angreifer Prozesse als Linux-Kernel-Threads tarnten und Cron-Jobs, systemd-Dienste und Shell-Startdateien nutzten, um den Zugriff aufrechtzuerhalten. Persistenz über Neustarts hinweg und erfolgreiche Relay-Sitzungen waren nicht in jedem analysierten Angriff bestätigt.
In einigen Fällen versuchten Angreifer außerdem, die Linux-Kernel-Schwachstelle CVE-2026-43284 auszunutzen, die BleepingComputer als „Dirty Frag“ beschreibt, um vom Konto des Webdienstes auf root zu gelangen, das Konto mit den höchsten Rechten unter Linux. Microsoft stuft diese Vorgänge als Ausnutzungsversuche ein.
Wonach Verteidiger suchen können
Die von Microsoft beobachteten Warnmeldungen betrafen verdächtige Shells, die von Webservern und Anwendungslaufzeitumgebungen gestartet wurden, die Ausführung von GSocket, das Herunterladen von Nutzlasten, Cron-Jobs und neu angelegte Linux-Dienste. Weitere Signale waren die Ausführung versteckter Dateien, Verschleierung, veränderte Zeitstempel, das Löschen laufender Binärdateien, Versuche, den Befehlsverlauf zu löschen, Systemaufklärung und Reverse-Shell-Verhalten. Eine einzelne Warnung belegt weder den anfänglichen Zugangsweg, noch zeigt sie, dass jede Phase eines Angriffs erfolgreich war.
Microsoft beobachtete zum Beispiel einen Bash-Befehl, der die umbenannte Nutzlast /usr/bin/defunct aufrief, zusammen mit Verweisen auf defunct.service und einen Link multi-user.target.wants, der zum Aktivieren eines systemd-Dienstes diente. Das zeigt, warum Administratoren nicht nur auf erkennbare GSocket-Dateinamen achten sollten, sondern auch auf unauffällig wirkende Dienstnamen.
Microsoft hat Defender-XDR-Hunting-Abfragen veröffentlicht, die die vorangegangenen sieben Tage abdecken. Sie durchsuchen Prozessnamen und Befehlszeilen nach gs-netcat, gsocket, gsnetcat und gsocket.io und zeigen anschließend Konto, Pfad und übergeordneten Prozess zur Untersuchung an. Weitere Abfragen prüfen Download-Aktivitäten und Netzwerkverbindungen zu gsocket.io und gsgg.b-cdn.net.
Diese Domains sowie cdn.gsocket.io verteilen das legitime Werkzeug; sie sind keine vom Angreifer kontrollierte Command-and-Control-Infrastruktur. Beobachtete Abruf-Ziele waren hxxps://gsocket[.]io/y und hxxps://gsocket[.]io/install.sh, wobei ein erfolgreicher Abruf über die zweite Adresse nicht nachgewiesen ist.
Dateisuchen decken Pfade ab, die mit /dev/shm/.gs- beginnen, sowie Namen wie systemd-remount-d, .gsn_ora, defunct und defunct.service. Microsoft hat außerdem diese konkreten Dateibeobachtungen und SHA-256-Fingerabdrücke veröffentlicht:
/dev/shm/.gs-0/gs-netcat_mini-linux-x86_64:d94f75a70b5cabaf786ac57177ed841732e62bdcc9a29e06e5b41d9be567bcfa/dev/shm/.gs-0/gs-netcat_mini-linux-aarch64:f95c4d029e6784e3849b4d1e2e2ae1a661187236ef7c5d487c71158a290a03b5/tmp/systemd-remount-dund/usr/bin/systemd-remount-d:55d141bb2f62c527c3fea3413b8429fed7d52633d0b123b5e611bfa42165229f/tmp/.gsn_ora:12450bafc7a4398040e1ad3a16dbf4dbc79b6a8f83ef306c4f0f73f59886f06c
Die architekturspezifischen Binärdateien standen im Zusammenhang mit Downloads von hxxps://gsgg[.]b-cdn[.]net/bin/gs-netcat_mini-linux-x86_64 und hxxps://cdn[.]gsocket[.]io/bin/gs-netcat_mini-linux-aarch64. Diese Indikatoren stellen einzelne Beobachtungen dar, keine vollständige Bestandsaufnahme. Microsoft rät, Treffer zusammen mit Prozessherkunft, Ausführungskontext, Persistenzänderungen und Netzwerkaktivität zu untersuchen.
Den Zugang ebenso entfernen wie die Schwachstelle
Administratoren, die betroffene Linux-Server untersuchen, sollten laut Microsoft den nicht autorisierten GSocket-Client, bereitgestellte Dateien und die zugehörige Persistenz entfernen und anschließend prüfen, ob ausgehende Verbindungen zur Relay-Infrastruktur beendet sind. Das Stoppen des laufenden Prozesses allein kann andere Neustart-Mechanismen intakt lassen.
Das Unternehmen empfiehlt außerdem, Cron-Einträge, systemd-Units und Shell-Startdateien zu prüfen, Deny-by-default-Regeln für ausgehenden Datenverkehr anzuwenden, die nur die erforderlichen Ziele erlauben, und Relay-Verbindungen zu überwachen. Wo möglich, sollten temporäre und speicherbasierte Verzeichnisse nicht ausführbar eingebunden werden, mit Warnungen bei Ausführung aus versteckten oder weltweit beschreibbaren Pfaden.
Aus dem Internet erreichbare Anwendungen, Content-Management-Systeme, Plugins und Application-Server sollten stets aktuell gehalten werden. Microsoft rät, nicht benötigte Komponenten zu entfernen und Upload- sowie Administrationspfade einzuschränken. Administratoren sollten außerdem Patches für lokale Rechteausweitungen priorisieren, einschließlich CVE-2026-43284. Als separaten Kontext zu dieser Empfehlung verwies Microsoft auf die Arbeit des FORGE Lab zu 59 Linux-Kernel-Fehlerberichten, darunter acht Schwachstellen, für die in kontrollierten Umgebungen lokale Root-Exploits demonstriert wurden.
Für Organisationen, die Defender for Endpoint unter Linux einsetzen, empfiehlt Microsoft, Echtzeitschutz, cloudbasierten Schutz und Verhaltensüberwachung aktiviert zu lassen, einschließlich der Überwachung ungewöhnlicher Kindprozesse von Webdiensten und getarnter Prozessidentitäten. Auf das Einspielen von Anwendungspatches sollten die Bereinigung des Hosts und die Prüfung folgen, dass die Relay-Verbindungen beendet sind.
