GlassWorm : analyse de la campagne supply-chain ciblant GitHub...

La campagne de supply-chain GlassWorm a franchi un nouveau palier en mars 2026. Les chercheurs d'Aikido, Socket, Step Security et la communauté OpenSourceMalware ont identifié collectivement 433 composants compromis répartis sur quatre plateformes distinctes : 200 dépôts GitHub Python, 151 dépôts GitHub JS/TS, 72 extensions VSCode/OpenVSX et 10 packages npm.

L'attribution repose sur plusieurs marqueurs convergents : une adresse Solana unique utilisée pour le C2 (Command & Control) à travers l'ensemble de la campagne, des payloads fonctionnellement identiques et une infrastructure partagée.

Le vecteur d'attaque initial sur GitHub passe par la compromission de comptes existants, suivie d'un force-push de commits malveillants. L'analyse de Step Security montre une anomalie caractéristique : la date du committer est significativement plus récente que la date de l'auteur original, trahissant la réécriture de l'historique Git.

Sur npm et VSCode/OpenVSX, les packages et extensions publiés embarquent du code obfusqué via des caractères Unicode invisibles. Cette technique de substitution de glyphes rend le payload illisible dans les outils d'analyse statique classiques tout en restant parfaitement fonctionnel à l'exécution.

Le mécanisme de C2 est particulièrement intéressant d'un point de vue architectural. Le malware interroge la blockchain Solana toutes les 5 secondes via des requêtes RPC standard. Les instructions sont encodées sous forme de memos dans les transactions Solana. Entre le 27 novembre 2025 et le 13 mars 2026, Step Security a recensé 50 transactions, principalement dédiées à la mise à jour de l'URL du payload.

Ce choix de Solana comme canal C2 offre plusieurs avantages aux attaquants : la décentralisation rend le takedown quasi impossible, la rapidité du réseau (400ms de finalité) permet des mises à jour fréquentes, et le trafic RPC Solana se fond dans le bruit de fond des requêtes blockchain légitimes.

La chaîne d'exécution se déroule en quatre étapes. Premièrement, le code compromis extrait l'URL du payload depuis la memo Solana. Deuxièmement, il télécharge le runtime Node.js si absent du système. Troisièmement, un stealer JavaScript est exécuté. Quatrièmement, les données exfiltrées couvrent les wallets crypto, les credentials, les tokens d'accès, les clés SSH et les variables d'environnement de développement.

La persistance s'appuie sur le fichier ~/init.json. La variable marqueur « lzcdrtfxyqiplpd » sert d'indicateur de compromission (IoC) dans les fichiers sources. Les installations Node.js suspectes dans le répertoire home (~/node-v22*) constituent un autre signal.

L'analyse forensique révèle des commentaires en russe dans le code source et un mécanisme de kill-switch basé sur la locale système : le malware s'auto-désactive si la locale russe est détectée. Ces éléments sont insuffisants pour une attribution formelle mais orientent vers des acteurs russophones.

Comparé à la première vague d'octobre 2025, cette itération marque une escalade massive en termes de surface d'attaque. Le passage de quelques extensions VSCode à un assaut coordonné multi-plateforme de 433 composants démontre une montée en capacité significative du groupe.

Recommandations de remédiation : auditer les dépôts récemment clonés avec grep -r « lzcdrtfxyqiplpd », vérifier l'absence de ~/init.json, inspecter les historiques Git pour les anomalies de dates, et scanner les extensions VSCode installées contre les listes d'IoC publiées par Socket et Aikido. L'adoption de politiques de lockfiles stricts et de vérification de signatures sur les dépendances reste la meilleure défense structurelle contre ce type de campagne.