CrowdStrike a annoncé le démantèlement coordonné du botnet Glassworm, une opération d’envergure qui ciblait les développeurs de logiciels par l’intermédiaire de packages open source compromis, d’extensions VSCode malveillantes et de dépôts GitHub contaminés.
Menée avec Google et la Shadowserver Foundation, l’opération a perturbé l’infrastructure du botnet et interrompu les communications entre ses opérateurs et les systèmes infectés.
« En collaboration avec Google et la Shadowserver Foundation, nous avons neutralisé simultanément les quatre canaux de commande et de contrôle (C2) de Glassworm », a déclaré CrowdStrike dans son article consacré à l’opération.
Principaux enseignements du démantèlement du botnet Glassworm
- CrowdStrike, Google et la Shadowserver Foundation ont perturbé le botnet Glassworm de la chaîne d’approvisionnement
- La campagne ciblait les développeurs au moyen d’extensions VSCode malveillantes, de packages npm/Python et de dépôts GitHub contaminés
- Glassworm utilisait une infrastructure C2 décentralisée comprenant Solana, le DHT de BitTorrent, Google Calendar et des serveurs VPS
- Plus de 300 dépôts GitHub auraient été compromis au moyen d’identifiants de développeurs dérobés
- Le logiciel malveillant ciblait les systèmes Windows, macOS et Linux, avec des capacités de vol d’identifiants et d’accès à distance
Au cœur de la campagne Glassworm
La campagne Glassworm met en évidence l’intérêt croissant que les attaquants portent aux développeurs de logiciels et, plus largement, à lachaîne d’approvisionnement logicielle.
Comme les développeurs disposent souvent d’un accès privilégié aux dépôts, aux plateformes cloud et aux pipelines de déploiement, la compromission d’un seul compte de développeur peut offrir aux attaquants un moyen de distribuer du code malveillant dans des écosystèmes logiciels de confiance.
Comment Glassworm a ciblé les développeurs
Selon CrowdStrike, les opérateurs de Glassworm ont utilisé plusieurs mécanismes de diffusion afin de maximiser leur portée dans les environnements de développement et les écosystèmes open source.
La campagne diffusait des extensions VSCode troyanisées via la marketplace OpenVSX, en les faisant passer pour des outils de développement légitimes, notamment des formateurs de code et des utilitaires liés à la productivité.
Les extensions malveillantes auraient ciblé plusieurs environnements de développement au-delà de VSCode, notamment Cursor, VSCodium, Windsurf et Positron.
Les opérateurs ont également compromis des packages npm et Python en y intégrant des scripts malveillants exécutés après l’installation, conçus pour se lancer automatiquement lors de l’installation des dépendances.
Plus de 300 dépôts GitHub auraient été contaminés à l’aide d’identifiants de développeurs dérobés afin d’introduire du code malveillant dans des dépôts de confiance et leurs branches par défaut.
Le logiciel malveillant a affecté les systèmes Windows, macOS et Linux et comprenait un outil d’accès à distance basé sur Node.js, connu sous le nom de GlasswormRAT.
CrowdStrike a indiqué que le logiciel malveillant permettait le vol d’identifiants, la persistance, la collecte d’informations et l’accès à distance sur les systèmes de développeurs compromis.
Au cœur de l’infrastructure C2 de Glassworm
L’infrastructure de Glassworm était également conçue pour résister aux tentatives traditionnelles de perturbation en s’appuyant simultanément sur plusieurs canaux de commande et de contrôle (C2) décentralisés.
Selon CrowdStrike, un mécanisme de communication stockait les informations relatives aux serveurs dans les champs de mémo des transactions de la blockchain Solana, créant ainsi un système de dépôt public résistant aux méthodes classiques de démantèlement.
Un autre exploitait le réseau Distributed Hash Table (DHT) de BitTorrent pour récupérer les données de configuration via une infrastructure pair à pair dépourvue de point de défaillance centralisé.
Le logiciel malveillant utilisait également les titres d’événements Google Calendar pour stocker des chemins C2 encodés en Base64, tout en conservant des serveurs traditionnels hébergés sur VPS pour la diffusion des charges utiles finales et le contrôle opérationnel.
Cette architecture en couches créait une redondance entre les services blockchain, les réseaux pair à pair (P2P), les plateformes cloud et les fournisseurs d’hébergement traditionnels, permettant aux opérateurs de rester résilients même en cas de perturbation d’un canal de communication.
Comment CrowdStrike a perturbé le botnet
CrowdStrike a souligné que les quatre canaux de commande et de contrôle devaient être perturbés simultanément pour désactiver efficacement le botnet et interrompre les communications avec les systèmes infectés.
L’entreprise a indiqué que les opérateurs avaient fait évoluer leurs outils de JavaScript vers Rust et Zig, tout en les étendant à d’autres plateformes de développement.
Comment réduire les risques liés à la chaîne d’approvisionnement
Alors que les attaques visant la chaîne d’approvisionnement logicielle continuent de cibler les environnements de développement et les écosystèmes open source, les entreprises sont poussées à renforcer leurs contrôles de sécurité dans les pipelines de compilation, les dépôts et les processus de gestion des dépendances.
- Surveiller les environnements de développement, les pipelines CI/CD et les dépôts pour détecter les activités anormales liées aux packages, les modifications non autorisées et les comportements d’authentification suspects.
- Valider les extensions et les dépendances avant leur installation, limiter les packages tiers superflus et utiliser si possible des dépôts privés d’artefacts.
- Imposer l’authentification multifacteur, le principe du moindre privilège et la protection des branches, des commits signés et des contrôles des accès privilégiés sur les comptes de développeurs et d’administrateurs.
- Mettre en place la vérification de la signature du code, l’analyse de la composition logicielle (SCA), la visibilité sur les SBOM et la surveillance de l’intégrité des fichiers afin d’identifier les composants malveillants ou vulnérables.
- Isoler les environnements de développement et de compilation des systèmes de production tout en limitant les connexions sortantes superflues vers les écosystèmes publics de packages.
- Renforcer la visibilité sur les terminaux et les capacités de détection comportementale sur les postes de travail des développeurs afin d’identifier le vol d’identifiants, la persistance et les activités de compilation suspectes.
- Tester régulièrement la réponse aux incidents, les plans de confinement et de reprise liés aux compromissions de la chaîne d’approvisionnement logicielle, aux packages malveillants et aux violations de dépôts.
Collectivement, ces mesures peuvent aider les entreprises à réduire leur exposition aux risques de la chaîne d’approvisionnement logicielle et à renforcer leur résilience opérationnelle.
Le développement de la menace visant la chaîne d’approvisionnement
L’opération Glassworm illustre une évolution plus large vers des attaques ciblant les écosystèmes logiciels de confiance et les infrastructures des développeurs.
Les dépôts open source, les registres de packages et les environnements CI/CD restent des cibles privilégiées, car un seul package ou compte de développeur compromis peut affecter des milliers d’utilisateurs et de systèmes en aval.
La détection seule devient moins efficace contre les attaques visant la chaîne d’approvisionnement, car les packages et dépendances malveillants peuvent se propager rapidement dans les processus de développement automatisés avant d’être identifiés.
CrowdStrike a souligné que les efforts de perturbation proactive et la collaboration intersectorielle devenaient essentiels pour réduire les risques liés à la chaîne d’approvisionnement et perturber les infrastructures de menace résilientes.
se tournent vers des solutions zero trust pour contribuer à renforcer les contrôles d’accès, la segmentation et la sécurité globale des environnements de développement.