GSocket-bakdörr på Linux-webbservrar: kontrollera PHP-, cPanel- och Apache-värdar för intrång

Vad hände

Den 11 november 2026 publicerade Microsoft research om flera separata angripargrupper som installerar GSocket på komprometterade Linux-servrar. BleepingComputer rapporterade om det den 12 november 2026. GSocket är ett legitimt open source-verktyg för fjärråtkomst. När det körs på en server gör både servern och angriparen utgående anslutningar till en publik reläetjänst, Global Socket Relay Network. Reläet kopplar sedan ihop de två till en krypterad session. Servern behöver varken en öppen port eller en publik IP-adress. Angriparna driver ingen egen infrastruktur, så det finns ingen angriparens IP-adress eller domän att blockera.

Detta är ingen sårbarhet i GSocket. Angriparna bryter först in i en internetvänd webbapplikation och installerar sedan GSocket för att behålla åtkomsten. Eftersom GSocket körs separat från applikationen tar patchning av applikationen inte bort det. Microsoft uppger att GSocket-relaterade detektioner i deras telemetri ökade med 356,2 % mellan mars och augusti 2026.

Microsoft beskriver attackerna så här:

• Angriparna utnyttjar en webbapplikation och använder curl för att ladda ner och köra ett installationsskript.
• Skriptet placerar GSocket-klienten i skrivbara eller minnesbaserade sökvägar, till exempel /dev/shm.
• Processen döljs under namn som liknar kärntrådar, till exempel [kaluad], eller under systemlika namn som systemd-remount-d och /usr/bin/defunct.
• Persistens sätts upp via cron-jobb, systemd-tjänster, shell-startfiler, watchdogs och extra kopior. Temporära filer raderas sedan och filtidsstämplar bakdateras.
• I några fall försökte angriparna få root via Linux-kärnsårbarheten CVE-2026-43284, känd som "Dirty Frag".

Vem drabbas

Linux-servrar som kör internetvända webbapplikationer som vid något tillfälle komprometterades. I Microsofts data involverade 87,1 % av incidenterna webbapplikationer och webbhotell. Inom den gruppen stod PHP-webbapplikationer och cPanel-hosting för 63,9 % och Apache för 24,3 %. Microsoft listar också varningar för skal som startats från Java- och Node.js-webbapplikationer. Servrar där en sårbarhet i en webbapplikation hittades och patchades nyligen är särskilt värda att kontrollera, eftersom angriparna kan ha tagit sig in före patchen.

Servrar vars webbapplikationer aldrig komprometterades påverkas inte. GSocket som ditt eget team medvetet installerat är i sig inte ett tecken på intrång.

Gör detta nu

1. Kontrollera varje internetvänd Linux-webbserver med stegen i nästa avsnitt. Börja med servrar där en sårbarhet i en webbapplikation, ett CMS, ett plugin eller ett hostingpanel patchades under de senaste månaderna.
2. Om du hittar GSocket, behandla servern som komprometterad. Stoppa processen. Ta sedan bort binären, alla kopior och alla autostartposter: cron, systemd-enheter, shell-startfiler och watchdog-skript. Microsoft noterar att persistensen ofta är lagrad på flera nivåer, så att döda processen ensam inte tar bort åtkomsten. Om angriparna kan ha fått root, till exempel via CVE-2026-43284, är det säkraste att bygga om servern från en ren avbild eller en säkerhetskopia som togs före intrånget.
3. Byt uppgifter på en påverkad server: databaslösenord, applikationshemligheter, API-nycklar och SSH-nycklar. Kontrollera även authorized_keys efter okända poster.
4. Hitta och täpp till ingångsvägen. Uppdatera webbapplikationer, CMS-plattformar, plugins och applikationsservrar. Ta bort komponenter du inte använder och begränsa uppladdnings- och adminsökvägar.
5. Patcha kärnan mot CVE-2026-43284 ("Dirty Frag") med din distributions kärnuppdatering och starta om i den nya kärnan.
6. Begränsa utgående trafik. Där du kan, blockera utgående anslutningar som standard och tillåt endast de mål en server behöver. GSocket-trafik är enbart utgående, så regler för inkommande trafik i brandväggen fångar den inte.
7. Härda temporära kataloger. Där det är praktiskt, montera /tmp och /dev/shm med noexec.
8. Verifiera efteråt att servern inte längre ansluter till GSocket-reläet eller domänerna nedan.

Så kontrollerar du om du påverkas

Kör dessa kontroller som root. En träff är inte bevis i sig, men den bör undersökas.

Filer och sökvägar som Microsoft nämner:

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

Körande processer:

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

Riktiga kärntrådar har ingen körbar fil. Om en process med ett hakparentesnamn som [kaluad] pekar på en fil är den misstänkt:

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

Persistens:

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

Titta noga på systemd-enheter vars namn ser trovärdiga ut men som du inte skapade. Kontrollera hemkatalogerna för webbtjänstkonton som www-data, apache och nobody, samt för cPanel-användare.

Kända filhashar (SHA-256) från Microsoft:

• d94f75a70b5cabaf786ac57177ed841732e62bdcc9a29e06e5b41d9be567bcfa
• f95c4d029e6784e3849b4d1e2e2ae1a661187236ef7c5d487c71158a290a03b5
• 55d141bb2f62c527c3fea3413b8429fed7d52633d0b123b5e611bfa42165229f
• 12450bafc7a4398040e1ad3a16dbf4dbc79b6a8f83ef306c4f0f73f59886f06c

Nätverk och loggar: Sök i DNS-, proxy- och brandväggsloggar efter gsocket.io, cdn.gsocket.io och gsgg.b-cdn.net. Dessa domäner används för att ladda ner verktyget. Sök också i skalhistoriken och webbserverloggarna efter kommandon som hämtar gsocket.io/y eller gsocket.io/install.sh med curl. Leta efter skal som startats av webbservern eller PHP-processerna. Använd ss -tnp för att se vilka processer som har utgående anslutningar, och undersök de du inte kan förklara. Tänk på att angriparna raderar temporära filer och kommandohistorik, så saknade spår på ett ställe bevisar inte att servern är ren.

Källor

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