Backdoor GSocket sui server web Linux: verifichi server con PHP, cPanel e Apache per eventuali compromissioni

Cosa è successo

L'11 novembre 2026 Microsoft ha pubblicato una ricerca su diversi gruppi distinti di aggressori che installano GSocket su server Linux compromessi. BleepingComputer ne ha riferito il 12 novembre 2026. GSocket è uno strumento legittimo di accesso remoto open source. Una volta in esecuzione su un server, sia il server sia l'aggressore effettuano connessioni in uscita verso un servizio di relay pubblico, la Global Socket Relay Network. Il relay collega i due in una sessione cifrata. Il server non richiede alcuna porta aperta né un indirizzo IP pubblico. Gli aggressori non gestiscono un'infrastruttura propria, quindi non esiste un indirizzo IP o un dominio dell'aggressore da bloccare.

Non si tratta di una vulnerabilità di GSocket. Gli aggressori violano prima un'applicazione web esposta su internet, quindi installano GSocket per mantenere l'accesso. Poiché GSocket viene eseguito separatamente dall'applicazione, applicare la patch all'applicazione non lo rimuove. Microsoft afferma che le rilevazioni legate a GSocket nella sua telemetria sono aumentate del 356,2% tra marzo e agosto 2026.

Microsoft descrive gli attacchi nel modo seguente:

• Gli aggressori sfruttano un'applicazione web e usano curl per scaricare ed eseguire uno script di installazione.
• Lo script colloca il client GSocket in percorsi scrivibili o basati sulla memoria, come /dev/shm.
• Il processo viene mascherato con nomi che sembrano thread del kernel, ad esempio [kaluad], oppure con nomi di sistema come systemd-remount-d e /usr/bin/defunct.
• La persistenza viene configurata tramite cron job, servizi systemd, file di avvio della shell, watchdog e copie aggiuntive. I file temporanei vengono poi eliminati e le date dei file retrodatate.
• In alcuni casi gli aggressori hanno tentato di ottenere i privilegi di root sfruttando la falla del kernel Linux CVE-2026-43284, nota come "Dirty Frag".

Chi è interessato

Sono interessati i server Linux che eseguono applicazioni web esposte su internet e che sono stati compromessi in un qualsiasi momento. Secondo i dati di Microsoft, l'87,1% degli incidenti riguardava applicazioni web e servizi di hosting. All'interno di questo gruppo, le applicazioni web PHP e l'hosting cPanel rappresentavano il 63,9%, mentre Apache il 24,3%. Microsoft segnala inoltre avvisi per shell avviate da applicazioni web Java e Node.js. Vale la pena verificare con particolare attenzione i server su cui è stata trovata e corretta di recente una falla di un'applicazione web, perché gli aggressori potrebbero essere entrati prima della correzione.

I server le cui applicazioni web non sono mai state compromesse non sono interessati. La presenza di GSocket installato intenzionalmente dal proprio team non è di per sé un segnale di compromissione.

Cosa fare ora

1. Verifichi ogni server Linux web esposto su internet seguendo i passaggi della sezione successiva. Inizi dai server su cui, nei mesi recenti, è stata corretta una falla di un'applicazione web, di un CMS, di un plugin o di un pannello di hosting.
2. Se trova GSocket, consideri il server compromesso. Interrompa il processo. Rimuova quindi il file eseguibile, ogni copia e ogni voce di avvio automatico: cron, unità systemd, file di avvio della shell e script watchdog. Microsoft segnala che la persistenza è spesso stratificata, quindi terminare solo il processo non elimina l'accesso. Se gli aggressori possono aver ottenuto i privilegi di root, ad esempio tramite CVE-2026-43284, la scelta più sicura è ricostruire il server da un'immagine pulita o da un backup effettuato prima della compromissione.
3. Modifichi le credenziali su un server interessato: password dei database, segreti delle applicazioni, chiavi API e chiavi SSH. Controlli inoltre authorized_keys alla ricerca di voci sconosciute.
4. Individui e chiuda la via d'accesso. Aggiorni applicazioni web, piattaforme CMS, plugin e application server. Rimuova i componenti che non utilizza e limiti i percorsi di caricamento file e di amministrazione.
5. Applichi la patch al kernel contro CVE-2026-43284 ("Dirty Frag") con l'aggiornamento del kernel della sua distribuzione, e riavvii nel nuovo kernel.
6. Limiti il traffico in uscita. Dove possibile, blocchi le connessioni in uscita per impostazione predefinita e consenta solo le destinazioni di cui il server ha bisogno. Il traffico GSocket è solo in uscita, quindi le regole del firewall in entrata non lo intercettano.
7. Irrobustisca le directory temporanee. Dove è praticabile, monti /tmp e /dev/shm con noexec.
8. Verifichi successivamente che il server non si connetta più al relay GSocket o ai domini elencati di seguito.

Come verificare se è interessato

Esegua questi controlli come root. Un riscontro non è di per sé una prova, ma va approfondito.

File e percorsi indicati da 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

Processi in esecuzione:

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

I veri thread del kernel non hanno un file eseguibile. Se un processo con un nome tra parentesi quadre, come [kaluad], punta a un file, è sospetto:

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

Persistenza:

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

Esamini con attenzione le unità systemd dal nome plausibile che però non ha creato lei. Controlli le directory home degli account di servizi web come www-data, apache e nobody, e quelle degli utenti cPanel.

Hash noti dei file (SHA-256) forniti da Microsoft:

• d94f75a70b5cabaf786ac57177ed841732e62bdcc9a29e06e5b41d9be567bcfa
• f95c4d029e6784e3849b4d1e2e2ae1a661187236ef7c5d487c71158a290a03b5
• 55d141bb2f62c527c3fea3413b8429fed7d52633d0b123b5e611bfa42165229f
• 12450bafc7a4398040e1ad3a16dbf4dbc79b6a8f83ef306c4f0f73f59886f06c

Rete e log: Cerchi nei log DNS, proxy e firewall i domini gsocket.io, cdn.gsocket.io e gsgg.b-cdn.net. Questi domini vengono usati per scaricare lo strumento. Cerchi inoltre nella cronologia della shell e nei log del server web i comandi che recuperano gsocket.io/y o gsocket.io/install.sh con curl. Controlli le shell avviate dal server web o dai processi PHP. Usi ss -tnp per verificare quali processi mantengono connessioni in uscita e approfondisca quelli che non riesce a giustificare. Tenga presente che gli aggressori eliminano i file temporanei e la cronologia dei comandi, quindi l'assenza di tracce in un punto non dimostra che il server sia pulito.

Fonti

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