GSocket-bagdør på Linux-webservere: tjek PHP-, cPanel- og Apache-servere for kompromittering

Hvad er sket

Den 11. november 2026 offentliggjorde Microsoft forskning om flere separate grupper af angribere, der installerer GSocket på kompromitterede Linux-servere. BleepingComputer skrev om det den 12. november 2026. GSocket er et legitimt open source-værktøj til fjernadgang. Når det kører på en server, opretter både serveren og angriberen udgående forbindelser til en offentlig relætjeneste, Global Socket Relay Network. Relæet forbinder de to i en krypteret session. Serveren har ikke brug for en åben port eller en offentlig IP-adresse. Angriberne driver ingen egen infrastruktur, så der er ingen angriber-IP-adresse eller ét domæne at blokere.

Dette er ikke en sårbarhed i GSocket. Angriberne bryder først ind i en internetvendt webapplikation og installerer derefter GSocket for at beholde adgangen. Fordi GSocket kører adskilt fra applikationen, fjerner rettelse af applikationen det ikke. Microsoft oplyser, at GSocket-relaterede detektioner i deres telemetri steg med 356,2 % mellem marts og august 2026.

Microsoft beskriver angrebene således:

• Angriberne udnytter en webapplikation og bruger curl til at downloade og køre et installationsscript.
• Scriptet placerer GSocket-klienten i skrivbare eller hukommelsesbaserede stier som /dev/shm.
• Processen er skjult under navne, der ligner kernel-tråde, for eksempel [kaluad], eller under systemlignende navne som systemd-remount-d og /usr/bin/defunct.
• Persistens sættes op via cron-jobs, systemd-tjenester, shell-opstartsfiler, watchdogs og ekstra kopier. Midlertidige filer slettes derefter, og filernes tidsstempler tilbagedateres.
• I nogle tilfælde forsøgte angriberne at opnå root-adgang via Linux-kernefejlen CVE-2026-43284, kendt som "Dirty Frag".

Hvem er berørt

Linux-servere, der kører internetvendte webapplikationer, som på et tidspunkt er blevet kompromitteret. I Microsofts data involverede 87,1 % af hændelserne webapplikationer og hosting. Inden for denne gruppe udgjorde PHP-webapplikationer og cPanel-hosting 63,9 % og Apache 24,3 %. Microsoft nævner også alarmer for shells, der er startet fra Java- og Node.js-webapplikationer. Servere, hvor en fejl i en webapplikation er fundet og rettet for nylig, er særligt værd at tjekke, fordi angriberne kan være kommet ind før rettelsen.

Servere, hvis webapplikationer aldrig er blevet kompromitteret, er ikke berørt. GSocket, som dit eget team har installeret med vilje, er i sig selv ikke et tegn på kompromittering.

Hvad du skal gøre nu

1. Tjek hver internetvendt Linux-webserver ved hjælp af trinene i næste afsnit. Start med servere, hvor en fejl i en webapplikation, et CMS, et plugin eller et hosting-panel er rettet i de seneste måneder.
2. Hvis du finder GSocket, skal du behandle serveren som kompromitteret. Stop processen. Fjern derefter binærfilen, alle kopier og alle autostart-poster: cron, systemd-units, shell-opstartsfiler og watchdog-scripts. Microsoft oplyser, at persistensen ofte er lagdelt, så det alene at dræbe processen fjerner ikke adgangen. Hvis angriberne muligvis har fået root-adgang, for eksempel via CVE-2026-43284, er det sikreste valg at genopbygge serveren fra et rent image eller en backup, der er taget før kompromitteringen.
3. Skift adgangsoplysningerne på en berørt server: databaseadgangskoder, applikationshemmeligheder, API-nøgler og SSH-nøgler. Tjek også authorized_keys for ukendte poster.
4. Find og luk indgangen. Opdatér webapplikationer, CMS-platforme, plugins og applikationsservere. Fjern komponenter, du ikke bruger, og begræns upload-funktioner og admin-stier.
5. Patch kernen mod CVE-2026-43284 ("Dirty Frag") med din distributions kerneopdatering, og genstart i den nye kerne.
6. Begræns udgående trafik. Hvor du kan, bør du blokere udgående forbindelser som standard og kun tillade de destinationer, en server har brug for. GSocket-trafik er kun udgående, så regler for indgående trafik i firewallen fanger den ikke.
7. Hærd midlertidige mapper. Hvor det er praktisk, skal du montere /tmp og /dev/shm med noexec.
8. Verificér bagefter, at serveren ikke længere forbinder til GSocket-relæet eller til domænerne nævnt nedenfor.

Sådan tjekker du, om du er berørt

Kør disse tjek som root. Et fund er ikke i sig selv bevis, men det bør undersøges.

Filer og stier, Microsoft har nævnt:

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ørende processer:

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

Rigtige kernel-tråde har ingen eksekverbar fil. Hvis en proces med et firkantet parentesnavn såsom [kaluad] peger på en fil, er den mistænkelig:

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

Kig nøje på systemd-units, hvis navne ser troværdige ud, men som du ikke selv har oprettet. Tjek hjemmemapperne for webtjeneste-konti såsom www-data, apache og nobody samt for cPanel-brugere.

Kendte filhashes (SHA-256) fra Microsoft:

• d94f75a70b5cabaf786ac57177ed841732e62bdcc9a29e06e5b41d9be567bcfa
• f95c4d029e6784e3849b4d1e2e2ae1a661187236ef7c5d487c71158a290a03b5
• 55d141bb2f62c527c3fea3413b8429fed7d52633d0b123b5e611bfa42165229f
• 12450bafc7a4398040e1ad3a16dbf4dbc79b6a8f83ef306c4f0f73f59886f06c

Netværk og logs: Søg i DNS-, proxy- og firewall-logs efter gsocket.io, cdn.gsocket.io og gsgg.b-cdn.net. Disse domæner bruges til at downloade værktøjet. Søg også i shell-historik og webserver-logs efter kommandoer, der henter gsocket.io/y eller gsocket.io/install.sh med curl. Kig efter shells, der er startet af webserveren eller PHP-processer. Brug ss -tnp til at se, hvilke processer der har udgående forbindelser, og undersøg dem, du ikke kan forklare. Husk, at angriberne sletter midlertidige filer og kommandohistorik, så manglende spor ét sted beviser ikke, at serveren er ren.

Kilder

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