GSocket-Backdoor auf Linux-Webservern: PHP-, cPanel- und Apache-Hosts auf Kompromittierung prüfen

Was passiert ist

Am 11. November 2026 veröffentlichte Microsoft Forschungsergebnisse zu mehreren voneinander unabhängigen Angreifergruppen, die GSocket auf kompromittierten Linux-Servern installieren. BleepingComputer berichtete am 12. November 2026 darüber. GSocket ist ein legitimes Open-Source-Werkzeug für Fernzugriff. Sobald es auf einem Server läuft, bauen sowohl der Server als auch der Angreifer ausgehende Verbindungen zu einem öffentlichen Relay-Dienst auf, dem Global Socket Relay Network. Das Relay verbindet die beiden dann zu einer verschlüsselten Sitzung. Der Server benötigt weder einen offenen Port noch eine öffentliche IP-Adresse. Die Angreifer betreiben keine eigene Infrastruktur, daher gibt es keine Angreifer-IP-Adresse und keine Domain, die Sie blockieren könnten.

Dabei handelt es sich nicht um eine Schwachstelle in GSocket. Die Angreifer brechen zunächst in eine aus dem Internet erreichbare Webanwendung ein und installieren dann GSocket, um ihren Zugriff zu sichern. Da GSocket getrennt von der Anwendung läuft, entfernt das Patchen der Anwendung GSocket nicht. Microsoft zufolge stiegen die GSocket-bezogenen Erkennungen in der eigenen Telemetrie zwischen März und August 2026 um 356,2 %.

Microsoft beschreibt die Angriffe wie folgt:

• Die Angreifer nutzen eine Webanwendung aus und verwenden curl, um ein Installationsskript herunterzuladen und auszuführen.
• Das Skript legt den GSocket-Client in beschreibbaren oder speicherbasierten Pfaden wie /dev/shm ab.
• Der Prozess ist unter Namen getarnt, die wie Kernel-Threads aussehen, etwa [kaluad], oder unter systemähnlichen Namen wie systemd-remount-d und /usr/bin/defunct.
• Die Persistenz wird über Cron-Jobs, systemd-Dienste, Shell-Startdateien, Watchdogs und zusätzliche Kopien eingerichtet. Anschließend werden Staging-Dateien gelöscht und Dateizeitstempel zurückdatiert.
• In einigen Fällen versuchten die Angreifer, über die Linux-Kernel-Schwachstelle CVE-2026-43284, bekannt als "Dirty Frag", Root-Rechte zu erlangen.

Wer betroffen ist

Betroffen sind Linux-Server, auf denen aus dem Internet erreichbare Webanwendungen laufen, die zu einem beliebigen Zeitpunkt kompromittiert wurden. In den Daten von Microsoft betrafen 87,1 % der Vorfälle Webanwendungen und Hosting. Innerhalb dieser Gruppe entfielen 63,9 % auf PHP-Webanwendungen und cPanel-Hosting und 24,3 % auf Apache. Microsoft führt außerdem Warnmeldungen zu Shells auf, die aus Java- und Node.js-Webanwendungen gestartet wurden. Server, auf denen eine Schwachstelle in einer Webanwendung gefunden und kürzlich gepatcht wurde, sollten besonders geprüft werden, da die Angreifer möglicherweise vor dem Patch eingedrungen sind.

Server, deren Webanwendungen nie kompromittiert wurden, sind nicht betroffen. GSocket, das Ihr eigenes Team absichtlich installiert hat, ist für sich genommen kein Hinweis auf eine Kompromittierung.

Was Sie jetzt tun sollten

