GlassWorm revient: la campagne de la chaîne d'approvisionnement qui cache les logiciels malveillants avec Unicode invisible dans les repos, paquets et extensions

La campagne d'engagement de la chaîne d'approvisionnement connue sous le nom de GlassWorm a réapparu avec une vague coordonnée beaucoup plus large que celle initialement observée. Chercheurs de diverses collectivités et sociétés de sécurité - y compris Aïkido, Socket, Sécurité des étapes et de la communauté OpenSourceMalware- ont identifié des centaines de paquets, dépôts et extensions affectés sur des plateformes telles que GitHub, npm et les marchés d'extension pour les éditeurs.

Dans cette nouvelle phase, la portée est remarquable : des centaines de dépôts Python et JavaScript ont été documentés dans GitHub, des dizaines d'extensions dans VSCode / OpenVSX et plusieurs paquets publiés dans npm contenant du code coupé ou ostruqué par des caractères Unicode "invisible". La technique d'insertion de caractères non imprimables permet au code malveillant de passer inaperçu pour les examens de surface et les filtres automatiques, parce que le fichier peut sembler légitime pour les yeux humains et les scanners qui ne normalisent pas le texte.

La recherche conjointe indique le même opérateur derrière les différentes vagues: les rapports mettent en évidence l'utilisation répétée d'une direction dans la blockchain de Solana en tant que canal de commande et de contrôle, la réutilisation d'infrastructures et de charges utiles avec des fonctionnalités équivalentes, et des modèles de sortie et de persistance comparables entre les projets touchés. Ce sont les détails qui permettent aux analystes de corréler les incidents et suggèrent qu'ils ne sont pas des attaques isolées, mais une campagne centralisée.

Techniquement, l'infection commence généralement par la prise en compte dans GitHub et l'introduction d'engagements malveillants par force-pouss. De là, les attaquants publient des paquets ou des extensions vers des enregistrements tels que npm ou OpenVSX. Le malware inclut une routine qui consulte la chaîne de verrouillage de Solana toutes les quelques secondes à la recherche d'instructions codées par transaction - Step Security chercheurs documenté environ 50 transactions pertinentes entre la fin novembre 2025 et la mi-mars 2026 - et ces instructions dirigent le téléchargement et l'exécution d'un runtime Node.js qui déploie un voleur d'informations écrit sur JavaScript.

Les objectifs du logiciel espion sont clairs : extraction de données à partir des pièces de cryptomoneda, des identifiants, des jetons d'accès, des clés SSH et des artefacts d'environnement de développement qui vous permettent de pivoter et de voler des dépôts ou des identifiants supplémentaires. Dans certaines campagnes précédentes, il y a eu aussi un certain nombre de macos échoués - par exemple des clients contrefaits de porte-monnaie matérielle - et des extensions engagées qui ont atteint des IDE non soutenus par OpenVSX, comme décrit par un chercheur dans la analyse d'OpenVSX.

L'analyse du code indique aux auteurs qui commentent en russe et à une logique qui évite de fonctionner dans des systèmes configurés dans cette langue; cependant, que les seules données ne suffisent pas à attribuer la responsabilité à une nation ou à un groupe donné avec certitude. L'attribution exige davantage de preuves opérationnelles et une corroboration de plusieurs sources.

Si vous travaillez avec des unités installées directement à partir de dépôts ou généralement des projets clonés pour les mettre en œuvre, il est approprié d'examiner les indicateurs techniques que les analystes ont partagés. L'un d'eux est la présence d'une variable marqueur identifiée comme « lzcdrtfxyqiplpd », qui a servi de signe révélateur dans plusieurs dépôts commis. La persistance a également été détectée à l'aide d'un fichier de configuration local (~ / La Commission a décidé d'ouvrir la procédure.) et l'installation silencieuse des versions Node.js dans les répertoires utilisateurs (comme ~ / node-v22 *), en plus des fichiers suspects avec des noms comme i.js dans les projets et engagements nouvellement clonés dont les métadonnées montrent des différences étranges entre la date de l'auteur et celle de l'engagement.

Compte tenu de ce scénario, les mesures de confinement et d'atténuation passent par des clés tournantes et des jetons qui ont pu être exposés, vérifient l'historique des engagements et des paquets publiés sur leurs propres comptes et cherchent des artefacts mentionnés dans les systèmes de développement. Il est également recommandé d'activer des contrôles supplémentaires sur les comptes de dépôt : activer l'authentification de deux facteurs, revoir les sessions actives et les clés SSH autorisées, et limiter les jetons avec des autorisations minimales. GitHub et d'autres fournisseurs publient des guides pour sécuriser les comptes et les dépôts; par exemple, la documentation 2FA de GitHub est un bon point de départ: https: / / docs.github.com /... / deux facteurs-authentification-2fa.

Pour les équipes de développement et les gestionnaires de plate-forme, il est essentiel de traiter les dépendances comme un code potentiellement peu fiable : valider les signatures lorsqu'elles existent, définir des versions dans les fichiers de verrouillage, examiner les changements dans les paquets transitoires et tirer parti des outils d'analyse de la chaîne d'approvisionnement qui scannent les dépôts et les dossiers de paquets. Les responsables de l'enregistrement et de la commercialisation devraient également améliorer la détection des modèles d'utilisation d'Unicode et renforcer les processus de vérification des comptes et des publications.

En ce qui concerne la réponse aux incidents, il convient de conserver les preuves (logs, accumulations, copies de fichiers engagées), de déconnecter les machines infectées des réseaux de développement et de dresser un inventaire des secrets qui auraient pu être exfiltrés. Les organisations qui dépendent de sources ouvertes dans la production devraient envisager d'autres mesures de prévention, comme des environnements de construction isolés, des signatures reproductibles et des pipelines qui n'appliquent pas de code de tiers sans examen préalable.

GlassWorm nous rappelle que la sécurité des logiciels modernes ne se limite pas au code que nous écrivons, mais s'étend à l'immense surface qui forme des dépôts, des paquets et des extensions tierces. La chaîne d'approvisionnement du logiciel est aussi forte ou faible que le maillon le moins protégé, et cette campagne montre comment les acteurs avec des pratiques et des ressources peuvent évoluer latéralement grâce à des outils et des services légitimes pour atteindre des objectifs précieux.

Si vous voulez entrer dans les rapports techniques et examiner les indicateurs publiés par les équipes qui ont analysé cette menace, vous pouvez voir les articles d'Aikido sur le retour de GlassWorm ( Voilà.), l'analyse OpenVSX par Socket ( Voilà.) et la rupture de la sécurité de la campagne et des signaux d'engagement ( Voilà.). Pour comprendre comment les transactions de Solana peuvent transporter des mémos avec des instructions, la documentation officielle de Solana sur le programme Memo est une référence utile: https: / / docs.solana.com /... / programmes # mémo-programme.

La communauté de la sécurité et les promoteurs doivent être vigilants et partager des indicateurs et des mesures d'atténuation pour mettre fin à cette campagne et à d'autres campagnes semblables. La collaboration entre les gestionnaires de l'infrastructure, les gestionnaires de projet à source ouverte et les fournisseurs d'enregistrement est essentielle pour réduire la fenêtre d'exposition et élever la barre de protection pour tous.