GSocket-backdoor op Linux-webservers: controleer PHP-, cPanel- en Apache-hosts op compromittering

Wat er is gebeurd

Op 11 november 2026 publiceerde Microsoft onderzoek naar verschillende afzonderlijke groepen aanvallers die GSocket installeren op gecompromitteerde Linux-servers. BleepingComputer berichtte hier op 12 november 2026 over. GSocket is een legitiem, open-source hulpmiddel voor toegang op afstand. Zodra het op een server draait, maken zowel de server als de aanvaller uitgaande verbindingen met een openbare relaydienst, het Global Socket Relay Network. De relay verbindt beide zijden vervolgens in een versleutelde sessie. De server heeft geen open poort en geen publiek IP-adres nodig. De aanvallers beheren geen eigen infrastructuur, dus er is geen IP-adres of domein van de aanvaller om te blokkeren.

Dit is geen kwetsbaarheid in GSocket. De aanvallers breken eerst in via een van buitenaf bereikbare webapplicatie en installeren daarna GSocket om hun toegang te behouden. Omdat GSocket los van de applicatie draait, verwijdert het patchen van de applicatie GSocket niet. Microsoft meldt dat detecties die met GSocket te maken hebben in de telemetriegegevens tussen maart en augustus 2026 met 356,2% zijn gestegen.

Microsoft beschrijft de aanvallen als volgt:

• De aanvallers misbruiken een webapplicatie en gebruiken curl om een installatiescript te downloaden en uit te voeren.
• Het script plaatst de GSocket-client in beschrijfbare of in geheugen gebaseerde paden zoals /dev/shm.
• Het proces is vermomd onder namen die op kernelthreads lijken, bijvoorbeeld [kaluad], of onder systeemachtige namen zoals systemd-remount-d en /usr/bin/defunct.
• Persistentie wordt ingesteld via cronjobs, systemd-services, shell-startbestanden, watchdogs en extra kopieën. Tijdelijke bestanden worden daarna verwijderd en bestandstijdstempels worden teruggezet.
• In enkele gevallen probeerden de aanvallers root-rechten te verkrijgen via de Linux-kernelkwetsbaarheid CVE-2026-43284, bekend als "Dirty Frag".

Wie is getroffen

Linux-servers die van buitenaf bereikbare webapplicaties draaien die op een bepaald moment zijn gecompromitteerd. In de gegevens van Microsoft betrof 87,1% van de incidenten webapplicaties en hosting. Binnen die groep vormden PHP-webapplicaties en cPanel-hosting 63,9% en Apache 24,3%. Microsoft vermeldt ook meldingen over shells die vanuit Java- en Node.js-webapplicaties zijn gestart. Servers waarop onlangs een fout in een webapplicatie is gevonden en gepatcht, verdienen extra aandacht, omdat de aanvallers mogelijk binnenkwamen vóór de patch.

Servers waarvan de webapplicaties nooit zijn gecompromitteerd, zijn niet getroffen. GSocket dat door uw eigen team bewust is geïnstalleerd, is op zichzelf geen teken van compromittering.

Wat u nu moet doen

1. Controleer elke van buitenaf bereikbare Linux-webserver aan de hand van de stappen in de volgende paragraaf. Begin met servers waarop de afgelopen maanden een fout in een webapplicatie, CMS, plug-in of hostingpaneel is gepatcht.
2. Als u GSocket aantreft, behandel de server dan als gecompromitteerd. Stop het proces. Verwijder daarna het binaire bestand, alle kopieën en alle automatische startitems: cron, systemd-units, shell-startbestanden en watchdog-scripts. Microsoft merkt op dat de persistentie vaak in lagen is opgebouwd, dus het stoppen van het proces alleen verwijdert de toegang niet. Als de aanvallers mogelijk root-rechten hebben verkregen, bijvoorbeeld via CVE-2026-43284, is de veiligste keuze de server opnieuw op te bouwen vanaf een schone image of een back-up die vóór de compromittering is gemaakt.
3. Wijzig de inloggegevens op een getroffen server: databasewachtwoorden, applicatiegeheimen, API-sleutels en SSH-sleutels. Controleer ook authorized_keys op onbekende vermeldingen.
4. Zoek de toegangsweg en sluit deze. Werk webapplicaties, CMS-platforms, plug-ins en applicatieservers bij. Verwijder componenten die u niet gebruikt en beperk de upload- en beheerpaden.
5. Patch de kernel tegen CVE-2026-43284 ("Dirty Frag") met de kernelupdate van uw distributie, en start opnieuw op in de nieuwe kernel.
6. Beperk uitgaand verkeer. Blokkeer waar mogelijk uitgaande verbindingen standaard en sta alleen de bestemmingen toe die een server nodig heeft. GSocket-verkeer is alleen uitgaand, dus inkomende firewallregels vangen het niet op.
7. Versterk tijdelijke mappen. Waar praktisch mogelijk, koppelt u /tmp en /dev/shm met noexec.
8. Controleer achteraf of de server geen verbinding meer maakt met de GSocket-relay of met de hieronder genoemde domeinen.

Zo controleert u of u getroffen bent

Voer deze controles uit als root. Een treffer is op zichzelf geen bewijs, maar moet wel worden onderzocht.

Bestanden en paden die Microsoft noemt:

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

Actieve processen:

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

echte kernelthreads hebben geen uitvoerbaar bestand. Als een proces met een tussen haakjes geplaatste naam zoals [kaluad] naar een bestand verwijst, is dat verdacht:

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

Persistentie:

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

Bekijk systemd-units met namen die plausibel lijken maar die u niet zelf hebt aangemaakt, zorgvuldig. Controleer ook de thuismappen van webservice-accounts zoals www-data, apache en nobody, en van cPanel-gebruikers.

Bekende bestands-hashes (SHA-256) van Microsoft:

• d94f75a70b5cabaf786ac57177ed841732e62bdcc9a29e06e5b41d9be567bcfa
• f95c4d029e6784e3849b4d1e2e2ae1a661187236ef7c5d487c71158a290a03b5
• 55d141bb2f62c527c3fea3413b8429fed7d52633d0b123b5e611bfa42165229f
• 12450bafc7a4398040e1ad3a16dbf4dbc79b6a8f83ef306c4f0f73f59886f06c

Netwerk en logbestanden: Doorzoek DNS-, proxy- en firewalllogboeken op gsocket.io, cdn.gsocket.io en gsgg.b-cdn.net. Deze domeinen worden gebruikt om de tool te downloaden. Zoek ook in de shellgeschiedenis en in de logbestanden van de webserver naar opdrachten die gsocket.io/y of gsocket.io/install.sh met curl ophalen. Let op shells die door de webserver of PHP-processen zijn gestart. Gebruik ss -tnp om te zien welke processen uitgaande verbindingen hebben, en onderzoek processen die u niet kunt verklaren. Houd er rekening mee dat aanvallers tijdelijke bestanden en opdrachtgeschiedenis verwijderen, dus ontbrekende sporen op één plek bewijzen niet dat de server schoon is.

Bronnen

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