Mise à jour : 3 avril 2026 - ajout d'informations sur la manière dont le compte a été initialement piraté.
--
Lorsqu'un paquet largement utilisé est compromis, la plupart des équipes suivent une procédure bien connue : elles examinent les différences, identifient la version malveillante et vérifient si celle-ci a été intégrée à leur environnement. Cette réaction est nécessaire, mais elle ne résout qu'une partie du problème.
Axios est un client HTTP largement utilisé dans l'écosystème npm. Elle est profondément intégrée dans les piles d'applications modernes, présente dans les outils de développement, les services backend, les frameworks frontend et les pipelines d'intégration continue. Les installations ne se font pas en un seul endroit ; elles s'effectuent en continu sur les postes de travail, les systèmes de compilation et les environnements de production. Dans de nombreux cas, les nouvelles dépendances sont résolues automatiquement lors des déploiements ou des opérations de mise à l'échelle, ce qui signifie qu'une version compromise peut se propager bien au-delà des machines des développeurs.
Pendant la période d'exposition, tout environnement utilisant les versions concernées a exécuté du code contrôlé par l'attaquant. C'est cet aspect qui doit déterminer la réponse à apporter. Le problème ne réside pas dans le numéro de version ni dans les différences de dépendances, mais dans le fait que du code non fiable s'est exécuté au sein de systèmes disposant déjà d'un accès privilégié.
Ce qui s'est réellement passé
Le compte d'un responsable de maintenance d'Axios a été piraté, ce qui a permis la publication de versions malveillantes et leur association à des balises, de sorte que les installations standard se connectaient à celles-ci.
Les informations fournies par la suite par le responsable du projet indiquent qu'il s'agissait d'une opération d'ingénierie sociale ciblée plutôt que d'une simple fuite d'identifiants. L'attaquant s'est fait passer pour une entreprise légitime, a créé un espace de travail Slack convaincant en clonant l'identité visuelle et les profils d'ingénieurs connus, puis a organisé une réunion en direct via Microsoft Teams. Au cours de cette interaction, le responsable du projet a été invité à installer ce qui semblait être une mise à jour de routine, mais qui, en réalité, a déployé le malware pour accéder à son environnement.
À partir de là, le pirate a profité de cet accès pour publier directement sur npm des versions d'Axios contenant une porte dérobée, contournant ainsi le processus de publication habituel du projet.
Le changement en lui-même était minime. Une seule dépendance, plain-crypto-js, a été ajoutée au paquet, mais elle n’a jamais été référencée nulle part dans le code, car cela n’était pas nécessaire. Son but était l’exécution, et non la fonctionnalité.
Cette dépendance a entraîné une post-installation hook, qui s'exécutait automatiquement pendant le fonctionnement normal npm install processus. Il n'y a eu ni message d'invite, ni avertissement, ni aucun signe indiquant qu'un problème était survenu. Au lieu de contenir la charge utile finale, le script a servi de compte-gouttes.
Dès son exécution, le programme a établi une connexion avec une infrastructure contrôlée par les pirates et a envoyé une requête conçue pour ressembler à un trafic normal lié à npm. Le corps de la requête imitait une communication légitime avec le registre, mais la destination était externe. La réponse fournissait une charge utile plateforme, adaptée à macOS, Windows ou Linux, qui était ensuite enregistrée sur le disque et exécutée en arrière-plan.
À ce stade, l'objectif était déjà atteint. Un outil d'accès à distance était en cours d'exécution sur le système, indépendamment du processus d'installation.
Le dropper a ensuite effacé ses propres traces. Le script d'installation a été supprimé et les métadonnées du paquet ont été réécrites pour paraître intactes. Quiconque aurait examiné les dépendances par la suite n'aurait rien remarqué de manifestement malveillant. L'installation aurait semblé légitime, même si la charge utile avait déjà été exécutée.
Ce qui rend cet incident d'autant plus significatif, c'est qu'il ne reposait pas sur une configuration manifestement vulnérable. Le responsable de la maintenance avait mis en place une authentification multifactorielle et avait commencé à s'orienter vers une publication sécurisée via OIDC. Cependant, les anciens canaux de publication reposaient toujours sur des jetons npm à longue durée de vie, qui, de par leur conception, contournent l'authentification multifactorielle.
C'est cette coexistence qui a créé la faille. Le contrôle renforcé était bien en place, mais n'était pas appliqué de bout en bout. L'attaquant n'avait pas besoin de perturber le processus de publication prévu. Il lui suffisait d'emprunter la voie qui restait accessible.
Les premières discussions entre le responsable du projet et la communauté ont rapidement abouti à la même conclusion : des contrôles rigoureux étaient en place, mais les anciens mécanismes d'authentification continuaient de présenter des failles de sécurité.
, commentaire de l'utilisateur Riteshkew sur GitHub
C'est le schéma qui se répète dans tous les incidents liés à la chaîne d'approvisionnement. La compromission s'effectue par le biais de l'identité, la charge utile est acheminée via un canal de distribution de confiance, et l'exécution se fond dans le comportement normal. Lorsque le changement est détecté, le code s'est déjà exécuté.
Source : StepSecurity
Les requêtes sortantes présentées ici sont dirigées vers une infrastructure contrôlée par l'attaquant, et non vers le registre npm. Le corps de la requête imite le trafic lié à npm, ce qui permet à l'activité de se fondre dans les flux de travail de développement normaux tout en récupérant la charge utile de deuxième étape.
Pourquoi cela s'intègre naturellement dans les processus habituels
Les paquets malveillants ne sont pas un phénomène nouveau, mais cette affaire se distingue par la façon dont elle s'intègre parfaitement aux processus de développement habituels et par la manière dont elle combine un accès ciblé à une large diffusion.
Comme nous l'avons vu précédemment, l'exploit en lui-même détermine rarement l'issue. Ce qui importe, c'est ce qui se passe après l'exécution du code au sein de l'environnement.
Plusieurs facteurs font que cet incident a des conséquences plus graves que les atteintes habituelles à la chaîne d'approvisionnement.
Axios est largement utilisé, ce qui étend la portée potentielle de la faille bien au-delà d'une simple application ou d'une seule équipe. La vulnérabilité ne se limitait pas aux organisations qui en dépendaient explicitement. Tout paquet, workflow de compilation ou tâche d'intégration continue ayant fait appel à Axios de manière transitive pendant la période concernée aurait pu récupérer la version malveillante, rendant difficile l'évaluation rapide de l'ampleur totale de l'impact.
L'exécution a été immédiate. La charge utile s'est exécutée quelques secondes seulement après son installation, souvent via des pipelines automatisés. Huntress a détecté la première endpoint connue endpoint à peine 89 secondes après la publication de la version malveillante, ce qui témoigne de la rapidité avec laquelle les environnements de développement modernes résolvent et exécutent les nouvelles dépendances.
Parallèlement, l'attaquant a pris des mesures pour réduire au minimum toute trace de son intervention. Le programme d'installation s'est désinstallé de lui-même, les métadonnées du paquet ont été réécrites, et les vérifications effectuées après coup ne laissaient rien présager d'anormal. La modification elle-même était précise : une dépendance ajoutée, aucune modification fonctionnelle, et aucun signe évident à moins d'examiner attentivement le fichier concerné.
Ce qui distingue également cette affaire, c'est la manière dont elle a débuté. La faille ne provenait pas de l'écosystème des paquets lui-même, mais d'une campagne d'ingénierie sociale ciblée contre le responsable de maintenance. En misant sur la confiance plutôt qu'en exploitant une faille technique, l'attaquant a contourné des contrôles tels que l'authentification multifactorielle (MFA) et a obtenu un accès direct au processus de publication.
C'est cette combinaison entre l'usurpation ciblée d'identité et la contamination de la chaîne logistique des logiciels qui rend ce type d'attaque difficile à anticiper et encore plus difficile à contenir.
De l'installation d'un paquet à la divulgation des identifiants
L'installation n'est qu'un point d'entrée. Une fois que le dropper s'exécute, il hérite des autorisations et des droits d'accès du système sur lequel il s'exécute.
Dans la pratique, cela concerne souvent les jetons GitHub, les jetons npm, cloud , les secrets CI/CD, les clés API et les données SSH. Aucun de ces éléments n'a besoin d'être piraté, car ils sont déjà disponibles au sein d'environnements de confiance, tels que les postes de travail des développeurs et les pipelines de compilation.
À ce stade, l'attaquant ne dépend plus du paquet lui-même. L'attention se porte désormais sur ce à quoi ces systèmes ont accès et sur la manière dont cet accès peut être exploité.
Nous avons déjà vu comment ce schéma se déroule. Dans le cas de Shai-Hulud, l'attaque est rapidement passée de l'exécution à la collecte et à la réutilisation d'identifiants, se propageant à travers les référentiels et les pipelines en tirant parti des relations de confiance existantes.
Le paquet sert de vecteur de diffusion. Le risque réside dans ce que cette diffusion permet.
Ce schéma ne se limite pas aux paquets npm. Lors du récent incident de chaîne d'approvisionnement chez Trivy, les attaquants ont utilisé des outils CI/CD compromis pour exécuter du code directement au sein des pipelines de compilation, récoltant ainsi à grande échelle cloud , des secrets Kubernetes et des jetons API. Un point d'entrée différent, mais le même résultat : une exécution au sein d'un environnement de confiance, suivie d'un accès immédiat à tout ce que cet environnement peut atteindre.
Le manque de visibilité après l'installation
C'est là que la plupart des organisations perdent leur clarté.
Il est relativement simple de vérifier si une version malveillante figure dans un fichier de verrouillage, mais cela ne permet pas de déterminer où le code a effectivement été exécuté. Les journaux de compilation enregistrent rarement le comportement des processus d'arrière-plan détachés, et les machines des développeurs fonctionnent souvent en dehors du même niveau de surveillance que celui appliqué aux systèmes de production.
Au moment où la dépendance malveillante est identifiée et supprimée, l'exécution initiale a déjà eu lieu, laissant les équipes avec peu d'éléments de preuve et de nombreuses questions sans réponse.
La charge utile a-t-elle accédé aux identifiants d'accès ?
Ces identifiants ont-ils été réutilisés ?
Cette activité s'est-elle étendue aux environnements cloud SaaS ?
Dans de nombreux cas, il n'existe pas de moyen définitif de répondre à ces questions en se contentant des outils traditionnels.
Une méthode pratique pour vérifier l'exposition
Pour les équipes qui cherchent à passer d'une situation où « nous pourrions être touchés » à une action concrète, l'un des indicateurs les plus rapides à vérifier est la communication externe.
Nous avons publié une chasse au trésor spéciale de 5 minutes dans le Vectra AI plateforme afin d'identifier les systèmes susceptibles d'avoir exécuté la charge utile malveillante axios en recherchant toute communication avec l'infrastructure de l'attaquant.
Cette opération de recherche se concentre sur un petit ensemble d'indicateurs hautement fiables liés à la campagne, notamment le domaine de commandement et de contrôle sfrclak.com et l'adresse IP correspondante 142.11.206.73. Tout système ayant communiqué avec cette infrastructure pendant ou après la période d'exposition doit être considéré comme suspect.
La requête fait apparaître les sessions réseau impliquant ce domaine ou cette adresse IP, ainsi que les hôtes source et destination, le protocole et la fréquence des connexions. Dans la pratique, les analystes doivent prêter attention aux systèmes qui présentent des connexions répétées ou automatisées, ou aux hôtes qui n'ont jamais communiqué auparavant avec une infrastructure externe similaire.
À partir de là, l'enquête peut avancer rapidement. Passez à la télémétrie DNS, HTTP et SSL pour évaluer l'étendue des communications, puis établissez des corrélations avec endpoint afin d'identifier le processus responsable. Si l'activité est confirmée, bloquez l'infrastructure et isolez le système affecté en vue d'une correction.
Ce type de recherche ciblée ne remplace pas une enquête plus approfondie, mais il offre aux équipes un moyen rapide d'identifier les systèmes susceptibles d'avoir été compromis et de hiérarchiser les interventions. Lors d'un incident où l'exécution s'effectue de manière silencieuse et où les indices sont rares, ce signal initial peut réduire considérablement le temps nécessaire pour comprendre ce qui s'est réellement exécuté dans votre environnement.
Les attaques visant la chaîne d'approvisionnement se concentrent désormais sur l'identité
Une fois l'accès obtenu, l'attaque ne repose plus sur malware . Des identifiants valides offrent une voie d'action plus fiable et moins facile à détecter.
Les pirates peuvent s'authentifier, appeler des API et interagir avec les systèmes en utilisant les mêmes interfaces et les mêmes processus que ceux sur lesquels s'appuient quotidiennement les développeurs et les outils d'automatisation. Cela leur permet de se fondre dans l'activité normale tout en étendant leur champ d'action à l'ensemble des environnements.
L' exemple de Shai-Hulud a illustré le fonctionnement de ce mécanisme, en utilisant des jetons volés pour créer des référentiels, modifier des pipelines et étendre son influence via des relations de confiance existantes sans introduire d'anomalies manifestes au niveau des événements individuels.
L'incident Axios offre la même opportunité. Un compte de service accédant à des ressources qu'il n'a jamais utilisées auparavant, un jeton apparaissant dans un nouveau contexte ou un pipeline se comportant différemment de ce qui était prévu sont autant d'événements qui peuvent s'expliquer pris isolément. Considérés dans leur ensemble, ils forment une tendance qui indique une utilisation abusive des droits d'accès plutôt qu'un fonctionnement normal.
Détecter ce qui se passe après la compromission
Une fois que le code a été exécuté, le défi ne consiste plus à prévenir les menaces, mais à comprendre comment cet accès est utilisé.
L'un des premiers indices de cette chaîne d'attaque est la communication sortante vers l'infrastructure de commande et de contrôle. Même lorsque le dropper supprime ses propres traces, cette activité réseau persiste. Des connexions externes inhabituelles provenant de machines de développement, d'environnements d'intégration continue ou d'environnements d'application peuvent constituer un signe évident qu'il y a un problème, en particulier lorsque la destination ne correspond pas au comportement attendu en matière de dépendances ou de compilation.
Le Vectra AI plateforme s'attache à identifier ces schémas dans les systèmes d'identité, les environnements cloud SaaS, ainsi que l'activité réseau. Elle met en évidence les comportements d'authentification qui ne correspondent pas à l'usage habituel, signale les schémas d'accès qui s'écartent du comportement attendu en termes de charge de travail, et détecte les activités suggérant une phase de préparation, une persistance ou un déplacement latéral.
Pris isolément, ces signaux peuvent passer inaperçus. Mais lorsqu’on les examine conjointement, ils permettent de déterminer si une intrusion s’est arrêtée au stade de l’exécution ou si elle a évolué vers une compromission plus étendue.
Pour une analyse plus approfondie de la manière dont ces schémas post-exploitation se manifestent dans différents environnements, cette étude passe en revue l'enquête sous l'angle de la détection.
Ce en quoi vous pouvez encore avoir confiance
L'incident Axios ne s'arrête pas à la suppression d'un paquet malveillant. Il marque le moment où la certitude cède la place à l'évaluation des risques.
La plupart des équipes sont en mesure de déterminer si les versions concernées étaient présentes. Rares sont celles qui peuvent préciser où elles ont été exécutées ou ce à quoi ces environnements étaient exposés à ce moment-là. Cette distinction est importante, car elle permet de savoir si l'incident a été limité ou s'il a donné lieu à un accès durable.
S'il existe la moindre possibilité que les versions compromises aient été exécutées, l'hypothèse la plus prudente est de considérer que l'environnement ne peut plus être considéré comme fiable dans son état antérieur. Les machines des développeurs, les serveurs d'intégration continue et les systèmes de compilation disposent souvent de droits d'accès plus étendus que prévu, et ces droits sont rarement répertoriés de manière exhaustive.
La réponse initiale reste simple : revenir à une version propre, supprimer la dépendance et reconstruire les systèmes concernés, plutôt que de tenter un nettoyage partiel. Le plus difficile est de déterminer ce à quoi on peut encore faire confiance par la suite.
Les identifiants associés à ces environnements doivent être considérés comme compromis, non pas parce qu'il existe des preuves d'une utilisation abusive, mais parce qu'il n'existe aucun moyen fiable de prouver le contraire. Leur rotation s'impose pour rétablir la confiance.
Cet incident met également en évidence des problèmes structurels liés à la gestion des dépendances. Les pipelines CI/CD qui intègrent automatiquement les dernières versions disponibles ouvrent la voie à l'exécution immédiate des paquets malveillants nouvellement publiés. L'introduction d'un délai entre la publication et l'adoption, associée à un verrouillage plus strict des versions, réduit l'exposition en laissant le temps aux problèmes de se manifester avant le déploiement.
Dans le même temps, la cause profonde reste la compromission d'identité. Les comptes des responsables de maintenance et de déploiement doivent être considérés comme des actifs de grande valeur, avec une séparation claire entre les accès quotidiens au développement et les privilèges de publication. Réduire le recours aux jetons à longue durée de vie et mettre en place des contrôles plus stricts autour des workflows de publication permet de limiter l'impact de ce type d'attaque.
Le constat général vaut pour tous les incidents touchant la chaîne d'approvisionnement. Le point d'entrée peut être une dépendance compromise, mais l'impact dépend de la manière dont cet accès est exploité par la suite. La compromission d'Axios a été de courte durée, mais les conditions qu'elle a créées pourraient persister bien au-delà de la fenêtre d'installation.