Un RAT nord-coréen caché dans 26 paquets npm utilisait Pastebin comme relais

26 paquets npm, publiés en deux jours, et un piège qui se déclenche au moment où tu fais le geste le plus banal du monde: installer une dépendance. Des chercheurs ont remonté une nouvelle itération de la campagne dite Contagious Interview, attribuée à un cluster nord-coréen. Le décor est classique: des faux outils pour développeurs, du typosquatting, et un install script qui fait le sale boulot pendant que tu regardes ton terminal défiler.

Le twist, c’est la façon de planquer le centre de commande. Pas un domaine louche collé en dur dans le code. À la place, les paquets vont lire du contenu Pastebin qui a l’air inoffensif, s’en servent comme « dead drop », décodent des domaines C2, puis vont récupérer des charges utiles différentes selon que tu es sur Windows, macOS ou Linux. Résultat: un enchaînement propre, modulaire, et franchement taillé pour viser des devs.

26 paquets npm publiés fin février, le piège vise tes réflexes

Le lot identifié tourne autour de 26 paquets, publiés sur une fenêtre très courte, du 25 au 26 février 2026. Le point commun, c’est qu’ils se font passer pour des outils de dev ou des bibliothèques qu’on manipule tous les jours. Et c’est ça qui fait mal: la réussite ne dépend pas d’un exploit obscur, mais de ta routine. Tu tapes un nom trop vite, tu copies-colles une commande, tu acceptes une suggestion d’autocomplétion, et c’est parti.

Le mécanisme d’entrée est bête comme chou: un script d’installation, typiquement un fichier « install. js », se lance automatiquement pendant l’installation. Ce script va ensuite exécuter un payload planqué dans un chemin qui sonne « vendor », « scrypt », « version », bref des mots qui n’alertent personne. Dans cette campagne, un fichier revient comme une signature: « vendor/scrypt-js/version. js ». Tu vois le genre: ça ressemble à un bout de dépendance, pas à un loader.

Le truc, c’est que les paquets ne se contentent pas d’être des copies. Ils déclarent aussi, noir sur blanc, une dépendance vers le paquet légitime qu’ils imitent. Sur le papier, ça donne une impression de sérieux: « regardez, on s’appuie sur l’original ». Dans les faits, ça peut brouiller une revue rapide, parce que ton projet finit bien par tirer le vrai paquet. Sauf que le code malveillant, lui, a déjà eu le temps de s’exécuter via le hook d’installation.

Et c’est là que tu comprends pourquoi npm et les registres de paquets restent un terrain de chasse rentable. La barrière d’entrée est faible, la surface d’attaque est immense, et un seul dev piégé peut contaminer une chaîne entière si le paquet se retrouve dans un build, un container, ou un repo partagé. Un RSSI que j’ai eu au téléphone, Marc, résume ça sans détour: « on a mis des années à sécuriser les serveurs, mais on continue d’avaler des dépendances comme des bonbons ».

Pastebin en « dead drop » et stéganographie: le C2 planqué en plein texte

Le cur du montage repose sur Pastebin utilisé comme relais. Les paquets vont récupérer un contenu qui a l’air banal, puis extraire dedans des informations utiles à l’attaquant. Ce n’est pas juste « un lien caché », c’est une logique de dead drop resolver: le malware lit un texte public, y applique une routine de décodage, et en sort une liste de domaines à contacter. Du coup, l’infrastructure peut bouger sans republier les paquets.

Dans cette campagne, le décodage s’appuie sur de la stéganographie au niveau caractère. En gros, l’info est dissimulée dans des substitutions de caractères et dans une extraction à intervalles réguliers. Le décodeur calcule des positions « régulièrement espacées » dans le texte, récupère les caractères à ces positions, et reconstruit les domaines. C’est simple à déployer, pénible à repérer à l’il nu, et ça passe sous le radar de pas mal de contrôles basiques.

Ce que les chercheurs ont vu sortir de ce décodage, c’est un ensemble de domaines C2 hébergés sur Vercel. On parle de 31 déploiements Vercel utilisés comme façade. Là encore, c’est malin dans le mauvais sens: Vercel, c’est une plateforme légitime, très utilisée, et un appel réseau vers un « . vercel. app » peut se confondre avec des tas de requêtes normales d’un environnement de dev. Tu peux filtrer, mais tu risques aussi de casser du trafic légitime.

Un exemple de domaine a été mentionné: « ext-checkdin. vercel[.]app ». Derrière, la logique est orientée livraison: le domaine sert un script shell, qui va ensuite recontacter la même URL pour récupérer un composant de RAT. On est sur une chaîne en plusieurs étages, où chaque étape donne l’impression d’être un petit bout technique. Sauf qu’à la fin, tu as une machine qui exécute des commandes distantes. Et ça, pour un poste de dev, c’est jackpot.

Install. js, version. js, puis payloads Windows/macOS/Linux: la chaîne d’infection

Le scénario type est répétitif, et c’est justement ce qui le rend industrialisable. Étape 1: tu installes le paquet. Étape 2: le hook d’installation lance « install. js ». Étape 3: « install. js » exécute le loader dans « vendor/scrypt-js/version. js ». Ce loader est obfusqué, et il est là pour une chose: préparer la suite sans trop se faire attraper par des règles statiques naïves.

