Secu
Glassworm : le botnet qui visait les développeurs perd ses fils
Par Laurent Delattre, publié le 28 mai 2026
Glassworm n’est pas un botnet comme les autres. En ciblant les développeurs, leurs extensions, leurs dépendances et leurs dépôts GitHub, il attaque non pas les applications finies, mais la chaîne de fabrication logicielle. CrowdStrike, Google et la Shadowserver Foundation viennent d’en coordonner le démantèlement, au moins partiellement.
Glassworm est un ver auto-propagé et un botnet spécialisé dans le ciblage des développeurs. Son terrain de chasse : les environnements de développement, les extensions VS Code et compatibles, les paquets npm et Python, les dépôts GitHub, les secrets d’accès et les identifiants permettant de rebondir d’un projet à l’autre. Dit autrement, ce malware a été spécifiquement taillé pour compromettre la supply chain logicielle.
CrowdStrike estime que la campagne est active depuis au moins début 2025. Ses « faits de gloire » résument à eux seuls l’évolution des attaques supply chain depuis 18 mois. Glassworm a publié des extensions VS Code piégées sur OpenVSX (le registre d’extensions utilisé notamment par plusieurs éditeurs de code dérivés ou compatibles VS Code), déguisées en outils anodins de productivité ou de formatage. Il a aussi compromis des paquets npm et Python, où le code malveillant s’exécutait via des scripts d’installation. Il a même utilisé des identifiants volés lors d’infections précédentes pour empoisonner plus de 300 dépôts GitHub, en poussant du code malveillant dans des branches par défaut. Dit autrement, Glassworm ne s’attaque pas seulement aux développeurs, il cherche à contaminer, par ricochet, les bibliothèques et logiciels que ces derniers produisent et par extension les entreprises qui les utilisent pour construire leurs applications métiers.
La subtilité de Glassworm tient aussi à sa discrétion. Le ver exploite des techniques d’injection fondées sur des caractères Unicode invisibles, rendant certaines charges difficiles à voir lors d’une revue de code classique. Une fois installé, il peut voler des identifiants, siphonner des secrets, transformer des postes de développeurs en nœuds de relais et déployer GlasswormRAT, un outil d’accès distant en Node.js. Le malware touche Windows, macOS et Linux, ce qui élargit mécaniquement sa surface d’exposition.
Pourquoi Glassworm était difficile à éteindre
Un botnet classique s’appuie souvent sur quelques serveurs de commande et de contrôle. En les saisissant, en les neutralisant ou en les faisant filtrer, on coupe une partie du pilotage.
Les créateurs de Glassworm avaient bien conscience de ce talon d’Achile et se sont montrés plus rusés. Ils ont imaginé une architecture de pilotage (C2) singulière, reposant sur quatre canaux distincts, dont plusieurs conçus pour résister aux démantèlements traditionnels :
– Le premier passe par la blockchain Solana : les adresses des serveurs C2 étaient encodées dans les champs mémo de transactions, créant une sorte de « dead drop » public (une boîte aux lettres anonyme), immuable et difficile à effacer. Le malware peut ainsi lire ses instructions, sans que les opérateurs aient besoin de communiquer directement avec lui.
– Le deuxième utilise la DHT BitTorrent, un réseau pair-à-pair décentralisé, pour récupérer de la configuration à partir de clés publiques codées en dur. Ainsi, le malware ne dépend pas d’un serveur central pour savoir où se connecter mais exploite le célèbre réseau BitTorrent comme une sorte d’annuaire clandestin et décentralisé.
– Le troisième exploite Google Calendar, dont les titres d’événements ont ici été utilisés comme points de dépôt pour des chemins C2 encodés en Base64. Le malware exploite donc le calendrier Google comme une sorte de panneau d’affichage qu’il peut lire et décoder.
– Le quatrième est plus classique et repose des serveurs VPS commerciaux, utilisés pour la livraison finale des charges malveillantes. Glassworm loue des serveurs chez des hébergeurs classiques et les utilise comme entrepôts techniques pour distribuer les derniers morceaux du malware aux machines déjà compromises.
Toute la force de Glassworm réside dans cette architecture hybride. Le botnet ne se contente pas de cacher ses serveurs. Il multiple les mécanismes de résolution permettant à une machine infectée de retrouver où aller chercher ses instructions. Supprimer un seul canal n’aurait donc pas suffi à le démanteler. Le botnet aurait pu basculer sur les autres et se reconstituer rapidement. C’est ce qui explique la nécessité de mener une vaste opération coordonnée, synchronisée, visant les quatre canaux à la fois.
Un démantèlement par synchronisation
Ainsi, ce 26 mai 2026 à 14 h UTC, CrowdStrike a exécuté, avec Google et la Shadowserver Foundation, une opération de démantèlement coordonnée contre les quatre canaux C2 de Glassworm. L’objectif n’était pas seulement de fermer quelques serveurs, mais de couper les opérateurs de leurs machines infectées et de bloquer leur capacité à pousser de nouvelles charges.
La méthode exacte n’est pas entièrement détaillée. Comme souvent, les fondements techniques et juridiques précis de l’opération n’ont pas été explicités publiquement. Le secret est une arme de la cyberdéfense. Dans ce type d’opération, la partie visible est souvent la moins intéressante. Ce qui fait la différence, c’est la combinaison de renseignement, d’accès aux plateformes abusées, de coopération avec des opérateurs d’infrastructure et de capacité à agir au même moment sur plusieurs couches.
On peut néanmoins reconstituer la logique opérationnelle. CrowdStrike a fourni l’analyse du malware, la cartographie des canaux C2 et la coordination technique. Google avait un rôle naturel à jouer puisque Glassworm abuse de Google Calendar comme canal de secours. Shadowserver, organisation spécialisée dans l’observation et la mesure d’infrastructures malveillantes sur Internet, a apporté sa capacité de suivi à grande échelle.
Au final, l’opération n’a pas permis de prendre intégralement le contrôle du botnet et de ses opérateurs. Mais l’opération a fait en sorte que les machines infectées ne peuvent désormais plus recevoir de nouvelles instructions via les anciens mécanismes de commande.
Les RSSI doivent néanmoins rester vigilants et surtout vérifier la présence d’un indicateur important : les machines infectées par Glassworm émettent désormais vers une adresse IP bénigne opérée par CrowdStrike, « 164.92.88.210 ». Les entreprises sont invitées à vérifier leurs journaux réseau et leur télémétrie endpoint pour repérer d’éventuelles connexions à cette adresse, qui signaleraient une infection à traiter. Des règles YARA ont aussi été mises à disposition pour confirmer la présence de GlasswormRAT ou de variantes du downloader Glassworm.
Une bataille remportée dans une guerre qui se poursuit
Reste que le démantèlement annnocé de Glassworm ne signifie pas que tout risque a disparu. Il signifie plutôt que les attaquants ont temporairement perdu leur capacité à piloter les infections existantes.
Dit autrement, il y a toujours urgence à nettoyer les postes compromis, à révoquer les identifiants dérobés, à renouveler les jetons, à auditer les dépôts et à inspecter les dépendances. Dans une attaque supply chain, couper le centre de commandement du botnet « ne répare pas » automatiquement le code empoisonné ni les secrets déjà exfiltrés.
Et il faut aussi y voir une piqure de rappel. Glassworm (et les autres botnets ciblant la supply chain logicielle) souligne l’importance de traiter l’environnement de développement comme une zone critique du SI, pas comme un simple poste bureautique amélioré. Cela suppose une supervision endpoint sérieuse sur les machines développeurs, une gestion stricte des secrets, une rotation rapide des jetons, une authentification forte sur GitHub, npm, PyPI et autres registres internes, ainsi qu’un contrôle des extensions IDE et des dépendances. La sécurité supply chain ne peut plus se limiter au scan du code livré. Elle doit commencer là où le logiciel se fabrique.
À LIRE AUSSI :
À LIRE AUSSI :
