GSocket auf Linux-Servern: Die Hintertür bleibt nach dem Patch aktiv

Mehrere Angreifergruppen setzen das Open-Source-Werkzeug GSocket auf Linux-Servern ein und behalten damit Zugriff, auch nachdem die ursprünglich ausgenutzte Lücke gepatcht ist. Das berichtet BleepingComputer am 12. November 2026. Laut Telemetrie von Microsoft Defender for Endpoint stiegen die GSocket-bezogenen Erkennungen zwischen März und August um 356,2 Prozent. Betroffen sind vor allem Webanwendungen und Hosting-Umgebungen, und ein Update allein entfernt die installierte Hintertür nicht.

Wie GSocket Firewall und NAT umgeht

GSocket verbindet zwei Programme über einen öffentlichen Relay-Dienst, ohne dass eine Seite eine erreichbare IP-Adresse braucht. Das Projekt steht unter BSD-2-Clause-Lizenz im Repository hackerschoice/gsocket auf GitHub und wirbt mit dem Satz „Connect like there is no firewall. Securely.“ Laut README tauscht das gleichnamige Werkzeug gsocket die IP-Schicht eines Programms gegen eine eigene Transportschicht. Der Verkehr läuft dann über das Global Socket Relay Network, kurz GSRN, einen frei nutzbaren Cloud-Dienst. Zum Paket gehören gs-netcat, gs-sftp, gs-mount und das Kopierwerkzeug blitz. Upstream listet das Quellpaket in Version 1.4.41.

Für Angreifende ist vor allem gs-netcat interessant. Das Werkzeug liefert laut README eine interaktive Shell mit echtem PTY, Dateiübertragung und einen SOCKS-Proxy ins dahinterliegende Netz. Vorkompilierte statische Binärdateien gibt es laut README für AMD64, ARM64, MIPS und weitere Architekturen.

Beide Endpunkte bauen laut Microsoft ausgehende Verbindungen zum Relay auf. Das Relay führt die zwei Sitzungen zusammen. Daraus entsteht eine Ende-zu-Ende-verschlüsselte Verbindung. Der kompromittierte Host braucht weder einen offenen Port noch eine öffentliche IP-Adresse. NAT, die Adressumsetzung in Routern und Gateways, verhindert die Verbindung laut Microsoft nicht. Angreifende finden den Server über ein gemeinsames Geheimnis wieder, ohne IP-Adresse oder Hostnamen zu kennen. Einen eigenen Command-and-Control-Server, kurz C2, für die Fernsteuerung brauchen sie nicht.

Eingehende Firewall-Regeln erkennen den GSocket-Verkehr laut Microsoft nicht. Sperrlisten für IP-Adressen oder Domains stören die Angreifenden kaum, weil sie keine feste Adresse des Opfers brauchen. Wirksam sind nach Microsofts Angaben Egress-Filter, also Regeln für ausgehenden Verkehr, und das Überwachen ausgehender Verbindungen. Den Inhalt der Sitzungen können weder das GSRN noch ein Provider lesen. Das README nennt SRP nach RFC 5054, AES-256 und einen Schlüsselaustausch mit 4096-Bit-Primzahl. Sichtbar bleibt laut README nur, wer mit wem kommuniziert. Für Verteidigende ist genau diese Metadatenspur der Ansatzpunkt.

Webhosting trägt die Hauptlast: PHP, cPanel, Apache

Webanwendungen und Hosting-Umgebungen machen laut Microsoft 87,1 Prozent der erkannten Vorfälle mit GSocket aus. Auf PHP-Webanwendungen und cPanel-Hosting entfallen 63,9 Prozent, auf Apache 24,3 Prozent. cPanel ist eine verbreitete Verwaltungsoberfläche für Hosting-Server. Hosting-Backends rücken damit erneut ins Zentrum, wie schon bei der cPanel-Lücke und der Sorry-Ransomware.

