Ce qui s’est passé
Des chercheurs en sécurité signalent que des attaquants installent GSocket (Global Socket Toolkit) sur des serveurs Linux compromis pour y garder un accès durable. Selon Microsoft, qui a publié une analyse le 11 novembre 2026, plusieurs groupes malveillants détournent cet outil pour en faire un canal de commande et de contrôle (C2 : la liaison qu’un attaquant utilise pour piloter à distance une machine piratée) particulièrement discret.
Au départ, GSocket est un outil libre (open source) et légitime. Il permet à deux machines de communiquer même si toutes deux se trouvent derrière un pare-feu ou un routeur. Pour cela, chaque machine ouvre une connexion sortante vers un réseau public de relais, et ce relais met les deux machines en contact. Pour un attaquant, c’est très pratique :
- Aucun port entrant à ouvrir. Le serveur piraté appelle lui-même vers l’extérieur, ce que la plupart des pare-feu laissent passer.
- Un trafic chiffré qui passe par une infrastructure tierce. L’adresse du véritable attaquant n’apparaît jamais dans les journaux du serveur.
- Une installation en une seule commande, souvent accompagnée de mécanismes de persistance (redémarrage automatique via tâches planifiées ou scripts de connexion) et d’un nom de processus maquillé pour ressembler à un processus système.
Autre signal à surveiller : les rootkits eBPF attirent de plus en plus l’attention sur les forums criminels. eBPF est une fonction normale du noyau Linux (le cœur du système), qui sert à exécuter de petits programmes pour la surveillance ou le réseau. Un rootkit (logiciel malveillant conçu pour se cacher) qui s’appuie sur eBPF peut fonctionner directement dans le noyau. Il peut alors masquer des processus, des fichiers ou des connexions aux outils d’administration habituels. Autrement dit, les commandes qu’un administrateur lance pour vérifier son serveur peuvent lui renvoyer une image « propre » qui ne correspond pas à la réalité.
Pourquoi ça compte pour une PME
Beaucoup de PME suivent le même réflexe : une faille est annoncée, on applique le correctif, on clôt le dossier. Ce réflexe est nécessaire, mais il ne suffit pas. Le correctif ferme la porte d’entrée. Il ne fait pas sortir quelqu’un qui est déjà entré. Si la faille a été exploitée avant la mise à jour, l’accès laissé par GSocket fonctionne encore après.
- Qui est concerné : toute organisation qui exploite des serveurs Linux exposés à Internet (site web, boutique en ligne, VPN, applications métier, serveurs virtuels chez un hébergeur ou dans le nuage), qu’elle les gère elle-même ou par l’intermédiaire d’un fournisseur.
- Ce que l’attaquant peut faire : voler des données (clients, identifiants, bases de données), revenir à tout moment, se déplacer vers d’autres systèmes, installer un mineur de cryptomonnaie ou préparer un rançongiciel (logiciel qui chiffre vos fichiers pour exiger une rançon).
- Le niveau de risque est élevé si un serveur exposé a fonctionné avec une faille connue et exploitée, même pendant peu de temps. La discrétion de GSocket, et plus encore celle d’un rootkit eBPF, peut faire durer la compromission des semaines sans que personne ne la remarque.
- Côté conformité : une fuite de renseignements personnels causée par une porte dérobée restée en place peut déclencher les obligations de la Loi 25 au Québec (registre des incidents, avis à la Commission d’accès à l’information et aux personnes touchées en cas de risque de préjudice sérieux).
Comment se protéger
Priorité 1 : corriger, puis chercher activement les traces d’intrusion
Dans une logique ITIL, la gestion des vulnérabilités (appliquer le correctif) doit déclencher systématiquement une vérification de compromission lorsque la faille est connue pour être exploitée. Si vous trouvez une trace, ouvrez un incident. Après une faille exploitée, vérifiez au minimum les points suivants :
- Processus inhabituels : un nom qui imite un processus système (entre crochets, comme
[kworker]), lancé par un utilisateur inattendu, ou dont l’exécutable se trouve dans un répertoire caché ou dans/tmp. - Connexions sortantes persistantes vers des adresses inconnues, en particulier vers les domaines du réseau de relais GSocket (
gsocket.io,thc.org). - Tâches planifiées (cron) et services système ajoutés récemment.
- Scripts de démarrage de session (
.bashrc,.profile) modifiés pour relancer un binaire. - Clés SSH ajoutées dans les fichiers
authorized_keys, pour root et pour chaque utilisateur. - Programmes eBPF chargés que vous ne savez pas expliquer.
# Processus et chemin réel de leur exécutable
ps auxf
ls -l /proc/*/exe 2>/dev/null | grep -E "deleted|/tmp|/dev/shm|/\."
# Connexions sortantes établies et processus associés
ss -tnp state established
# Tâches planifiées et services
for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u "$u" 2>/dev/null; done
ls -la /etc/cron* /var/spool/cron 2>/dev/null
systemctl list-unit-files --type=service --state=enabled
# Persistance dans les scripts de session et clés SSH
grep -rnE "gs-netcat|gsocket|GS_SECRET" /root /home /etc 2>/dev/null
find / -name authorized_keys -exec ls -l {} \; -exec cat {} \; 2>/dev/null
# Programmes eBPF chargés (nécessite bpftool)
bpftool prog listAttention : si un rootkit eBPF est présent, ces commandes peuvent mentir. Un résultat « propre » obtenu sur le serveur lui-même ne prouve pas que le serveur est sain. Croisez-le avec des données externes : journaux du pare-feu, flux réseau observés par votre hébergeur, et indicateurs de compromission publiés par Microsoft dans son analyse.
Priorité 2 : décider entre nettoyer et réinstaller
| Situation | Décision recommandée |
|---|---|
| Faille corrigée, aucune trace trouvée, journaux réseau externes cohérents | Surveillance renforcée pendant quelques semaines, rotation préventive des secrets |
| GSocket ou autre porte dérobée trouvée, accès limité à un utilisateur non privilégié | Nettoyage possible, mais réinstallation préférable si le serveur est critique |
| Accès root obtenu, module noyau ou programme eBPF suspect, ou incohérence entre ce que montre le serveur et ce qu’on observe sur le réseau | Réinstallation complète à partir d’une image saine, puis restauration des données uniquement (jamais des binaires ni des configurations non vérifiées) |
Un attaquant qui contrôle le noyau peut survivre à un nettoyage partiel. Dans ce cas, réinstaller coûte moins cher qu’une seconde intrusion. Traitez la reconstruction comme un changement ITIL planifié : sauvegarde vérifiée, image de référence, correctifs appliqués avant la remise en ligne.
Priorité 3 : couper l’accès et renouveler les secrets
- Isolez le serveur suspect sur le plan réseau avant toute analyse approfondie, en conservant si possible une copie de ses disques pour l’enquête.
- Changez tous les mots de passe, clés SSH, jetons d’API et identifiants de bases de données qui étaient stockés sur le serveur ou utilisés depuis celui-ci.
- Bloquez au pare-feu les domaines de relais GSocket si votre activité n’en a pas besoin, et créez une alerte sur toute tentative de connexion vers ces domaines.
Priorité 4 : se donner les moyens de voir
- EDR sur les serveurs Linux (outil de détection et de réponse installé sur chaque machine). Il enregistre les lancements de processus, les modifications de persistance et le chargement de programmes eBPF. Il peut aussi isoler une machine à distance. C’est ce qui permet de repérer une installation GSocket au moment où elle se produit.
- Surveillance réseau : comme le rootkit trompe le système de l’intérieur, le réseau reste un témoin indépendant. Une connexion sortante permanente vers un relais inconnu se voit dans les journaux du pare-feu, même quand le serveur la cache.
- Filtrage des connexions sortantes : un serveur web n’a généralement besoin de joindre que quelques destinations précises (mises à jour, API partenaires). Bloquer le reste prive GSocket de son principal atout.
- Limiter eBPF : réservez le chargement de programmes eBPF aux comptes privilégiés (paramètre
kernel.unprivileged_bpf_disabled=1) et réduisez au strict nécessaire les comptes disposant des droits root.
Qui alerter
- Votre hébergeur ou infogérant, dès qu’un doute apparaît : il dispose souvent de journaux réseau que vous n’avez pas.
- Votre assureur cyber, si vous en avez un, avant d’effacer quoi que ce soit.
- Le Centre canadien pour la cybersécurité, pour signaler l’incident, et la Commission d’accès à l’information si des renseignements personnels sont touchés et qu’il existe un risque de préjudice sérieux (Loi 25).
À retenir : après une faille exploitée, la bonne question n’est pas seulement « avons-nous corrigé ? », mais aussi « l’attaquant est-il encore là ? ». Sans visibilité indépendante (EDR et surveillance réseau), il est souvent impossible de répondre avec certitude.
