Amazon indique avoir établi un lien entre plusieurs attaques NPM de grande ampleur et des hackers associés à la Corée du Nord. Les incidents visent l’écosystème Node Package Manager, où des bibliothèques open source sont largement réutilisées dans des applications cloud comme sur des postes de développement.
Dans son analyse, l’entreprise relie les compromis de plusieurs projets — dont typo-crypto, debug, chalk et axios — à un acteur de menace baptisé Sapphire Sleet, aussi connu sous des noms tels que BlueNoroff et Stardust Chollima.
De multiples bibliothèques touchées, un même acteur suspecté
Le fil conducteur mis en avant par Amazon repose sur les techniques et tactiques observées pendant les campagnes, ainsi que sur les éléments liés aux infrastructures de command-and-control (C2) et sur des similitudes dans la manière d’opérer.
Amazon précise toutefois que l’attribution à Sapphire Sleet reste à confiance moyenne. Autrement dit, le rapprochement s’appuie sur des signaux concordants, mais pas sur une certitude absolue.
Chronologie : d’abord une piste, puis une escalade
Selon Amazon, l’activité initiale remonte à mars 2025, lorsque le paquet typo-crypto aurait été trojanisé. L’entreprise estime que ce premier événement aurait servi de terrain d’essai avant l’extension du dispositif.
En septembre 2025, l’attaque aurait pris de l’ampleur avec la compromission des bibliothèques debug et chalk, deux packages très utilisés. Amazon estime que cette vague aurait concerné jusqu’à 10% des environnements cloud en l’espace de deux heures, signe de l’impact potentiel d’une modification malveillante distribuée automatiquement.
Enfin, en mars 2026, les chercheurs indiquent que l’acteur aurait ciblé axios, un des packages les plus populaires de l’écosystème npm, avec plus de 100 millions de téléchargements hebdomadaires.
Axios déjà attribué ailleurs : pourquoi Amazon relie aussi l’incident
Amazon rappelle qu’une attribution publique de l’incident axios a déjà été faite vers des acteurs liés à la DPRK. Malgré cela, l’entreprise explique avoir connecté cet événement aux compromis antérieurs de paquets, sur la base de la convergence des indices techniques et opérationnels.
Cette approche vise à montrer qu’il ne s’agit pas seulement d’incidents isolés, mais possiblement d’une stratégie plus large s’appuyant sur la même grammaire d’attaque.
Comment les mises à jour malveillantes se propagent
D’après Amazon, l’accès aurait été obtenu par ingénierie sociale ciblant des mainteneurs de paquets. Une fois l’accès acquis, l’attaquant aurait publié des mises à jour malveillantes, automatiquement distribuées aux utilisateurs qui installent ou mettent à jour les dépendances.
Ce mode opératoire est redoutable : les développeurs ne téléchargent pas toujours le code directement à partir d’un endroit “suspect”, mais s’appuient sur des mécanismes d’installation standard, ce qui rend la détection plus difficile lorsque le contenu semble plausible.
Des tendances qui rendent la détection plus complexe
Amazon met en avant plusieurs tendances observées dans les attaques NPM récentes. L’idée n’est pas seulement de compromettre un package, mais d’augmenter la probabilité que la charge utile passe sous les radars.
- Fonctionnalités malveillantes réparties : l’attaque peut être divisée entre plusieurs paquets apparemment bénins, rendant l’analyse isolée moins concluante.
- Confiance patiemment construite : des acteurs peuvent prendre des mois pour contribuer à des projets légitimes ou maintenir une présence crédible, avant d’insérer du code nuisible.
- Comportement découplé du contenu : le code malveillant peut dépendre d’éléments externes, comme des scripts, des fichiers de configuration ou des serveurs exploitables plus tard.
- Chiffrement renforcé et payloads en plusieurs étapes : des clés peuvent être récupérées à l’exécution ou via des mécanismes distants, ce qui complique l’analyse statique.
- Exécution dépendante de l’environnement : la charge utile peut attendre de détecter une configuration réelle de production ou de développement, afin d’éviter les bacs à sable d’analyse.
- Slopsquatting alimenté par l’IA : des noms de paquets inspirés d’erreurs ou de “faux jumeaux” peuvent être enregistrés, avec l’espoir qu’ils soient installés par des développeurs ou par des agents de codage autonomes.
Amazon ajoute que certaines de ces techniques seraient accélérées et simplifiées par l’IA : génération de code, production de documentation et même création d’identités de mainteneurs plus crédibles.
Protection : signaler, collaborer et réduire le risque
Face à ces dangers, Amazon décrit une réponse à plusieurs niveaux. L’entreprise indique notamment avoir rapporté ses constatations et son renseignement à la communauté, tout en collaborant avec des acteurs de l’industrie comme OpenSSF.
Amazon annonce également un investissement de 12,5 millions de dollars dans l’initiative Akrites, visant à protéger les logiciels open source contre des attaques rendues plus accessibles par l’IA.
Tester avant que l’attaque ne “passe”
Au-delà de l’analyse des incidents, l’enjeu concerne la capacité de détection. Amazon évoque un constat préoccupant : une proportion importante des attaques “réussies” franchit l’environnement sans être repérée.
L’idée est simple : si les règles SIEM/EDR et les procédures internes ne sont jamais éprouvées, certaines menaces peuvent traverser les mailles du filet. Les tests de simulation permettent de vérifier que les signaux attendus déclenchent bien des alertes et que l’organisation ne dépend pas uniquement du hasard ou de la réactivité.
Dans cette logique, la meilleure défense consiste à multiplier les contrôles, à tester leur efficacité et à limiter les risques dès la chaîne de dépendances.
Conclusion : des attaques NPM de plus en plus organisées
En reliant plusieurs compromissions de bibliothèques npm à un acteur associé à la Corée du Nord, Amazon met en lumière la réalité des attaques NPM actuelles : elles combinent ingénierie sociale, mises à jour trojanisées et techniques visant à réduire la visibilité lors de l’analyse.
Si l’attribution reste à confiance moyenne, les signaux décrits — chronologie, similitudes et infrastructures — renforcent l’idée qu’une stratégie cohérente est à l’œuvre. Pour les équipes de sécurité et les développeurs, le message est clair : il faut renforcer les pratiques de contrôle des dépendances, surveiller plus finement et tester la détection avant qu’un code malveillant ne se diffuse à grande échelle.