1. Prüfen Sie jeden aus dem Internet erreichbaren Linux-Webserver anhand der Schritte im nächsten Abschnitt. Beginnen Sie mit Servern, auf denen in den letzten Monaten eine Schwachstelle in einer Webanwendung, einem CMS, einem Plugin oder einem Hosting-Panel geschlossen wurde.
2. Wenn Sie GSocket finden, behandeln Sie den Server als kompromittiert. Beenden Sie den Prozess. Entfernen Sie anschließend das Binary, alle Kopien und alle Autostart-Einträge: Cron, systemd-Units, Shell-Startdateien und Watchdog-Skripte. Microsoft weist darauf hin, dass die Persistenz häufig mehrschichtig aufgebaut ist, sodass das Beenden des Prozesses allein den Zugriff nicht entfernt. Falls die Angreifer möglicherweise Root-Rechte erlangt haben, etwa über CVE-2026-43284, ist die sicherste Option, den Server aus einem sauberen Image oder einem Backup neu aufzusetzen, das vor der Kompromittierung erstellt wurde.
3. Ändern Sie die Zugangsdaten auf einem betroffenen Server: Datenbankpasswörter, Anwendungsgeheimnisse, API-Schlüssel und SSH-Schlüssel. Prüfen Sie außerdem authorized_keys auf unbekannte Einträge.
4. Finden und schließen Sie den Zugangsweg. Aktualisieren Sie Webanwendungen, CMS-Plattformen, Plugins und Application-Server. Entfernen Sie Komponenten, die Sie nicht verwenden, und beschränken Sie Upload- und Admin-Pfade.
5. Patchen Sie den Kernel gegen CVE-2026-43284 ("Dirty Frag") mit dem Kernel-Update Ihrer Distribution und starten Sie in den neuen Kernel neu.
6. Beschränken Sie den ausgehenden Datenverkehr. Blockieren Sie nach Möglichkeit ausgehende Verbindungen standardmäßig und erlauben Sie nur die Ziele, die ein Server tatsächlich benötigt. GSocket-Verkehr ist ausschließlich ausgehend, daher erfassen eingehende Firewall-Regeln ihn nicht.
7. Härten Sie temporäre Verzeichnisse. Wo es praktikabel ist, binden Sie /tmp und /dev/shm mit noexec ein.
8. Überprüfen Sie anschließend, ob der Server keine Verbindung mehr zum GSocket-Relay oder zu den unten genannten Domains aufbaut.

So prüfen Sie, ob Sie betroffen sind

Führen Sie diese Prüfungen als root aus. Ein Treffer ist für sich genommen kein Beweis, sollte aber untersucht werden.

Von Microsoft genannte Dateien und Pfade:

ls -la /dev/shm/.gs-* /tmp/.gsn_ora /tmp/systemd-remount-d /usr/bin/systemd-remount-d /usr/bin/defunct 2>/dev/null
find / -xdev \( -name 'gs-netcat*' -o -name 'defunct.service' -o -name 'defunct' -o -name 'systemd-remount-d' \) 2>/dev/null

Laufende Prozesse:

ps -eo pid,ppid,user,args | grep -Ei 'gs-netcat|gsocket|defunct|remount-d' | grep -v grep

Echte Kernel-Threads haben keine ausführbare Datei. Wenn ein Prozess mit einem eckig geklammerten Namen wie [kaluad] auf eine Datei verweist, ist das verdächtig:

for p in /proc/[0-9]*; do n=$(cat $p/cmdline 2>/dev/null | tr '\0' ' '); case "$n" in \[*) e=$(readlink $p/exe 2>/dev/null); [ -n "$e" ] && echo "${p#/proc/} $n -> $e";; esac; done

Persistenz:

for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"; done
ls -la /etc/cron.* /var/spool/cron* 2>/dev/null
systemctl list-unit-files --type=service | grep -Ei 'defunct|remount'
grep -sEl 'gs-netcat|gsocket|defunct|GS_' /etc/profile /etc/profile.d/* /etc/bash.bashrc /root/.bashrc /root/.profile /home/*/.bashrc /home/*/.profile

Prüfen Sie systemd-Units sorgfältig, deren Namen plausibel klingen, die Sie aber nicht angelegt haben. Kontrollieren Sie die Home-Verzeichnisse von Konten für Webdienste wie www-data, apache und nobody sowie von cPanel-Benutzern.

Bekannte Datei-Hashes (SHA-256) von Microsoft:

• d94f75a70b5cabaf786ac57177ed841732e62bdcc9a29e06e5b41d9be567bcfa
• f95c4d029e6784e3849b4d1e2e2ae1a661187236ef7c5d487c71158a290a03b5
• 55d141bb2f62c527c3fea3413b8429fed7d52633d0b123b5e611bfa42165229f
• 12450bafc7a4398040e1ad3a16dbf4dbc79b6a8f83ef306c4f0f73f59886f06c

Netzwerk und Protokolle: Durchsuchen Sie DNS-, Proxy- und Firewall-Protokolle nach gsocket.io, cdn.gsocket.io und gsgg.b-cdn.net. Diese Domains dienen dem Herunterladen des Werkzeugs. Durchsuchen Sie außerdem Shell-Verlauf und Webserver-Protokolle nach Befehlen, die mit curl gsocket.io/y oder gsocket.io/install.sh abrufen. Achten Sie auf Shells, die vom Webserver oder von PHP-Prozessen gestartet wurden. Mit ss -tnp sehen Sie, welche Prozesse ausgehende Verbindungen halten, und Sie sollten alle untersuchen, die Sie nicht erklären können. Denken Sie daran, dass die Angreifer Staging-Dateien und Befehlsverläufe löschen. Fehlende Spuren an einer Stelle beweisen daher nicht, dass der Server sauber ist.

Quellen

• https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• https://www.bleepingcomputer.com/news/security/hackers-plant-gsocket-on-linux-servers-for-persistent-access/