Le PolinRider est maintenant allé bien au-delà de npm. La campagne touche les écosystèmes Go, Packagist et npm simultanément. Des analystes de Socket ont répertorié 162 artefacts malveillants disséminés dans 108 paquets distincts. De plus, la télémétrie a révélé une compromission active dans 80 modules Go, 10 paquets du Packagist et au moins une extension Chrome.
Le groupe derrière l’opération apparaît dans les rapports sous les noms Contagious Interview ou Famous Chollima. Par conséquent, vous êtes confronté à des acteurs étatiques nord-coréens dotés d’objectifs clairement définis. Ils prennent le contrôle de comptes légitimes de mainteneurs et modifient des dépôts fiables. Ainsi, ils parviennent à publier des versions infectées dans les pipelines des entreprises et à maintenir l’accès au registre.
Pourquoi les sources fausses sont devenues le repaire privilégié
La mécanique de l’attaque débute par des chargeurs JavaScript dissimulés dans des ressources apparemment inoffensives. Tout d’abord, les pirates remplissent les lignes exécutables avec des espaces en trop. Ainsi, le code malveillant échappe à la largeur visible standard de l’IDE. Ensuite, ils cachent le chargeur entier dans des fichiers de police .woff2 falsifiés. De cette façon, la charge malveillante se déguise en un simple élément visuel statique.
tasks.json : le déclencheur silencieux à l’intérieur de VS Code
L’exécution de ces charges utiles dépend de vos outils de développement locaux. Les attaquants exploitent les fichiers de tâches de Visual Studio Code pour forcer l’exécution. Un fichier .vscode/tasks.json modifié configure une tâche silencieuse en arrière-plan. Par conséquent, cette tâche se déclenche chaque fois que vous ouvrez le dossier du projet. Elle transmet discrètement la fausse police .woff2 à Node.js. Par conséquent, l’infection commence avant même que vous compiliez l’application.
Blockchain comme canal de distribution de la seconde charge
La déobfuscation de la charge utile initiale révèle un chargeur connecté à des réseaux blockchain. Le chargeur recherche une infrastructure RPC publique sur TRON, BNB Smart Chain et Aptos. Ainsi, il extrait des charges utiles de second stade cryptées. Cette architecture Web3 décentralisée offre une résilience aux attaquants. De plus, elle contourne les filtres de sortie et les listes de blocage de domaines. Le chargeur déchiffre le contenu à l’aide de clés XOR intégrées. Puis il exécute le code résultant via la fonction eval().
OmniStealer et DEV#POPPER : ce que transportent les charges utiles
Les charges secondaires actuelles incluent OmniStealer et DEV#POPPER. Ces malwares offrent une compromission complète de la station de travail. Par conséquent, ils permettent l’exécution arbitraire de commandes et la collecte des identifiants. De plus, ils volent des données du navigateur et vident les portefeuilles de cryptomonnaies. Le design modulaire du chargeur accroît encore le risque. Ainsi, les attaquants changent de malware dès que les contrôles de sécurité s’adaptent.
Push forcé et commits antidatés : l’art de disparaître dans l’historique
Les attaquants utilisent Git push forcé et injectent des commits antidatés. Ainsi, ils tissent les modifications dans d’anciennes mises à jour de maintenance. L’historique visible paraît souvent légitime. De plus, il affiche des messages routiniers de mainteneurs de confiance. C’est pourquoi votre équipe doit passer en revue les journaux d’activité du dépôt. De cette manière, vous identifiez des réécritures rétroactives de l’historique et des pushes forcés suspects.
Le cas du compte Xpos587 sur GitHub illustre bien cette coordination. Plusieurs projets de ce compte ont reçu des mises à jour simultanées dans une fenêtre temporelle courte. Par conséquent, le motif pointe vers une compromission au niveau du compte suivie d’une modification massive. Les attaquants ont publié des modules Go infectés dans des dépôts en aval. Toutefois, ils se sont retrouvés sans identifiants pour envoyer des versions malveillantes sur PyPI.
Une situation similaire a touché l’écosystème PHP sur Packagist. La campagne a infiltré l’espace de noms sevenspan, géré par l’organisation 7span. Les mainteneurs internes ont repéré les fichiers .woff2 anormaux et ont commencé un nettoyage partiel. Cependant, ils ont perdu des variantes cachées dans vite.config.js et eslint.config.js. Ainsi, le JavaScript obscurci est resté actif dans l’infrastructure du dépôt.
Du notebook du développeur au cluster Kubernetes
L’intrusion sur une seule station expose déjà l’ensemble du réseau d’entreprise. Les attaquants privilégient le vol de jetons d’authentification de grande valeur. Le vol d’identifiants Kubernetes, par exemple, donne un accès administratif à l’environnement de production. De plus, l’objectif central concerne des points d’accès persistants dans le CI/CD. Une fois dans le pipeline, ils injectent des artefacts malveillants dans vos releases propriétaires. Ainsi, l’entreprise victime devient un vecteur actif de la prochaine attaque à la chaîne d’approvisionnement.
Comment sécuriser vos dépôts dès maintenant
Commencez par l’audit des journaux d’activité et de l’historique des pushes forcés. Ensuite, activez la protection des branches et exigez une revue obligatoire à chaque fusion. De plus, inspectez les fichiers de configuration tels que tasks.json, vite.config.js et eslint.config.js. Vérifiez également toute police .woff2 nouvellement ajoutée au projet. Des outils comme Socket vous aident à repérer les dépendances suspectes avant la fusion. Enfin, adoptez l’authentification multifactorielle sur toutes les comptes de mainteneurs. Ainsi, vous fermez la porte principale par laquelle PolinRider peut pénétrer.
Acompaña nosso perfil no Instagram!
