Une nouvelle campagne de paquets npm malveillants vient d’être mise en évidence : près de 800 modules nuisibles ont été publiés sur le registre npm avec l’objectif de compromettre des systèmes Windows, macOS et Linux. Leur point commun : tous livrent un RAT (Remote Access Trojan) ainsi qu’un infostealer, capables d’ouvrir la voie à la prise de contrôle et au vol d’informations.
Selon les analyses rapportées, la campagne s’appuie sur des noms de packages imitant des dépendances légitimes (typosquatting) et fournit un mécanisme d’exécution détourné via la documentation du projet. Le résultat : une chaîne d’infection qui récupère ensuite un payload adapté à la plateforme avant de l’exécuter.
Pourquoi ces paquets npm sont particulièrement dangereux
Dans beaucoup d’attaques orientées supply chain, le code malveillant se déclenche grâce à des étapes automatiques du cycle de vie, par exemple preinstall ou postinstall. Ici, l’approche diffère : les paquets identifiés affichent, dans leur README, des instructions invitant les développeurs à les charger explicitement avec la fonction require().
Cette subtilité peut réduire l’attention des équipes, car l’exécution ne dépend pas forcément d’un hook standard. Une fois la fonction appelée, le module passe à l’étape suivante : le lancement d’un téléchargeur nommé WEL1DROPPER.
Le téléchargeur détecte l’OS et l’architecture
Le téléchargeur commence par identifier l’environnement de la machine cible, notamment le système d’exploitation et l’architecture du processeur. Ensuite, il récupère un payload compatible auprès d’hôtes distants déployés sur Cloudflare Workers.
Trois domaines (Cloudflare Workers) sont rapportés comme sources potentielles de téléchargement :
- oob-worker.cf103-070.workers[.]dev
- oob-worker.cf102-baf.workers[.]dev
- oob-worker.cf99-9b3.workers[.]dev
Si ces téléchargements échouent via HTTPS, la charge malveillante bascule vers une méthode alternative : elle utilise des enregistrements DNS TXT pour récupérer une nouvelle étape.
Livraison via DNS TXT et domaines de payload
Lors du repli, la chaîne s’appuie sur le domaine wel1[.]ru. Le mécanisme décrit implique l’interrogation d’un enregistrement TXT sous la forme c.<domain>. La réponse est ensuite interprétée comme un nombre de morceaux de payload (entre 1 et 2 000). Le code interroge ensuite des TXT numérotés, concatène les chaînes renvoyées, puis applique un décodage Base64 pour reconstituer un tampon binaire.
Les domaines de payload indiqués varient selon l’OS et l’architecture :
- Linux x64 : sdk.dl.wel1[.]ru
- Linux ARM64 : ext.dl.wel1[.]ru
- macOS : pkg.dl.wel1[.]ru
- Windows : net.dl.wel1[.]ru
Ce comportement renforce la robustesse de l’attaque : même si un canal HTTPS est bloqué, la récupération via DNS peut permettre de maintenir la compromission.
Exécution finale : scripts shell, cmd.exe et processus détaché
Une fois le payload reconstitué, la dernière étape consiste à l’écrire dans un dossier temporaire puis à l’exécuter.
Le chemin d’exécution varie selon la plateforme :
- Linux et macOS : exécution via /bin/sh
- Windows : exécution via cmd.exe
La phase finale est également décrite comme étant lancée comme un processus détaché sur Windows. Sur ce système, la chaîne d’infection inclut des actions visant à perturber les mécanismes de supervision.
Windows : perturbation de la surveillance et persistance
Pour la version Windows, la chaîne d’attaque est présentée comme comportant des mesures destinées à interférer avec des composants liés à la télémétrie et à la sécurité. Des références à la gestion Event Tracing for Windows (ETW) et à Antimalware Scan Interface (AMSI) sont mentionnées.
La campagne check ensuite des signaux de sandbox ou d’environnement virtuel. Puis elle met en place une persistance via une clé de registre de type Registry Run et via une tâche planifiée. Enfin, elle télécharge une charge chiffrée indiquée sous la forme /pkg/update_win.exe avant de l’exécuter.
macOS : similarité de la chaîne et persistance via LaunchAgent
Sur macOS, la chaîne d’infection suit un schéma comparable : recherche d’éléments d’analyse (comme des traceurs ou artefacts associés au diagnostic) avant de tenter de récupérer un payload compatible.
Le payload mentionné pour macOS apparaît sous la forme /pkg/beacon_mac.bin récupérée depuis un serveur distant. En cas d’échec, la méthode de DNS TXT décrite plus haut est réutilisée. La persistance est ensuite établie via un LaunchAgent, puis l’exécutable est démarré comme processus détaché.
Linux : ELF compressé et déploiement vers Sliver
Pour Linux, l’exemple analysé est décrit comme un binaire ELF compressé avec UPX. Il est configuré pour télécharger des charges additionnelles à partir d’une URL associée à Cloudflare Workers, puis mène à un déploiement de Sliver.
Sliver est présenté comme un cadre de commande et contrôle open-source. Autrement dit, le résultat de l’attaque n’est pas seulement le chargement d’un code : il ouvre la porte à des opérations de pilotage à distance après compromis.
Un faux SDK de télémétrie pour brouiller l’analyse
Un élément complémentaire a été observé dans les paquets : la présence d’un fichier nommé lib/telemetry.js. Il met en œuvre une logique de télémétrie qui peut ressembler à un SDK de profiling ou de mesure analytique.
Cependant, les analyses indiquent que le point d’entrée du package ne l’importe pas, et qu’il n’expose pas d’infrastructure supplémentaire codée en dur. L’objectif apparent serait de noyer le comportement malveillant dans du bruit visuel, rendant un examen rapide plus trompeur.
Indices sur une cible financière
Les échantillons macOS contiennent des indications de domaines associés, dont tcsbank[.]ru et cloudpayments[.]ru. D’après les observations, cela suggère que la campagne pourrait chercher des cibles liées à des institutions financières russes et à des paiements mobiles.
Le contexte général inclut aussi une piste d’évolution : l’attaque serait possiblement liée à une campagne précédente de type dependency confusion baptisée Moika, observée plus tôt au mois d’avril. Cette campagne visait notamment le vol d’informations sur l’environnement, puis la livraison d’une seconde étape spécifique à l’OS.
Autres campagnes : npm et PyPI, puis extensions Chrome
La découverte s’inscrit dans un contexte plus large. D’autres campagnes visant npm et PyPI ont été documentées : par exemple des paquets capables de télécharger un voleur de cryptomonnaie et un RAT depuis un serveur externe. Dans certains cas, l’URL de téléchargement est construite à partir de code IIFE obfusqué encastré dans une structure JSON.
La même source mentionne également des attaques orientées exfiltration de jetons et identifiants (cloud credentials), du vol de clés de portefeuilles et l’abus de composants comme des mécanismes liés à Telegram, des fichiers secrets (.env), des leurres type fausses pages de CAPTCHA, ou encore le vol de tokens et de secrets associés à des pipelines d’intégration continue.
Au-delà des écosystèmes de paquets, des acteurs auraient aussi utilisé des extensions Google Chrome commercialisées comme outils utiles (simulateurs de jeux, gestionnaires de mots de passe, outils de productivité, inspecteurs CSS, convertisseurs Markdown). Le navigateur devient alors un proxy de crawl : les commandes seraient reçues via une connexion persistante WebSocket.
Selon les éléments rapportés, ces extensions intègrent un SDK de partage de bande passante connecté à un réseau résidentiel tiers. Le scraping passerait par l’injection d’un iframe dans les onglets actifs, la conversion du contenu en Markdown en arrière-plan, puis l’envoi vers un backend cloud.
Que peuvent faire les équipes pour réduire le risque
Face à des paquets npm malveillants capables de déclencher une charge via require(), la défense doit dépasser le seul contrôle des hooks de cycle de vie. Voici des actions concrètes à envisager :
- Limiter les sources : privilégier des registres internes ou des listes blanches lorsque c’est possible.
- Vérifier les dépendances : contrôler les nouveaux packages, surtout ceux dont le nom ressemble à une dépendance connue.
- Surveiller les appels à require() et les flux suspects vers des URL ou des domaines inattendus.
- Renforcer la sécurité du build : builds isolés, exécution dans des environnements confinés, et journalisation.
- Contrôler la persistance et les indicateurs : sur Windows (Run key, tâches planifiées), sur macOS (LaunchAgent) et sur Linux (déploiements C2).
En parallèle, garder un œil sur les signaux contextuels (noms de domaines, méthodes DNS TXT, présence de scripts “télémétrie” non utilisés) peut aider à repérer des variantes.
Conclusion
La campagne décrite montre une fois de plus à quel point l’écosystème npm peut être ciblé : près de 800 paquets npm malveillants visent une compromission multi-plateformes en s’appuyant sur un schéma de téléchargement adaptatif et une exécution finale basée sur des instructions explicitement données dans les README.
Avec un RAT, un infostealer, des méthodes de repli via DNS et des indices de cibles financières possibles, l’affaire mérite une attention immédiate côté sécurité applicative et DevOps. En détectant tôt les dépendances suspectes et en surveillant les comportements lors du build, les équipes réduisent fortement l’exposition à ce type d’attaque supply chain.
Source: https://thehackernews.com/2026/08/nearly-800-malicious-npm-packages.html
