Porte dérobée GSocket sur serveurs web Linux : vérifier les PHP, cPanel et Apache

Ce qui s'est passé

Le 11 novembre 2026, Microsoft a publié une étude sur plusieurs groupes distincts d'attaquants qui installent GSocket sur des serveurs Linux compromis. BleepingComputer en a rendu compte le 12 novembre 2026. GSocket est un outil légitime d'accès à distance en open source. Une fois lancé sur un serveur, celui-ci et l'attaquant établissent des connexions sortantes vers un service relais public, le Global Socket Relay Network. Le relais relie ensuite les deux parties dans une session chiffrée. Le serveur n'a besoin d'aucun port ouvert ni d'adresse IP publique. Les attaquants n'exploitent aucune infrastructure propre : il n'existe donc aucune adresse IP ni aucun domaine d'attaquant à bloquer.

Il ne s'agit pas d'une vulnérabilité de GSocket. Les attaquants pénètrent d'abord dans une application web exposée sur Internet, puis installent GSocket pour conserver leur accès. Comme GSocket fonctionne indépendamment de l'application, corriger l'application ne le supprime pas. Microsoft indique que les détections liées à GSocket dans sa télémétrie ont augmenté de 356,2 % entre mars et août 2026.

Microsoft décrit les attaques de la manière suivante :

• Les attaquants exploitent une application web et utilisent curl pour télécharger et exécuter un script d'installation.
• Le script place le client GSocket dans des chemins accessibles en écriture ou basés sur la mémoire, comme /dev/shm.
• Le processus se fait passer pour des threads du noyau, par exemple [kaluad], ou pour des noms système comme systemd-remount-d et /usr/bin/defunct.
• La persistance est assurée par des tâches cron, des services systemd, des fichiers de démarrage du shell, des chiens de garde et des copies supplémentaires. Les fichiers temporaires sont ensuite supprimés et les dates de modification des fichiers sont falsifiées.
• Dans quelques cas, les attaquants ont tenté d'obtenir les droits root en exploitant la faille du noyau Linux CVE-2026-43284, connue sous le nom de "Dirty Frag".

Qui est concerné

Les serveurs Linux qui hébergent des applications web exposées sur Internet et qui ont été compromises à un moment donné. Selon les données de Microsoft, 87,1 % des incidents concernaient des applications web et des services d'hébergement. Dans ce groupe, les applications web PHP et l'hébergement cPanel représentaient 63,9 %, et Apache 24,3 %. Microsoft signale également des alertes pour des shells lancés depuis des applications web Java et Node.js. Les serveurs sur lesquels une faille d'application web a été détectée puis corrigée récemment méritent une attention particulière, car les attaquants ont pu entrer avant la correction.

Les serveurs dont les applications web n'ont jamais été compromises ne sont pas concernés. L'installation de GSocket volontairement par votre propre équipe ne constitue pas en soi un signe de compromission.

Que faire maintenant

1. Vérifiez chaque serveur Linux web exposé sur Internet en suivant les étapes de la section suivante. Commencez par les serveurs sur lesquels une faille d'application web, de CMS, d'extension ou de panneau d'hébergement a été corrigée ces derniers mois.
2. Si vous trouvez GSocket, considérez le serveur comme compromis. Arrêtez le processus. Supprimez ensuite le binaire, toutes les copies et toutes les entrées de démarrage automatique : cron, unités systemd, fichiers de démarrage du shell et scripts de surveillance. Microsoft note que la persistance est souvent multicouche : arrêter le processus ne suffit donc pas à supprimer l'accès. Si les attaquants ont pu obtenir les droits root, par exemple via CVE-2026-43284, le plus sûr est de reconstruire le serveur à partir d'une image propre ou d'une sauvegarde antérieure à la compromission.
3. Changez les identifiants du serveur concerné : mots de passe de bases de données, secrets d'application, clés d'API et clés SSH. Vérifiez également la présence d'entrées inconnues dans authorized_keys.
4. Identifiez et fermez la porte d'entrée. Mettez à jour les applications web, les CMS, les extensions et les serveurs d'applications. Supprimez les composants que vous n'utilisez pas et restreignez les chemins d'envoi de fichiers et d'administration.
5. Corrigez le noyau contre CVE-2026-43284 ("Dirty Frag") avec la mise à jour du noyau de votre distribution, puis redémarrez sur le nouveau noyau.
6. Restreignez le trafic sortant. Lorsque c'est possible, bloquez par défaut les connexions sortantes et n'autorisez que les destinations nécessaires à chaque serveur. Le trafic GSocket est uniquement sortant : les règles de pare-feu entrant ne le détectent donc pas.
7. Durcissez les répertoires temporaires. Lorsque c'est possible, montez /tmp et /dev/shm avec l'option noexec.
8. Vérifiez ensuite que le serveur n'est plus connecté au relais GSocket ni aux domaines listés ci-dessous.

Comment vérifier si vous êtes concerné

Exécutez ces contrôles en tant que root. Un résultat positif ne constitue pas une preuve à lui seul, mais il doit faire l'objet d'une investigation.

Fichiers et chemins cités par 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

Processus en cours :

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

Les véritables threads du noyau n'ont pas de fichier exécutable. Si un processus au nom entre crochets, tel que [kaluad], pointe vers un fichier, il est 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

Persistance :

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

Examinez attentivement les unités systemd dont le nom semble plausible mais que vous n'avez pas créées. Vérifiez les répertoires personnels des comptes de services web, comme www-data, apache et nobody, ainsi que ceux des utilisateurs cPanel.

Empreintes SHA-256 de fichiers connus, fournies par Microsoft :

• d94f75a70b5cabaf786ac57177ed841732e62bdcc9a29e06e5b41d9be567bcfa
• f95c4d029e6784e3849b4d1e2e2ae1a661187236ef7c5d487c71158a290a03b5
• 55d141bb2f62c527c3fea3413b8429fed7d52633d0b123b5e611bfa42165229f
• 12450bafc7a4398040e1ad3a16dbf4dbc79b6a8f83ef306c4f0f73f59886f06c

Réseau et journaux : Recherchez gsocket.io, cdn.gsocket.io et gsgg.b-cdn.net dans les journaux DNS, proxy et pare-feu. Ces domaines servent à télécharger l'outil. Recherchez également, dans l'historique des shells et les journaux du serveur web, les commandes qui récupèrent gsocket.io/y ou gsocket.io/install.sh avec curl. Recherchez les shells lancés par le serveur web ou par les processus PHP. Utilisez ss -tnp pour identifier les processus qui maintiennent des connexions sortantes, et examinez ceux que vous ne pouvez pas expliquer. Gardez à l'esprit que les attaquants suppriment les fichiers temporaires et l'historique des commandes : l'absence de traces à un endroit ne prouve donc pas que le serveur est sain.

Sources

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