Ensuite, le loader va résoudre le C2 via Pastebin, puis contacter un domaine décodé pour récupérer un payload adapté à ton OS. Windows, macOS, Linux, tout le monde est servi. C’est cohérent avec ce qui est observé dans Contagious Interview: on vise des développeurs, et les développeurs bossent sur tout. Un MacBook pour le quotidien, un Linux pour les CI, une VM Windows pour tester, parfois les trois dans la même équipe.

Un point concret relevé dans l’analyse: un domaine Vercel peut servir un script shell, puis ce script retélécharge derrière un composant de RAT. Les outils de récupération mentionnés côté shell, c’est le duo classique « curl/wget ». Et après, tu peux avoir un bootstrapper protégé par jeton, histoire de limiter l’analyse opportuniste et de ne livrer la suite qu’aux cibles qui passent certains critères. C’est du contrôle d’accès, mais côté malware.

Dans une simulation de machine compromise, les chercheurs ont pu observer un ensemble post-exploitation plus large: un RAT, plus un voleur d’informations modulaire. Dans un cas documenté, un composant « parser. js » se connecte à une adresse IP « 103[.]106[.]67[.]63 » sur le port 1244, avec aussi un canal WebSocket sur 1247. Le trafic mélange HTTP et WebSocket, et c’est typiquement le genre de combinaison qui se fond dans une journée normale de dev si tu ne journalises pas sérieusement.

Vercel, IP brute, WebSocket: une infra hybride qui brouille les pistes

Ce qui ressort, c’est une infra en deux couches. D’un côté, des domaines sur une plateforme reconnue, Vercel, déployés en série. De l’autre, des points d’ancrage plus « bruts », comme des adresses IP sur des hébergeurs classiques. Cette hybridation sert deux objectifs: rendre le premier contact « propre » et résilient, puis basculer vers des endpoints plus contrôlés pour la commande et l’exfiltration. C’est une recette qu’on voit revenir souvent.

Les chercheurs parlent de 31 déploiements Vercel. Ce chiffre compte, parce qu’il montre la redondance. Si tu fais tomber un domaine, il en reste 30. Si tu bloques un pattern, ils changent le texte Pastebin et tu repars pour un tour. Et si tu te dis « je bloque Vercel », bon courage: dans plein d’équipes, Vercel fait partie de la stack, ou au moins des tests. Le défenseur se retrouve à choisir entre sécurité et continuité.

La partie communication C2 s’appuie sur des protocoles web: HTTP, HTTPS, WebSocket. Rien d’exotique. Et c’est exactement ce qui rend l’affaire pénible à trier. Dans un environnement de dev, les sorties réseau sont nombreuses: registry, CI, APIs, dashboards, logs, tickets, dépôts Git, monitoring. Un attaquant qui se cale sur des URIs qui sonnent « tech » et des endpoints qui ressemblent à des API peut se fondre dans le bruit, surtout si l’entreprise n’a pas d’egress filtering sérieux.

Il y a quand même un revers de médaille côté attaquants, et c’est là qu’il faut nuancer. Plus tu utilises des plateformes légitimes, plus tu dépends de leur capacité à réagir. Un déploiement Vercel peut être signalé, suspendu, corrélé. Pareil pour Pastebin, qui peut supprimer un contenu. Le modèle est résilient, mais pas invincible. Le problème, c’est le timing: entre la publication, l’installation, et la détection, quelques minutes suffisent. Et dans cette campagne, des systèmes de détection ont justement repéré les paquets très vite.

Pourquoi les devs sont ciblés: secrets, wallets, CI et effet domino supply chain

Le choix des cibles n’a rien de romantique. Un poste de dev, c’est un coffre-fort ambulant. Tu y trouves des tokens, des clés d’API, des accès cloud, des secrets de CI, des identifiants de registries, parfois des clés SSH réutilisées, et des bouts de config qui ouvrent des portes. Dans les analyses de cette campagne, on parle d’un infostealer à plusieurs modules, jusqu’à neuf modules, orienté collecte d’artefacts développeurs et de secrets. C’est chirurgical.

Et il y a l’effet domino. Tu compromises un dev, tu peux toucher un dépôt, puis une pipeline, puis une image de build, puis une release. Les attaques supply chain adorent ça. Dans d’autres vagues attribuées aux mêmes acteurs, on a déjà vu des paquets malveillants imiter des dépendances très communes dans l’écosystème Node, y compris des noms proches de bibliothèques utilisées dans Express, ou des libs liées à la crypto et au Web3. Le but est simple: se glisser dans les habitudes des équipes qui ship vite.

La dimension « recrutement » joue aussi un rôle dans ce type de campagne, via de l’ingénierie sociale autour d’entretiens techniques. Le schéma Contagious Interview est connu pour appâter des profils dev, souvent via des échanges qui ressemblent à du process RH, puis pousser vers un test, un projet, une dépendance, un repo. Là, on parle d’une diffusion via npm, mais l’idée reste la même: toucher des gens qui ont les clés du royaume, pas juste des utilisateurs finaux.

Concrètement, tu fais quoi lundi matin si tu gères une équipe? D’abord, tu audites tes dépendances et tu traques les scripts d’installation inattendus, surtout « postinstall » et les fichiers qui se lancent à l’installation. Tu bloques les installs depuis des machines sensibles sans proxy ni contrôle, tu actives des alertes sur les nouveaux paquets, tu imposes des lockfiles, et tu fais tourner des outils qui détectent le typosquatting et les comportements d’obfuscation. Et si tu te dis « on est trop petits pour intéresser la Corée du Nord », Marc m’a lâché une phrase qui pique: « ils ne te visent pas toi, ils visent ce que tu touches ».