GlassWorm : anatomie d'une attaque supply-chain sur 433 compos...

GlassWorm : anatomie d'une attaque supply-chain sur 433 composants open source

La campagne GlassWorm vient de frapper sa vague la plus massive à ce jour. Quatre équipes de recherche — Aikido, Socket, Step Security et la communauté OpenSourceMalware — ont collectivement identifié 433 composants compromis sur GitHub, npm et les registres VSCode/OpenVSX en mars 2026.

Périmètre de la compromission

La répartition des composants infectés couvre l'ensemble de l'écosystème de développement :

• 200 dépôts Python sur GitHub (compromis via account takeover + force-push)
• 151 dépôts JavaScript/TypeScript sur GitHub
• 72 extensions VSCode/OpenVSX
• 10 paquets npm

L'attribution à un acteur unique repose sur trois corrélations : une adresse Solana identique utilisée pour le C2 sur l'ensemble des vecteurs, des payloads fonctionnellement identiques, et une infrastructure partagée entre les différentes vagues.

Vecteur d'infection initial

La compromission commence par la prise de contrôle de comptes GitHub (account takeover). Les comptes compromis sont ensuite utilisés pour effectuer des force-push de commits malveillants, écrasant l'historique git légitime.

Un indicateur de compromission intéressant : dans les commits malveillants, la date du committer est significativement plus récente que la date de l'auteur original, trahissant la réécriture de l'historique.

Obfuscation Unicode

GlassWorm utilise des caractères Unicode invisibles pour masquer le code malveillant dans le code source. Cette technique exploite des caractères de formatage Unicode (catégorie Cf) qui ne produisent aucun rendu visuel dans la plupart des éditeurs de code et interfaces web.

Le code semble syntaxiquement correct et fonctionnellement identique à l'original lors d'une revue visuelle. Seule une analyse au niveau des octets ou un linter configuré pour détecter les caractères Unicode non-ASCII dans le code source permet d'identifier l'injection.

Architecture du C2 via Solana

L'aspect le plus original de GlassWorm est son mécanisme de command-and-control. Le malware interroge la blockchain Solana toutes les 5 secondes pour récupérer de nouvelles instructions.

Les instructions sont encodées sous forme de mémos dans les transactions Solana. Cette approche offre plusieurs avantages pour l'attaquant :

• Résilience : la blockchain est décentralisée, impossible à saisir ou à mettre hors ligne
• Anonymat : les adresses Solana sont pseudonymes
• Auditabilité réduite : le trafic blockchain se fond dans le trafic réseau légitime
• Flexibilité : mise à jour du payload URL par simple transaction

Entre le 27 novembre 2025 et le 13 mars 2026, Step Security a observé 50 transactions sur l'adresse C2, principalement destinées à mettre à jour l'URL du payload.

Chaîne d'exécution

1. Injection : code obfusqué inséré via force-push (GitHub) ou publication directe (npm/VSCode)
2. Déobfuscation : les caractères Unicode invisibles sont interprétés à l'exécution
3. Beacon C2 : requête à la blockchain Solana toutes les 5 secondes
4. Récupération du payload : téléchargement du runtime Node.js et d'un stealer JavaScript
5. Exécution : le fichier i.js exécute le stealer
6. Persistance : création de ~/init.json pour la survie au redémarrage
7. Exfiltration : vol de données ciblées

Données ciblées

• Données de portefeuilles crypto (fichiers wallet, clés privées)
• Credentials et tokens d'accès (GitHub, AWS, cloud providers)
• Clés SSH (~/.ssh/)
• Variables d'environnement contenant des secrets
• Données de l'environnement de développement

Indicateurs de compromission (IoC)

Fichiers :

• Variable marqueur dans le code : lzcdrtfxyqiplpd
• Fichier de persistance : ~/init.json
• Runtime Node.js non sollicité : ~/node-v22*
• Fichiers JavaScript suspects : i.js dans les projets récemment clonés

Comportement réseau :

• Requêtes récurrentes vers la blockchain Solana (RPC endpoints)
• Téléchargement de binaires Node.js depuis des sources non officielles

Git :

• Commits avec écart significatif entre author date et committer date
• Force-push sur des branches protégées

Attribution

Deux indices linguistiques pointent vers des acteurs russophones :

• Commentaires en russe dans certaines portions du code
• Le malware vérifie la locale du système et s'abstient d'exécuter si ru_RU est détecté

Ce comportement d'exclusion géographique (geo-fencing) est un pattern récurrent dans les campagnes de cybercriminalité originaires de la CEI, documenté notamment dans les ransomwares REvil, Conti et LockBit. Toutefois, ces éléments sont insuffisants pour une attribution formelle — ils pourraient constituer de faux drapeaux.

Historique de la campagne

GlassWorm n'est pas nouveau. Chronologie des vagues observées :

• Octobre 2025 : première détection sur les registres OpenVSX et VSCode
• Novembre 2025 : extension au marketplace officiel VSCode
• Décembre 2025 : ciblage macOS avec des clients Trezor/Ledger trojanisés
• Janvier-février 2026 : compromission d'extensions OpenVSX sur macOS
• Mars 2026 : vague massive — 433 composants sur GitHub, npm et VSCode/OpenVSX

L'escalade en termes de volume (de quelques dizaines à 433 composants) et de diversification des vecteurs (ajout de GitHub et npm aux registres d'extensions) indique une montée en capacité opérationnelle significative.

Remédiation

Pour les développeurs :

• Scanner les projets pour la variable marqueur lzcdrtfxyqiplpd
• Vérifier l'absence de ~/init.json et de runtimes Node.js non sollicités
• Auditer l'historique git des dépendances récemment mises à jour
• Utiliser des outils d'analyse statique configurés pour détecter les caractères Unicode non-ASCII
• Activer les notifications de force-push sur les dépôts critiques

Pour les organisations :

• Implémenter le pinning de dépendances avec vérification de hash (npm integrity, pip hash checking)
• Utiliser des solutions de Software Composition Analysis (SCA) en CI/CD
• Monitorer les logs réseau pour les connexions récurrentes vers les RPC Solana depuis des postes de développement