Backdoor GSocket pe serverele web Linux: verifică gazdele PHP, cPanel și Apache pentru compromitere

Ce s-a întâmplat

Pe 11 noiembrie 2026 Microsoft a publicat cercetări despre mai multe grupuri separate de atacatori care instalează GSocket pe servere Linux compromise. BleepingComputer a relatat despre acest lucru pe 12 noiembrie 2026. GSocket este un instrument legitim, open-source, de acces la distanță. Odată pornit pe un server, atât serverul, cât și atacatorul fac conexiuni de ieșire către un serviciu public de releu, Global Socket Relay Network. Releul unește cele două capete într-o sesiune criptată. Serverul nu are nevoie de port deschis și nici de adresă IP publică. Atacatorii nu folosesc o infrastructură proprie, deci nu există adresă IP sau domeniu de atacator pe care să-l blochezi.

Nu este o vulnerabilitate în GSocket. Atacatorii pătrund mai întâi într-o aplicație web expusă la internet, apoi instalează GSocket ca să-și păstreze accesul. Pentru că GSocket rulează separat de aplicație, aplicarea patch-ului pe aplicație nu îl elimină. Microsoft spune că detecțiile legate de GSocket din telemetria sa au crescut cu 356,2% între martie și august 2026.

Microsoft descrie atacurile astfel:

• Atacatorii exploatează o aplicație web și folosesc curl pentru a descărca și rula un script de instalare.
• Scriptul plasează clientul GSocket în locații scriptabile sau în memorie, precum /dev/shm.
• Procesul este camuflat sub nume care par thread-uri de kernel, de exemplu [kaluad], sau sub nume de sistem precum systemd-remount-d și /usr/bin/defunct.
• Persistența se realizează prin joburi cron, servicii systemd, fișiere de pornire ale shell-ului, watchdog-uri și copii suplimentare. Fișierele de lucru sunt apoi șterse, iar datele de modificare ale fișierelor sunt falsificate în trecut.
• În câteva cazuri, atacatorii au încercat să obțină root prin defectul de kernel Linux CVE-2026-43284, cunoscut drept „Dirty Frag”.

Cine este afectat

Serverele Linux care rulează aplicații web expuse la internet și care au fost compromise la un moment dat. În datele Microsoft, 87,1% dintre incidente au implicat aplicații web și hosting. În cadrul acestui grup, aplicațiile web PHP și hostingul cPanel au reprezentat 63,9%, iar Apache 24,3%. Microsoft mai listează alerte pentru shell-uri pornite din aplicații web Java și Node.js. Merită verificate în special serverele pe care s-a găsit și s-a corectat recent un defect al unei aplicații web, pentru că atacatorii ar fi putut intra înainte de patch.

Serverele ale căror aplicații web nu au fost niciodată compromise nu sunt afectate. GSocket instalat intenționat de echipa ta nu este, prin el însuși, un semn de compromitere.

Ce trebuie să faci acum

1. Verifică fiecare server Linux web expus la internet folosind pașii din secțiunea următoare. Începe cu serverele unde o aplicație web, un CMS, un plugin sau un panou de hosting a fost corectat în ultimele luni.
2. Dacă găsești GSocket, tratează serverul ca fiind compromis. Oprește procesul. Apoi elimină binarul, toate copiile și toate intrările de pornire automată: cron, unitățile systemd, fișierele de pornire ale shell-ului și scripturile watchdog. Microsoft notează că persistența este adesea stratificată, deci oprirea procesului nu elimină singură accesul. Dacă atacatorii ar fi putut obține root, de exemplu prin CVE-2026-43284, cea mai sigură alegere este reinstalarea serverului dintr-o imagine curată sau dintr-o copie de rezervă făcută înainte de compromitere.
3. Schimbă credențialele de pe serverul afectat: parolele bazei de date, secretele aplicațiilor, cheile API și cheile SSH. Verifică și authorized_keys pentru intrări necunoscute.
4. Găsește și închide calea de intrare. Actualizează aplicațiile web, platformele CMS, pluginurile și serverele de aplicații. Elimină componentele pe care nu le folosești și restricționează căile de upload de fișiere și de administrare.
5. Aplică patch-ul de kernel împotriva CVE-2026-43284 („Dirty Frag”) cu actualizarea de kernel a distribuției tale și repornește în noul kernel.
6. Restricționează traficul de ieșire. Unde poți, blochează implicit conexiunile de ieșire și permite doar destinațiile de care serverul are nevoie. Traficul GSocket este doar de ieșire, deci regulile de firewall pentru intrare nu îl prind.
7. Întărește directoarele temporare. Unde este practic, montează /tmp și /dev/shm cu noexec.
8. Verifică după aceea că serverul nu mai se conectează la releul GSocket sau la domeniile enumerate mai jos.

Cum verifici dacă ești afectat

Rulează aceste verificări ca root. Un rezultat pozitiv nu este dovadă în sine, dar trebuie investigat.

Fișiere și căi denumite de 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

Procese care rulează:

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

Thread-urile reale de kernel nu au fișier executabil. Dacă un proces cu un nume între paranteze drepte, precum [kaluad], indică spre un fișier, este suspect:

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

Persistență:

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

Verifică atent unitățile systemd care au nume plauzibile, dar pe care nu tu le-ai creat. Verifică directoarele home ale conturilor de servicii web, precum www-data, apache și nobody, și ale utilizatorilor cPanel.

Hash-uri cunoscute ale fișierelor (SHA-256) de la Microsoft:

• d94f75a70b5cabaf786ac57177ed841732e62bdcc9a29e06e5b41d9be567bcfa
• f95c4d029e6784e3849b4d1e2e2ae1a661187236ef7c5d487c71158a290a03b5
• 55d141bb2f62c527c3fea3413b8429fed7d52633d0b123b5e611bfa42165229f
• 12450bafc7a4398040e1ad3a16dbf4dbc79b6a8f83ef306c4f0f73f59886f06c

Rețea și jurnale: Caută în jurnalele DNS, proxy și firewall domeniile gsocket.io, cdn.gsocket.io și gsgg.b-cdn.net. Aceste domenii sunt folosite pentru descărcarea instrumentului. Caută și în istoricul shell-ului și în jurnalele serverului web comenzi care descarcă gsocket.io/y sau gsocket.io/install.sh cu curl. Caută shell-uri pornite de procesele serverului web sau PHP. Folosește ss -tnp ca să vezi ce procese au conexiuni de ieșire și investighează-le pe cele pe care nu le poți explica. Ține minte că atacatorii șterg fișierele de lucru și istoricul comenzilor, deci lipsa urmelor într-un loc nu dovedește că serverul este curat.

Surse

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