Vdor GSocket na spletnih strežnikih Linux: preverite gostitelje s PHP, cPanel in Apache za kompromitacijo

Kaj se je zgodilo

Dne 11. novembra 2026 je Microsoft objavil raziskavo o več ločenih skupinah napadalcev, ki na okuženih strežnikih Linux nameščajo GSocket. BleepingComputer je o tem poročal 12. novembra 2026. GSocket je zakonito odprtokodno orodje za oddaljeni dostop. Ko se zažene na strežniku, se tako strežnik kot napadalec povežeta z javno posredniško storitvijo, Global Socket Relay Network. Posrednik ju nato poveže v šifrirano sejo. Strežnik ne potrebuje odprtih vrat in javnega IP naslova. Napadalci nimajo lastne infrastrukture, zato ni IP naslova ali domene napadalca, ki bi jo lahko blokirali.

To ni ranljivost v GSocket. Napadalci najprej vdrejo v spletno aplikacijo, dostopno z interneta, nato pa namestijo GSocket, da ohranijo dostop. Ker GSocket deluje ločeno od aplikacije, popravek aplikacije ga ne odstrani. Microsoft navaja, da so se zaznave, povezane z GSocket, v njihovi telemetriji med marcem in avgustom 2026 povečale za 356,2 %.

Microsoft napade opisuje takole:

• Napadalci izkoristijo spletno aplikacijo in z ukazom curl prenesejo ter zaženejo namestitveno skripto.
• Skripta postavi odjemalca GSocket na mesta, ki so zapisljiva ali delujejo v pomnilniku, na primer /dev/shm.
• Proces je prikrit pod imeni, ki so videti kot jedrne niti, na primer [kaluad], ali pod sistemskimi imeni, kot sta systemd-remount-d in /usr/bin/defunct.
• Trajnost zagotovijo prek cron opravil, storitev systemd, datotek za zagon lupine, nadzornih skript in dodatnih kopij. Pomožne datoteke nato izbrišejo, časovne oznake datotek pa ponastavijo nazaj.
• V nekaterih primerih so napadalci poskusili pridobiti skrbniške pravice prek ranljivosti jedra Linux CVE-2026-43284, znane kot "Dirty Frag".

Kdo je prizadet

Strežniki Linux, ki gostijo spletne aplikacije, dostopne z interneta, in so bili nekoč vdrti. Po podatkih Microsofta je 87,1 % incidentov zadevalo spletne aplikacije in gostovanje. Znotraj te skupine so PHP spletne aplikacije in gostovanje cPanel predstavljale 63,9 %, Apache pa 24,3 %. Microsoft navaja tudi opozorila za lupine, zagnane iz spletnih aplikacij v Javi in Node.js. Strežniki, na katerih je bila nedavno odkrita in popravljena napaka v spletni aplikaciji, si zaslužijo posebno pozornost, saj so napadalci lahko vstopili pred popravkom.

Strežniki, na katerih spletne aplikacije nikoli niso bile vdrte, niso prizadeti. GSocket, ki ga je vaša ekipa namestila namerno, sam po sebi ni znak vdora.

Kaj storiti zdaj

1. Preverite vsak spletni strežnik Linux, dostopen z interneta, po korakih v naslednjem razdelku. Začnite s strežniki, na katerih so bile v zadnjih mesecih popravljene napake v spletni aplikaciji, CMS, vtičniku ali nadzorni plošči za gostovanje.
2. Če najdete GSocket, obravnavajte strežnik kot vdrt. Ustavite proces. Nato odstranite program, vse kopije in vse samodejne zagone: cron, enote systemd, datoteke za zagon lupine in nadzorne skripte. Microsoft opozarja, da je trajnost pogosto plastovita, zato sam postopek ustavitve ne odstrani dostopa. Če so napadalci morda pridobili skrbniške pravice, na primer prek CVE-2026-43284, je najvarnejša izbira ponovna namestitev strežnika iz čiste slike ali iz varnostne kopije, narejene pred vdorom.
3. Zamenjajte poverilnice na prizadetem strežniku: gesla podatkovnih baz, skrivnosti aplikacij, API ključe in ključe SSH. Preverite tudi authorized_keys za neznane vnose.
4. Poiščite in zaprite vstopno pot. Posodobite spletne aplikacije, CMS platforme, vtičnike in aplikacijske strežnike. Odstranite komponente, ki jih ne uporabljate, in omejite poti za nalaganje datotek ter skrbniške poti.
5. Popravite jedro proti CVE-2026-43284 ("Dirty Frag") s posodobitvijo jedra vaše distribucije in ponovnim zagonom v novo jedro.
6. Omejite odhodni promet. Kjer je mogoče, privzeto blokirajte odhodne povezave in dovolite le cilje, ki jih strežnik potrebuje. Promet GSocket je samo odhodni, zato ga pravila požarnega zidu za dohodni promet ne zaznajo.
7. Utrdite začasne imenike. Kjer je to praktično, pripnite /tmp in /dev/shm z možnostjo noexec.
8. Naknadno preverite, da se strežnik ne povezuje več s posrednikom GSocket ali z domenami, navedenimi spodaj.

Kako preveriti, ali ste prizadeti

Te preglede izvedite kot root. Zadetek sam po sebi ni dokaz, vendar ga je treba preiskati.

Datoteke in poti, ki jih navaja 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

Delujoči procesi:

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

Prave jedrne niti nimajo izvedljive datoteke. Če proces z imenom v oglatih oklepajih, kot je [kaluad], kaže na datoteko, je sumljiv:

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

Trajnost:

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

Pozorno preglejte enote systemd, katerih imena so videti verjetna, vi pa jih niste ustvarili. Preverite domače mape računov spletnih storitev, kot so www-data, apache in nobody, ter uporabnikov cPanel.

Znane zgoščene vrednosti datotek (SHA-256) po podatkih Microsofta:

• d94f75a70b5cabaf786ac57177ed841732e62bdcc9a29e06e5b41d9be567bcfa
• f95c4d029e6784e3849b4d1e2e2ae1a661187236ef7c5d487c71158a290a03b5
• 55d141bb2f62c527c3fea3413b8429fed7d52633d0b123b5e611bfa42165229f
• 12450bafc7a4398040e1ad3a16dbf4dbc79b6a8f83ef306c4f0f73f59886f06c

Omrežje in dnevniki: V dnevnikih DNS, posredniškega strežnika in požarnega zidu poiščite gsocket.io, cdn.gsocket.io in gsgg.b-cdn.net. Te domene se uporabljajo za prenos orodja. Prav tako v zgodovini lupine in dnevnikih spletnega strežnika poiščite ukaze, ki z curl prenašajo gsocket.io/y ali gsocket.io/install.sh. Iščite lupine, ki jih zaženejo spletni strežnik ali procesi PHP. Z ukazom ss -tnp preverite, kateri procesi imajo odhodne povezave, in preiščite tiste, ki jih ne znate pojasniti. Upoštevajte, da napadalci brišejo pomožne datoteke in zgodovino ukazov, zato odsotnost sledi na enem mestu še ne dokazuje, da je strežnik čist.

Viri

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