Nach Branchen liegen laut Microsoft Bildung und Forschung vorn. Es folgen Technologie und Kommunikation, Fertigung sowie Behörden. Absolute Fallzahlen nennt der Bericht nicht. Die prozentuale Steigerung misst Erkennungen in der Defender-Telemetrie. Sie beschreibt also, was bei Microsoft-Kunden sichtbar wird, und keine Gesamtzahl kompromittierter Server.

Neu ist die Masche nicht. Im März 2026 beschrieb das SANS Internet Storm Center ein Bash-Skript, das eine GSocket-Hintertür installiert. Aviatrix und SOC Prime griffen die Analyse am 20. und 24. März auf. Das Skript erkennt laut SOC Prime zuerst das Betriebssystem und lädt dann gs-netcat nach. Aviatrix nennt Linux und macOS als Ziele. Die von Microsoft gezählten Fälle betreffen dagegen Server mit Webanwendungen. Ein Desktop ohne öffentlich erreichbaren Dienst bietet den beobachteten Einstiegswegen deutlich weniger Fläche.

Wo sich die GSocket-Hintertür einnistet

Die Angreifenden tarnen GSocket laut Microsoft als Kernel-Thread und verankern es über Cron-Jobs, systemd-Dienste und Shell-Startdateien. Cron ist der klassische Zeitplaner unter Linux, systemd der Dienstemanager der meisten Distributionen. Ein ps aux auf einem befallenen Server zeigt deshalb keinen Prozess namens gs-netcat. Der Eintrag ähnelt eher einem der vielen Kernel-Threads in eckigen Klammern. Das Upstream-README dokumentiert solche Tricks selbst. Es zeigt, wie sich gs-netcat per exec -a als -bash oder als rsyslogd ausgibt.

Dieses Bild wurde mit KI generiertProviderhiggsfieldModellgpt_image_2_5 flare high 1k 16:9PromptFlat vector illustration, schematic and without any numbers. On the left, a terminal window titled "ps aux" with a list of rows, most of them in square brackets like kernel threads. One row wears a small mask icon and is marked "gs-netcat". On the right, a folder icon labeled ".ssh" hides a dark binary file behind it, and next to it a clock with a counterclockwise arrow stands for reset timestamps. A thin line connects the masked row to the hidden file. Limited palette of deep navy, teal, and warm orange on a light gray background, clean geometric shapes, even lighting, no people. No watermark, no signature.

Die folgende Tabelle zeigt die Verstecke, die Microsoft und die Analysen vom März dokumentiert haben.

Hinzu kommt Spurenverwischung. Das Skript vom März setzt laut Aviatrix und SOC Prime die Zeitstempel veränderter Dateien zurück. Eine Suche mit find -mtime nach frisch geänderten Dateien greift dann zu kurz. Der Watchdog-Modus von gs-netcat ist laut README über den Schalter -D erreichbar. Der Prozess startet nach einem Kill automatisch neu. Ein einzelnes kill reicht also nicht.

In einigen Fällen versuchten die Angreifenden laut Microsoft, die Kernel-Lücke Dirty Frag auszunutzen, um Root-Rechte zu erlangen. Die Lücke trägt die Kennung CVE-2026-43284; CVE ist das öffentliche Nummernsystem für Schwachstellen. Mit Root-Rechten stehen systemweite Verstecke wie systemd-Units offen. Ohne Root bleiben Nutzer-Crontab und ~/.profile. Kernel-Lücken als Sprungbrett zu Root sind derzeit ein Dauerthema, wie unser Bericht über Root-Lücken aus einer KI-Pipeline zeigt.

Warum ein Patch allein den Zugang nicht kappt

Ein Sicherheitsupdate schließt den ursprünglichen Einstiegspunkt, ein bereits installiertes GSocket läuft laut BleepingComputer aber weiter. Die Hintertür hängt an keiner Schwachstelle. Sie nutzt ein legitimes Programm und ausgehende Verbindungen. TechJack Solutions stufte die Kampagne am 21. März als Werkzeugmissbrauch ohne zugehörige CVE ein. GSocket selbst sei keine verwundbare Software, einen Hersteller-Patch gebe es deshalb nicht. Als betroffene Distribution nennt TechJack Ubuntu ausdrücklich.

