Gli attaccanti usano GSocket, uno strumento legittimo di accesso remoto open source, per mantenere il controllo dei server Linux compromessi anche dopo che gli amministratori hanno applicato le patch alle vulnerabilità sfruttate per entrare. In un rapporto di Microsoft dell’11 novembre sono descritte diverse intrusioni in cui lo strumento è sopravvissuto alla correzione delle applicazioni. Per questo i difensori devono analizzare l’host e rimuovere la persistenza, oltre a correggere la falla originale.
L’attività colpisce in particolare le applicazioni web e gli ambienti di hosting. La telemetria di Microsoft Defender for Endpoint ha mostrato un aumento del 356,2% dei dispositivi con rilevamenti legati a GSocket tra marzo e agosto 2026, sebbene la crescita sia variata da un mese all’altro. Il dato misura i dispositivi con rilevamenti, non il numero di intrusioni riuscite confermate.
BleepingComputer ha riportato il 12 novembre, citando Microsoft, che l’87,1% degli incidenti rilevati riguardava applicazioni web e hosting. Le quote riportate sono del 63,9% per le applicazioni web PHP e l’hosting cPanel, e del 24,3% per Apache. Istruzione e ricerca sono stati i settori più colpiti, seguiti da tecnologia e comunicazioni, manifattura e pubblica amministrazione.
Come l’accesso sopravvive a una patch
Microsoft ha osservato che gli attaccanti sfruttavano applicazioni esposte su internet per eseguire comandi con l’account del servizio web, per poi installare GSocket. Poiché il client di relay funziona in modo indipendente dall’applicazione vulnerabile, applicare la patch a quest’ultima non rimuove il client né i meccanismi che lo riavviano.
GSocket instrada il traffico attraverso la Global Socket Relay Network, un servizio pubblico condiviso. Il server compromesso e l’attaccante avviano ciascuno una connessione in uscita verso un relay, che li collega tramite un canale cifrato end-to-end. Il server non ha bisogno né di un servizio in ascolto in ingresso né di un indirizzo IP pubblico. Il Network Address Translation (NAT), che permette ai sistemi di condividere un indirizzo esterno, non impedisce la connessione.
In questo modo gli attaccanti ottengono accesso remoto senza gestire un server di comando e controllo dedicato, cioè l’infrastruttura che normalmente serve a dirigere i sistemi compromessi. Possono riconnettersi senza conoscere l’indirizzo IP o l’hostname del server compromesso. Di conseguenza non esiste un indirizzo o un dominio di proprietà dell’attaccante da bloccare, anche se le organizzazioni possono limitare l’accesso alla rete di relay stessa.
Le regole firewall in ingresso non intercettano questo traffico in uscita. Il filtraggio e il monitoraggio del traffico in uscita sì.
Secondo Microsoft, diversi attori di minaccia non collegati tra loro hanno adottato GSocket. Il suo script di distribuzione può rinominare i processi, collocare file in directory basate sulla memoria e installare meccanismi pensati per sopravvivere a un riavvio. I ricercatori hanno osservato attaccanti che mascheravano i processi da thread del kernel Linux e che usavano job pianificati di cron, servizi systemd e file di avvio della shell per mantenere l’accesso. La persistenza dopo il riavvio e le sessioni di relay riuscite non sono state confermate in tutte le intrusioni analizzate.
In alcuni casi gli attaccanti hanno anche tentato di sfruttare la vulnerabilità del kernel Linux CVE-2026-43284, descritta da BleepingComputer come «Dirty Frag», per passare dall’account del servizio web a root, l’account con i privilegi più elevati di Linux. Microsoft le ha descritte come tentativi di sfruttamento.
Cosa possono cercare i difensori
Gli avvisi osservati da Microsoft riguardavano shell sospette avviate da server web e runtime delle applicazioni, esecuzione di GSocket, download di payload, job cron e servizi Linux di nuova creazione. Altri segnali includevano l’esecuzione di file nascosti, l’offuscamento, timestamp modificati, la cancellazione di binari in esecuzione, tentativi di cancellare la cronologia dei comandi, ricognizione del sistema e comportamenti di reverse shell. Un singolo avviso non stabilisce il percorso di accesso iniziale né dimostra che ogni fase dell’intrusione sia riuscita.
Ad esempio, Microsoft ha osservato un comando bash che richiamava il payload rinominato /usr/bin/defunct, insieme a riferimenti a defunct.service e a un collegamento multi-user.target.wants usato per abilitare un servizio systemd. Questo mostra perché gli amministratori devono verificare anche i nomi di servizio dall’aspetto plausibile, oltre ai nomi di file riconoscibili come appartenenti a GSocket.
Microsoft ha pubblicato query di hunting per Defender XDR relative ai sette giorni precedenti. Cercano nei nomi e nelle righe di comando dei processi gs-netcat, gsocket, gsnetcat e gsocket.io, quindi mostrano account, percorso e processo padre per l’analisi. Altre query verificano l’attività di download e le connessioni di rete che coinvolgono gsocket.io e gsgg.b-cdn.net.
Questi domini, insieme a cdn.gsocket.io, distribuiscono lo strumento legittimo; non sono infrastrutture di comando e controllo di proprietà degli attaccanti. Tra i target di recupero osservati figuravano hxxps://gsocket[.]io/y e hxxps://gsocket[.]io/install.sh, anche se per il secondo non è stato accertato un recupero riuscito.
Le ricerche sui file riguardano percorsi che iniziano con /dev/shm/.gs- e nomi come systemd-remount-d, .gsn_ora, defunct e defunct.service. Microsoft ha inoltre pubblicato queste specifiche osservazioni sui file e le relative impronte SHA-256:
/dev/shm/.gs-0/gs-netcat_mini-linux-x86_64:d94f75a70b5cabaf786ac57177ed841732e62bdcc9a29e06e5b41d9be567bcfa/dev/shm/.gs-0/gs-netcat_mini-linux-aarch64:f95c4d029e6784e3849b4d1e2e2ae1a661187236ef7c5d487c71158a290a03b5/tmp/systemd-remount-de/usr/bin/systemd-remount-d:55d141bb2f62c527c3fea3413b8429fed7d52633d0b123b5e611bfa42165229f/tmp/.gsn_ora:12450bafc7a4398040e1ad3a16dbf4dbc79b6a8f83ef306c4f0f73f59886f06c
I binari specifici per architettura risultavano associati a download da hxxps://gsgg[.]b-cdn[.]net/bin/gs-netcat_mini-linux-x86_64 e hxxps://cdn[.]gsocket[.]io/bin/gs-netcat_mini-linux-aarch64. Questi indicatori rappresentano osservazioni specifiche e non un inventario completo. Microsoft consiglia di analizzare le corrispondenze insieme alla discendenza dei processi, al contesto di esecuzione, alle modifiche di persistenza e all’attività di rete.
Rimuovere la presenza oltre alla falla
Gli amministratori che analizzano server Linux colpiti devono rimuovere il client GSocket non autorizzato, i file di staging e la relativa persistenza, poi verificare che le connessioni in uscita verso l’infrastruttura di relay siano cessate, raccomanda Microsoft. Fermare il solo processo in esecuzione potrebbe lasciare intatti altri meccanismi di riavvio.
L’azienda consiglia inoltre di controllare le voci di cron, le unità systemd e i file di avvio della shell, di applicare regole di uscita che negano tutto per impostazione predefinita e consentono solo le destinazioni necessarie, e di monitorare le connessioni di relay. Ove possibile, le directory temporanee e quelle basate sulla memoria dovrebbero essere montate come non eseguibili, con avvisi per le esecuzioni da percorsi nascosti o scrivibili da tutti.
Applicazioni esposte su internet, sistemi di gestione dei contenuti, plugin e application server devono essere mantenuti aggiornati. Microsoft consiglia di rimuovere i componenti inutilizzati e di limitare i percorsi di upload e di amministrazione. Gli amministratori dovrebbero inoltre dare priorità alle patch per l’escalation di privilegi locale, incluso CVE-2026-43284. Come contesto separato per questa raccomandazione, Microsoft ha citato il lavoro del FORGE Lab su 59 segnalazioni di bug del kernel Linux, tra cui otto vulnerabilità con exploit locali per ottenere root dimostrati in ambienti controllati.
Per le organizzazioni che usano Defender for Endpoint su Linux, Microsoft raccomanda di mantenere attive la protezione in tempo reale, la protezione basata sul cloud e il monitoraggio comportamentale, incluso il monitoraggio di processi figli insoliti generati dai servizi web e di identità di processo mascherate. Dopo la patch dell’applicazione occorre procedere con la pulizia dell’host e verificare che le connessioni di relay siano terminate.
