La Corée du Nord derrière les attaques npm sur debug, chalk et axios : l’attribution d’Amazon

Introduction

Le 29 juillet 2026, Amazon Threat Intelligence a attribué avec un niveau de confiance moyen au groupe nord-coréen Sapphire Sleet (aussi suivi sous les noms UNC1069 ou BlueNoroff) la compromission de certains des paquets npm les plus répandus au monde. L’enquête relie pour la première fois sous une unique orchestration trois campagnes qui, en l’espace de douze mois, ont touché debug et chalk en septembre 2025, axios en mars 2026 et la publication malveillante du paquet typo‑crypto en mars 2025.
Les analyses précédentes d’Aikido et Wiz n’avaient pas identifié d’acteur spécifique : désormais le tableau se complète, décrivant une menace persistante et financièrement motivée contre la chaîne d’approvisionnement du logiciel open‑source.

Analyse technique

Les trois campagnes comparées

Les opérations montrent des techniques d’attaque différentes, symptôme d’un adversaire capable de s’adapter aux contrôles de sécurité.

• debug et chalk (septembre 2025) : les attaquants ont compromis les comptes des mainteneurs par ingénierie sociale et publié des mises à jour infectées. Le code malveillant injecté – un script exécuté côté navigateur – n’utilisait pas de hook npm comme postinstall, mais s’activait directement lorsque les applications web chargeaient les paquets. En intercepant fetch, XMLHttpRequest et les API des portefeuilles de cryptomonnaies, le script modifiait silencieusement les adresses de transaction (wallet drainer), sans installer de persistance sur l’appareil.
• typo‑crypto (31 mars 2025) : un faux paquet imitant crypto‑js (typosquatting) publié comme paquet original, non issu d’un mainteneur compromis. Il contenait un déclencheur offusqué (XOR avec la clé 01042025) qui ne s’activait que dans des conditions spécifiques, probablement un banc d’essai pour perfectionner les techniques.
• axios et Mastra (mars 2026) : l’accès aux mainteneurs a permis d’insérer des scripts de cycle de vie (postinstall) qui distribuaient une porte dérobée (WAVESHAPER.V2) pour le vol d’identifiants et le mouvement latéral dans les environnements de développement.

Les preuves et les divergences

Les preuves publiques fournies par Amazon – réutilisation de code et infrastructures C2 partagées (npmjs[.]store, IP 216.74.123.126) – ne détaillent cependant pas le lien exact entre les campagnes. Quelques divergences émergent : le hash SHA256 indiqué pour core.js ne correspond à aucun fichier dans l’archive de typo‑crypto et le paquet semble être une opération de typosquatting originale, non un mainteneur compromis.
Google et Microsoft avaient déjà attribué l’attaque sur axios au même acteur, mais aucun autre éditeur n’a publiquement confirmé le lien pour debug, chalk et typo‑crypto. Aikido affirme avoir relié les incidents depuis longtemps grâce à des chevauchements de C2 entre axios et Mastra.

La réponse de la plateforme

npm v12 (publié le 8 juillet 2026) désactive par défaut les scripts de cycle de vie des dépendances, supprimant le vecteur postinstall exploité par axios. Cependant, il ne protège pas contre les attaques comme celle sur debug et chalk, où le code malveillant était distribué directement dans le paquet et exécuté par les applications sans avoir besoin de hooks d’installation.

Impact

Les paquets concernés totalisaient plus de 2 milliards de téléchargements hebdomadaires. Le gain immédiat documenté n’est que de 600 USD (source Socket), mais le risque systémique est énorme et toujours d’actualité.

• Utilisateurs finaux : le script dans debug/chalk interceptait les transactions crypto dans le navigateur, redirigeant les fonds sans laisser de traces sur l’appareil.
• Développeurs : la porte dérobée dans axios permettait l’accès à des identifiants et environnements d’entreprise, exposant les réseaux et dépôts internes.
• Écosystème : la compromission de mainteneurs de confiance et l’utilisation d’un faux paquet comme test démontrent une planification sophistiquée et une menace concrète pour la chaîne d’approvisionnement, exploitant la confiance accordée aux mainteneurs open‑source.

Atténuation

• Mettre à jour npm vers la dernière version (v12) pour bloquer les scripts de cycle de vie ; malheureusement cela ne suffit pas pour les attaques in‑code comme celles observées.
• Protéger les comptes mainteneurs : imposer l’authentification à deux facteurs (2FA), surveiller les accès anormaux et examiner chaque mise à jour suspecte sont des contre-mesures indispensables.
• Détecter les indicateurs de compromission : rechercher dans ses environnements le domaine npmjs[.]store, l’IP 216.74.123.126 et le fichier core.js. Dans les applications web, vérifier d’éventuels hooks anormaux sur fetch, XMLHttpRequest et les API de portefeuille.
• Vérifier l’intégrité des paquets : comparer les hash avec ceux déclarés et se méfier des paquets où l’auteur diffère du compte de publication (cas typo‑crypto).
• Supprimer les dépendances non maintenues et consulter des avis comme OSV MAL‑2026‑3400 pour typo‑[email protected].
• Adopter des outils d’analyse (par ex. Socket) pour surveiller en continu les dépendances.

FAQ

1. Qui est Sapphire Sleet et pourquoi cible-t-il npm ?

Sapphire Sleet (UNC1069, BlueNoroff, STARDUST CHOLLIMA) est un groupe nord-coréen spécialisé dans les attaques financières. Il a ciblé des banques et des plateformes d’échange de cryptomonnaies ; il a aujourd’hui étendu ses opérations à la chaîne d’approvisionnement logicielle pour distribuer du code malveillant à grande échelle, visant le vol de cryptomonnaies ou l’accès à des réseaux d’entreprise. npm, avec ses millions de développeurs, est un vecteur idéal.

2. Comment puis-je vérifier si j’ai été touché ?

Si votre application utilisait des versions compromises de debug, chalk ou axios, inspectez les bundles côté client à la recherche de scripts qui interceptent fetch ou XMLHttpRequest. Pour axios, vérifiez les logs réseau vers les indicateurs C2 (npmjs[.]store, 216.74.123.126) et vérifiez l’intégrité des paquets avec des hash et des outils d’audit. La présence du fichier core.js est un signal d’alarme.

3. Pourquoi npm v12 n’est-il pas suffisant pour bloquer ces attaques ?

npm v12 neutralise les scripts de cycle de vie (ex. postinstall), le vecteur utilisé par axios. Cependant, les attaques sur debug et chalk injectaient du code directement dans les fichiers JavaScript du paquet, exécutable sans avoir besoin de hooks d’installation. Par conséquent, la protection nécessite des pratiques de développement sécurisé, des vérifications d’intégrité et une surveillance continue des dépendances, pas seulement des mises à jour de la plateforme.