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

Hva skjedde

Den 11. november 2026 publiserte Microsoft forskning om flere separate angripergrupper som installerer GSocket på kompromitterte Linux-servere. BleepingComputer omtalte det den 12. november 2026. GSocket er et legitimt, åpen kildekode-verktøy for fjerntilgang. Når det kjører på en server, oppretter både serveren og angriperen utgående forbindelser til en offentlig relétjeneste, Global Socket Relay Network. Reléet kobler de to sammen i en kryptert økt. Serveren trenger ingen åpen port og ingen offentlig IP-adresse. Angriperne driver ingen egen infrastruktur, så det finnes ingen angriper-IP-adresse eller domene å blokkere.

Dette er ikke en sårbarhet i GSocket. Angriperne bryter først inn i en internettvendt webapplikasjon og installerer deretter GSocket for å beholde tilgangen. Fordi GSocket kjører separat fra applikasjonen, fjerner ikke oppdatering av applikasjonen den. Microsoft sier at GSocket-relaterte deteksjoner i telemetrien deres økte med 356,2 % mellom mars og august 2026.

Microsoft beskriver angrepene slik:

• Angriperne utnytter en webapplikasjon og bruker curl til å laste ned og kjøre et installasjonsskript.
• Skriptet plasserer GSocket-klienten i skrivbare eller minnebaserte stier, som /dev/shm.
• Prosessen skjules under navn som ser ut som kjerne-tråder, for eksempel [kaluad], eller under systemlignende navn som systemd-remount-d og /usr/bin/defunct.
• Vedvarende kjøring settes opp via cron-jobber, systemd-tjenester, shell-oppstartsfiler, watchdog-skript og ekstra kopier. Midlertidige filer slettes deretter, og filtidsstempler tilbakedateres.
• I noen tilfeller forsøkte angriperne å få root-tilgang via Linux-kjernesårbarheten CVE-2026-43284, kjent som "Dirty Frag".

Hvem er berørt

Linux-servere som kjører internettvendte webapplikasjoner som på et tidspunkt ble kompromittert. I Microsofts data gjaldt 87,1 % av hendelsene webapplikasjoner og hosting. Innenfor den gruppen utgjorde PHP-webapplikasjoner og cPanel-hosting 63,9 %, og Apache 24,3 %. Microsoft lister også varsler om shell-er startet fra Java- og Node.js-webapplikasjoner. Servere der en feil i en webapplikasjon ble funnet og rettet nylig, bør sjekkes spesielt, fordi angriperne kan ha kommet inn før rettelsen.

Servere der webapplikasjonene aldri ble kompromittert, er ikke berørt. GSocket som er installert med vilje av ditt eget team, er i seg selv ikke et tegn på kompromittering.

Hva du bør gjøre nå

1. Sjekk alle internettvendte Linux-webservere med stegene i neste avsnitt. Start med servere der en feil i en webapplikasjon, CMS, plugin eller hostingpanel ble rettet de siste månedene.
2. Hvis du finner GSocket, må du behandle serveren som kompromittert. Stopp prosessen. Fjern deretter binærfilen, alle kopier og alle oppstartsoppføringer: cron, systemd-enheter, shell-oppstartsfiler og watchdog-skript. Microsoft påpeker at vedvarende kjøring ofte er lagdelt, så det er ikke nok å drepe prosessen for å fjerne tilgangen. Hvis angriperne kan ha fått root-tilgang, for eksempel via CVE-2026-43284, er det tryggeste valget å installere serveren på nytt fra et rent image eller en sikkerhetskopi tatt før kompromitteringen.
3. Bytt passord og nøkler på en berørt server: databasepassord, applikasjonshemmeligheter, API-nøkler og SSH-nøkler. Sjekk også authorized_keys for ukjente oppføringer.
4. Finn og tett inngangsveien. Oppdater webapplikasjoner, CMS-plattformer, plugins og applikasjonsservere. Fjern komponenter du ikke bruker, og begrens filopplastings- og admin-stier.
5. Oppdater kjernen mot CVE-2026-43284 ("Dirty Frag") med distribusjonens kjerneoppdatering, og start på nytt i den nye kjernen.
6. Begrens utgående trafikk. Der du kan, bør du blokkere utgående forbindelser som standard og bare tillate de målene en server trenger. GSocket-trafikk er kun utgående, så innkommende brannmurregler fanger den ikke.
7. Herd midlertidige kataloger. Der det er praktisk, monter /tmp og /dev/shm med noexec.
8. Verifiser etterpå at serveren ikke lenger kobler seg til GSocket-reléet eller domenene nevnt nedenfor.

Slik sjekker du om du er berørt

Kjør disse kontrollene som root. Et treff er ikke bevis i seg selv, men det bør undersøkes.

Filer og stier nevnt av Microsoft:

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

Kjørende prosesser:

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

Ekte kjerne-tråder har ingen kjørbar fil. Hvis en prosess med klammeparentes-navn, som [kaluad], peker på en fil, er den mistenkelig:

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

Vedvarende kjøring:

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

Se nøye etter systemd-enheter med navn som virker plausible, men som du ikke opprettet. Sjekk hjemmekatalogene til webtjeneste-kontoer som www-data, apache og nobody, og til cPanel-brukere.

Kjente filhasher (SHA-256) fra Microsoft:

• d94f75a70b5cabaf786ac57177ed841732e62bdcc9a29e06e5b41d9be567bcfa
• f95c4d029e6784e3849b4d1e2e2ae1a661187236ef7c5d487c71158a290a03b5
• 55d141bb2f62c527c3fea3413b8429fed7d52633d0b123b5e611bfa42165229f
• 12450bafc7a4398040e1ad3a16dbf4dbc79b6a8f83ef306c4f0f73f59886f06c

Nettverk og logger: Søk i DNS-, proxy- og brannmurlogger etter gsocket.io, cdn.gsocket.io og gsgg.b-cdn.net. Disse domenene brukes til å laste ned verktøyet. Søk også i shell-historikk og webserverlogger etter kommandoer som henter gsocket.io/y eller gsocket.io/install.sh med curl. Se etter shell-er startet av webserveren eller PHP-prosesser. Bruk ss -tnp for å sjekke hvilke prosesser som har utgående forbindelser, og undersøk alle du ikke kan forklare. Husk at angriperne sletter midlertidige filer og kommandohistorikk, så manglende spor på ett 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/