Les campagnes de **Glassworm** sont en cours depuis octobre 2025, ciblant initialement les développeurs avec des extensions malveillantes pour **OpenVSX** et **Microsoft VS Code**. Ces extensions étaient conçues pour voler des portefeuilles de cryptomonnaies et des identifiants de développeurs. Les attaques se sont ensuite étendues aux dépôts **GitHub** et aux packages **npm**, impactant plus de 400 artefacts logiciels lors d'une campagne en mars. Lors d'une attaque récente, les opérateurs de **Glassworm** ont implanté des dizaines d'extensions dormantes sur **OpenVSX** qui activaient leurs composants malveillants après une mise à jour. ## Infrastructure C2 résiliente L'une des raisons de la persistance de **Glassworm** réside dans son infrastructure C2. Le botnet exploitait des canaux de communication non traditionnels, rendant son démantèlement exceptionnellement difficile. « La combinaison de la blockchain, du peer-to-peer et des services web légitimes comme couches de résolution était conçue pour être résiliente aux démantèlements – un front dynamique protégeant les serveurs C2 réels derrière plusieurs couches d'indirection », a noté **CrowdStrike**. Les chercheurs ont souligné que les opérateurs du botnet avaient spécifiquement construit leur infrastructure pour la résilience. Le démantèlement a nécessité une action simultanée sur les quatre canaux C2 : 1. Blockchain **Solana** : Les adresses des serveurs C2 étaient encodées dans les champs mémo des transactions blockchain, créant un dépôt mort immuable et accessible publiquement. 2. Table de hachage distribuée (DHT) de **BitTorrent** : Le **GlasswormRAT** interrogeait le réseau peer-to-peer **BitTorrent** pour obtenir des données de configuration stockées contre des clés publiques codées en dur. 3. Service de calendrier public : **Glassworm** utilisait les titres d'événements **Google Calendar** comme emplacements de dépôt mort pour les chemins C2 encodés en Base64. 4. Connexions serveur directes : L'infrastructure C2 traditionnelle hébergée sur des fournisseurs VPS commerciaux servait de mécanisme final de livraison de payload.  *Architecture de commande et contrôle du botnet Glassworm source : CrowdStrike* En raison de cette architecture, la perturbation d'un seul canal aurait eu un impact minimal, car les communications auraient pu simplement basculer vers un autre canal, permettant à l'acteur de la menace de maintenir le contrôle. ## Démantèlement coordonné « Les quatre canaux devaient être perturbés simultanément dans un effort coordonné. Par conséquent, les machines infectées ne peuvent plus recevoir de nouvelles instructions ou de payloads », a déclaré **CrowdStrike**. Suite à la perturbation, toutes les machines compromises dans l'attaque **Glassworm** font désormais du beaconing vers l'adresse IP 164.92.88[.]210, qui est exploitée par **CrowdStrike**. Il est conseillé aux organisations de rechercher cet indicateur réseau et de prendre des mesures de remédiation immédiates. Les chercheurs ont également publié des règles YARA pour aider à confirmer les infections sur les hôtes suspectés. ## Le fossé de validation : le pentesting automatisé répond à une question. Vous en avez besoin de six. Les outils de pentesting automatisés apportent une réelle valeur, mais ils ont été conçus pour répondre à une seule question : un attaquant peut-il se déplacer sur le réseau ? Ils n'ont pas été conçus pour tester si vos contrôles bloquent les menaces, si vos règles de détection se déclenchent ou si vos configurations cloud tiennent bon. Ce guide couvre les 6 surfaces que vous devez réellement valider. [Télécharger maintenant](https://hubs.li/Q048zztN0)