Für die Arbeit nach einem Vorfall ändert sich damit die Reihenfolge. Wer eine PHP-Anwendung oder ein cPanel-Konto im regulären Release-Zyklus patcht, muss den Server danach gezielt nach Persistenz absuchen. Das gilt auch ohne Alarm im Monitoring. Der Verkehr zum Relay ist verschlüsselt und läuft nach außen. Heikel ist das Verzeichnis ~/.ssh, weil dort echte und gefälschte Schlüssel nebeneinander liegen. SSH-Zugänge selbst sind ebenfalls angreifbar, wie die OpenSSH-Lücke SSHole auf Alpine-Servern zeigt.

Das gemeinsame Geheimnis ist der eigentliche Schlüssel zum Server. Laut README kann jede Person, die es kennt, eine Verbindung aufbauen. Bei mehreren Eingeweihten kann der Host nicht unterscheiden, wer sich gerade verbindet. Übergeben lässt sich das Geheimnis laut README auch per Umgebungsvariable GSOCKET_ARGS. In den Argumenten der Prozessliste erscheint es dann nicht. Ein gefundenes Geheimnis gehört sofort entwertet. Wer GSocket bewusst für die Fernwartung einsetzt, sollte das im Betriebshandbuch festhalten. Jeder andere Fund ist ein Sicherheitsvorfall.

So räumen Sie einen befallenen Server sauber auf

Microsoft empfiehlt, GSocket samt zugehöriger Dateien zu entfernen und danach zu prüfen, ob die ausgehenden Verbindungen zum Relay-Netz aufgehört haben. SOC Prime rät zusätzlich, den Host zu isolieren, Skript und Binärdateien zu sichern und eine forensische Prüfung zu beginnen. Erst sichern, dann löschen. Wer Artefakte vorher entfernt, verliert die Spur zum Einstiegspunkt.

Die folgenden Schritte bringen die Empfehlungen von Microsoft und SOC Prime in eine pragmatische Reihenfolge.

1. Nehmen Sie den Server vom Netz und sichern Sie Skripte, Binärdateien und Logs für die Analyse.
2. Prüfen Sie die Crontabs aller Konten, alle systemd-Units und Shell-Startdateien wie ~/.profile auf unbekannte Einträge.
3. Untersuchen Sie ~/.ssh auf ausführbare Dateien und auf Schlüsseldateien, die keine echten Schlüssel sind.
4. Entfernen Sie GSocket, alle Persistenzeinträge und die zugehörigen Dateien.
5. Rotieren Sie betroffene SSH-Schlüssel und entwerten Sie gefundene gemeinsame Geheimnisse.
6. Spielen Sie ausstehende Updates ein, darunter den Kernel-Patch für CVE-2026-43284.
7. Prüfen Sie nach dem Neustart, ob der Server noch ausgehende Verbindungen zum GSRN aufbaut.

Tipp: Lassen Sie Ihre Erkennung nach Empfehlung von SOC Prime auf den Dateinamen gs-netcat und auf Befehle anschlagen, die Zeitstempel manipulieren.

Dauerhaft hilft laut Microsoft vor allem, ausgehenden Verkehr auf vorab festgelegte Ziele zu beschränken. Ein Webserver braucht meist Paketquellen, Zeitserver und wenige APIs, selten beliebige Hosts. SOC Prime empfiehlt, bekannte Relay-Domains und IP-Adressen von GSocket zu sperren und Startdateien per Integritätsmonitoring zu überwachen. Eine Positivliste ist robuster als eine Sperrliste. Das README dokumentiert die Option, Verbindungen über Tor zu leiten. Pro Dienst sauber dokumentiert, bleibt ein Egress-Filter wartbar.

Offen bleibt, welche Gruppen hinter den Kampagnen stehen; BleepingComputer nennt keine Namen. Hosting-Admins mit PHP- oder cPanel-Systemen sollten die Prüfschritte noch in dieser Woche abarbeiten, auch auf Servern, die seit März unauffällig laufen.