18 paquets npm malveillants déploient un RAT ciblant les développeurs Alibaba

Les faits

Des chercheurs en sécurité de Socket ont publié le 3 août 2026 une analyse détaillée d’une campagne de supply chain ciblant l’écosystème de développement Alibaba. Dix-huit paquets npm malveillants ont été identifiés, publiés sur plusieurs comptes mainteneurs distincts pour disperser les traces et compliquer l’attribution. Ces paquets se faisaient passer pour des dépendances privées du namespace @ali d’Alibaba, un préfixe utilisé en interne par les équipes d’Alibaba pour des bibliothèques propriétaires non publiées sur le registre npm public.

La technique utilisée est une combinaison de dependency confusion et de namespace squatting. Lorsqu’un développeur travaillant dans un environnement Alibaba exécute npm install avec un fichier package.json référençant une dépendance @ali/[nom], et que son client npm est configuré pour consulter d’abord le registre public avant le registre privé interne, il peut installer l’un des paquets malveillants à la place de la bibliothèque légitime attendue. Cette technique, théorisée publiquement par Alex Birsan en 2021, continue de faire des victimes cinq ans plus tard faute de configurations npm sécurisées systématisées.

L’architecture d’attaque repose sur une chaîne de dépendances en couches. Les paquets de premier niveau — les leurres imitant les bibliothèques @ali — ne contiennent aucun code malveillant apparent. Ils se contentent de déclarer des dépendances sur d’autres paquets du même attaquant qui, eux, transportent le downloader et les composants de traitement des commandes du RAT. Cette décomposition vise à contourner les outils d’analyse de code statique qui n’examinent que le paquet installé sans explorer la chaîne de dépendances transitive.

Une fois installé, le RAT s’active via un script postinstall déclenché automatiquement lors de l’installation du paquet. La communication avec le serveur de commande et contrôle (C2) utilise des requêtes HTTP avec des en-têtes falsifiés référençant des services Alibaba légitimes — notamment alidocs.dingtalk.com — pour se fondre dans le trafic réseau normal d’un environnement de développement Alibaba. Cette technique d’obfuscation du C2 par usurpation d’en-têtes de services légitimes est une évolution notable par rapport aux RAT plus anciens utilisant des domaines manifestement suspects.

Les capacités documentées du RAT incluent la reconnaissance système complète (OS, architecture, utilisateurs, processus en cours, réseaux disponibles), la collecte de fichiers ciblés, l’installation de modules supplémentaires à la demande depuis le C2, et l’exécution de code arbitraire sur le système infecté. Le RAT supporte Windows, macOS et Linux — d’où la qualification multiplateforme — ce qui maximise son efficacité dans les environnements de développement hétérogènes typiques des grandes organisations technologiques.

L’élément d’attribution le plus solide publié par Socket concerne les timestamps des commits GitHub associés aux comptes malveillants : tous les commits sont horodatés en UTC+0800, correspondant à l’heure standard de Chine (CST). Les paquets npm malveillants ont été créés les mêmes jours que ces commits. La nature de la cible — Alibaba, acteur technologique majeur — et l’objectif apparent d’espionnage industriel s’inscrivent dans le schéma de compétition économique et technologique documenté par plusieurs groupes de recherche en 2025-2026.

L’historique des paquets révèle une préparation méticuleuse. La version initiale du paquet leurre principal a été publiée en novembre 2023 sans aucune fonctionnalité — une pratique connue sous le nom de sleeping package visant à accumuler du temps d’existence sur le registre pour paraître plus légitime. Trois nouvelles versions avec les charges malveillantes ont ensuite été uploadées en mars et avril 2026, coïncidant avec le début actif de la campagne d’infection.

Les 18 paquets ont été signalés à npm (administré par GitHub/Microsoft) et retirés du registre public. Cependant, tout environnement de développement ayant installé l’un de ces paquets entre la date de publication des versions malveillantes et leur retrait doit être considéré comme potentiellement compromis. Les artefacts du RAT peuvent persister dans node_modules, dans les caches npm locaux, et les scripts postinstall ayant déjà été exécutés peuvent avoir laissé des processus en arrière-plan ou des mécanismes de persistance système.

Impact et exposition

L’exposition est concentrée sur les développeurs travaillant avec l’écosystème Alibaba Cloud, DingTalk et les outils associés au namespace @ali. Elle concerne potentiellement des organisations du monde entier intégrant des SDK ou des bibliothèques de la sphère Alibaba dans leurs pipelines de développement. Dans un contexte où les machines de développement ont souvent accès à des credentials cloud, à des dépôts de code source propriétaires et à des environnements de préproduction ou production, la compromission d’un seul poste développeur via un paquet npm malveillant peut rapidement évoluer en incident de sécurité majeur touchant l’ensemble de l’infrastructure d’une organisation.

Recommandations

• Configurer npm avec un fichier .npmrc forçant la résolution des packages @ali vers un registre privé interne ou vers un scope bloqué sur le registre public (publishConfig, ou proxy Artifactory/Nexus avec règles de blocage).
• Auditer les node_modules de tous les projets pour détecter la présence des paquets malveillants identifiés — la liste complète figure dans le rapport Socket publié le 3 août 2026.
• Analyser les journaux réseau des postes développeurs pour détecter des requêtes sortantes vers des domaines inconnus avec des en-têtes usurpant des services Alibaba.
• Isoler et analyser forensiquement tout poste ayant installé l’un des paquets incrimillés avant leur retrait du registre npm.
• Mettre en place un scan automatique des dépendances en CI/CD via socket.dev, Snyk ou Dependabot pour détecter les paquets suspects dès leur introduction dans la chaîne de build.