Après le piratage d’Axios, Google remonte la piste d’un groupe de cybercriminels nord-coréens




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.


Les attaquants ont d’abord publié une version saine de "plain-crypto-js", sans doute pour crédibiliser le paquet avant d’en déployer une version malveillante. ©



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.