Derrière la compromission d’Axios, le GTIG fait état d’une opération structurée, reposant sur une évolution du malware WAVESHAPER et sur un mode opératoire déjà observé dans d’autres campagnes attribuées au même acteur.
L’alerte publiée hier, le 31 mars, suffisait déjà à mesurer la gravité de l’incident. Deux versions d’Axios, bibliothèque JavaScript omniprésente dans les projets web, avaient été piégées sur npm pour déployer un cheval de Troie sur Windows, macOS et Linux. Dans les heures qui ont suivi, l’affaire a gagné en netteté. Les équipes du Google Threat Intelligence Group attribuent désormais l’attaque à UNC1069, un groupe nord-coréen actif depuis au moins 2018 et déjà associé à des opérations dirigées contre l’écosystème crypto et la finance décentralisée. Ce qui ressemblait à une compromission particulièrement habile apparaît donc de plus en plus comme une campagne mûrement préparée, pensée pour toucher des environnements de développement à grande échelle.
Une nouvelle version de WAVESHAPER au cœur d’une attaque soigneusement préparée
En marge de l’attribution elle-même, Google estime aussi que la charge finale déployée via Axios, baptisée WAVESHAPER. V2, constitue une évolution directe de WAVESHAPER, une porte dérobée déjà associée à UNC1069 dans des attaques antérieures. Le GTIG relève plusieurs points communs très précis, à commencer par la manière dont le malware communique avec son serveur de commande, sa façon de le recontacter à intervalles réguliers pour récupérer d’éventuelles instructions, l’usage d’un identifiant réseau inhabituel pour se présenter aux serveurs distants, ainsi que le recours aux mêmes répertoires temporaires sur les machines compromises.
Sur le fond, cette évolution de WAVESHAPER confirme surtout le degré de maturité de l’attaque. La chaîne d’infection observée via Axios reposait sur l’ajout d’une dépendance externe appelée plain-crypto-js, d’abord publiée dans une version saine pour lui donner une apparence légitime, avant d’être remplacée par une version malveillante, chargée d’exécuter un script d’installation dissimulé. Ce script, SILKBELL, a ensuite servi de dropper pour récupérer une charge utile adaptée au système d’exploitation détecté. Les chercheurs décrivent ainsi une opération pensée pour fonctionner sur macOS, Windows et Linux à partir d’un même point d’entrée, avec des variantes capables d’exécuter des commandes, de parcourir l’arborescence de fichiers, d’injecter d’autres binaires et de dialoguer régulièrement avec l’infrastructure de commande.
Autre élément important, l’attaque a été brève mais très structurée. Les versions piégées d’Axios ont été publiées à peu d’intervalle sur deux branches. Tout indique aussi que le dispositif a été pensé pour masquer l’infection après son déclenchement. Le script chargé de récupérer le malware a tenté de s’auto-supprimer, tandis que les fichiers de configuration modifiés pendant l’attaque ont été remplacés par des versions nettoyées, moins susceptibles d’éveiller les soupçons. De quoi compliquer sensiblement l’analyse après coup.
Ce qu’il faut vérifier sans attendre
Pour les développeurs et les équipes de sécurité, l’attribution à UNC1069 ne change pas la marche à suivre de base, mais elle renforce le niveau d’urgence. La première étape consiste à vérifier si les environnements concernés ont installé les versions compromises d’Axios, à savoir 1.14.1 et 0.30.4, ainsi que la dépendance plain-crypto-js, notamment dans ses versions 4.2.0 et 4.2.1. Si ces éléments apparaissent dans l’arbre de dépendances, il faut rétrograder immédiatement vers une version saine, verrouiller explicitement cette version dans les fichiers de dépendances et suspendre les déploiements qui permettraient toute remontée involontaire lors des prochains builds.
Il faut ensuite passer à la vérification des artefacts laissés sur les postes potentiellement touchés. Les analyses publiques décrivent des comportements différents selon le système d’exploitation, avec des charges utiles spécifiques pour macOS, Windows et Linux. Même en l’absence de persistance documentée dans certaines branches, il serait imprudent de conclure trop vite à un risque limité. Un RAT de ce type peut suffire à exfiltrer des secrets, lancer une seconde charge ou ouvrir une fenêtre d’accès courte mais suffisante pour compromettre un environnement de développement.
Par conséquent, le renouvellement des secrets n’est pas une précaution accessoire. Les tokens npm, identifiants GitHub, clés d’API, secrets cloud, certificats et variables sensibles exposés sur les machines ayant installé les versions piégées doivent être considérés comme potentiellement compromis.
Les équipes doivent aussi bloquer l’infrastructure de commande identifiée par les chercheurs, isoler les systèmes suspects du réseau, interrompre les processus malveillants détectés, conserver les éléments utiles à l’investigation avant restauration ou nettoyage complet, puis purger les caches npm, yarn et pnpm afin d’éviter une nouvelle contamination lors des prochaines installations.
Une attaque de la chaîne d’approvisionnement consiste à compromettre un maillon “en amont” (un paquet npm, une dépendance, un compte de mainteneur) pour toucher automatiquement un grand nombre de projets qui l’installent. npm est particulièrement exposé car l’installation de dépendances peut déclencher des scripts (postinstall, preinstall) capables d’exécuter du code sur la machine du développeur ou sur un serveur de build. Axios étant une bibliothèque très répandue, une version piégée peut se diffuser vite et atteindre des environnements variés (postes dev, CI/CD, conteneurs). Le risque principal n’est pas seulement l’infection d’un poste, mais la compromission d’identifiants et de secrets qui donnent accès à des dépôts, registries ou environnements cloud.
À quoi sert un “dropper” comme SILKBELL, et en quoi une charge utile multi-OS complique la défense ?Un dropper est un composant intermédiaire dont le rôle est de récupérer, déposer et lancer la charge finale (malware) en limitant son exposition initiale. Il peut adapter l’infection à l’environnement détecté (Windows, macOS, Linux), ce qui augmente les chances de réussite dans des parcs hétérogènes. Cette approche permet aussi de modifier rapidement la charge finale sans republier tout le mécanisme, et de contourner certaines détections basées sur des signatures. En pratique, un seul point d’entrée (ici une dépendance npm) suffit à déployer des binaires différents selon l’OS, ce qui complique l’analyse et la réponse à incident.
Que signifient C2 (commande et contrôle) et “RAT”, et pourquoi le renouvellement des secrets est indispensable après une compromission ?Un serveur C2 (commande et contrôle) est l’infrastructure distante que contacte le malware pour recevoir des ordres et renvoyer des informations, souvent par “beaconing” (reconnexion périodique). Un RAT (Remote Access Trojan) est un cheval de Troie d’accès à distance qui peut exécuter des commandes, explorer des fichiers, déposer d’autres outils ou exfiltrer des données. Sur un poste de développement, la cible la plus rentable est souvent l’accès indirect : tokens npm, identifiants Git, clés d’API, secrets cloud, certificats et variables d’environnement. Même si l’infection semble brève, quelques minutes peuvent suffire à voler ces secrets, d’où la nécessité de les révoquer/renouveler et de revoir les accès associés.
