Attaque de la chaîne d’approvisionnement Mini Shai-Hulud : pourquoi cette campagne change la façon dont les défenseurs doivent penser aux logiciels de confiance

L’attaque de la chaîne d’approvisionnement Mini Shai-Hulud n’est pas seulement un autre incident de package malveillant. Cette campagne a abusé de l’infrastructure de publication légitime, y compris des workflows de publication approuvés, des pipelines signés par la provenance et des environnements de développeurs. Ces techniques sont particulièrement efficaces pour rendre l’activité malveillante normale, car le code passera la plupart des vérifications standard et des contrôles d’intégrité.

Selon le post-mortem TanStack, les packages TanStack compromis portaient des attestations de provenance valides produites par le pipeline de publication de confiance GitHub Actions du projet. Même lorsque les attestations de provenance étaient valides, la provenance seule était insuffisante. La campagne, attribuée à l’acteur malveillant TeamPCP, a ensuite utilisé des informations d’identification de publication volées pour propager la campagne sur des packages supplémentaires.

Bon nombre des contrôles que les équipes de sécurité ont mis en œuvre pendant des années ont été conçus pour vérifier l’authenticité et non l’intention. Dans cette campagne, les contrôles d’authenticité passeraient toujours avec succès alors que le logiciel livré était compromis.

Ce qui s’est passé lors de l’attaque de la chaîne d’approvisionnement Mini Shai-Hulud

Comme le rapporte publiquement la communauté de la sécurité, cette campagne a affecté plus de 170 packages à travers npm et PyPI et a touché des écosystèmes avec une portée massive en aval. L’attaque ciblait les outils et bibliothèques de développeurs largement utilisés, y compris les packages liés aux frameworks frontaux, aux SDK d’IA, aux outils d’automatisation d’entreprise et à l’infrastructure de recherche.

À un niveau élevé, la campagne a fonctionné comme suit :

• Les attaquants ont détourné un chemin de publication fiable en compromettant le processus de création lui-même.
• Les versions de package malveillantes ont été publiées via des workflows légitimes et portaient des attestations de provenance valides.
• Une fois installés, ces packages ont volé les informations d’identification des machines du développeur et des exécuteurs CI/CD.
• Le logiciel malveillant a ensuite utilisé ces informations d’identification volées pour publier plus de packages empoisonnés.
• Des mécanismes de persistance ont été ajoutés pour survivre aux tentatives de nettoyage et continuer le vol d’informations d’identification.

C’est ce qui a rendu la campagne semblable à un ver. Chaque environnement nouvellement compromis pourrait devenir un point de distribution pour la prochaine vague.

Pourquoi cette attaque est différente

Elle a abusé des processus de publication approuvés, pas seulement de la confiance des packages

L’attaquant a détourné un pipeline de versions légitime plutôt que de simplement publier des typosquats évidents ou de faux packages. Les versions malveillantes ont conservé des signaux de provenance valides, ce qui souligne que les vérifications d’authenticité seules étaient insuffisantes.

Si votre contrôle unique ou principal vérifie si un package provient du pipeline attendu, cela ne suffit pas. Le pipeline était le vecteur d’attaque, et le Mini Shai-Hulud semblait légitime dans les vérifications typiques qui vérifient et confirment quel pipeline a créé un artefact, et non si le contenu de l’artefact est intentionnel.

Il se propage à travers l’identité, pas seulement le code

Cette campagne était fortement axée sur l’identité et exploitée au sein d’un écosystème présentant des secrets extrêmes. L’échelle des secrets exposés dans l’écosystème lui a donné de la place pour fonctionner : GitGuardian a signalé 28,65 millions de nouveaux secrets codés en dur publiquement exposés sur GitHub en 2025.

Plutôt que de s’appuyer sur une seule exécution ponctuelle, elle s’est concentrée sur le vol d’informations d’identification sur les machines des développeurs et les runners CI/CD. Une fois que les attaquants avaient ces identités, la publication de logiciels elle-même est devenue le mécanisme de propagation. Il ciblait les environnements de développeurs comme une couche de persistance.

La campagne a installé des crochets de persistance dans les outils de développement et les chemins de configuration locaux, y compris les répertoires liés à l’IDE et les environnements de codage assistés par IA. La persistance dans .claude/settings.json (un crochet SessionStart qui s’exécute à nouveau sur chaque session Claude Code) et .vscode/tasks.json (s’exécute automatiquement sur le dossier ouvert) signifie que le simple fait d’exécuter « désinstaller npm » seul ne la supprime pas.

Comment la chaîne d’attaque a fonctionné

Alors que les implémentations variaient selon le package et l’écosystème, la campagne a largement combiné la compromission de la chaîne d’approvisionnement, le vol d’informations d’identification et l’auto-propagation.

Ce que le logiciel malveillant a essayé de voler

Les rapports sur l’attaque de la chaîne d’approvisionnement Mini Shai-Hulud indiquent un large champ d’application de collecte. L’objectif n’était pas un seul type de jeton. En Q3 2025, Sonatype a constaté que 37 % des packages open source malveillants ciblent l’exfiltration des données, et cette campagne a suivi ce même modèle. Il a été conçu pour récolter tout ce qui est utile pour les mouvements latéraux, la persistance et la compromission de suivi.

Les cibles courantes comprenaient :

• Informations d’identification du fournisseur cloud
• Jetons de registre de package
• Secrets de pipeline CI/CD
• Informations d’identification Git et jetons de contrôle source
• Fichiers de configuration Kubernetes, jetons de compte de service et informations d’identification ou jetons qui donnent accès aux gestionnaires de secrets
• Clés SSH
• Fichiers de configuration du développeur local
• Paramètres d’outillage de développeur IA
• Données du portefeuille de cryptomonnaies dans certaines variantes

Les équipes d’intervention ne doivent pas penser en termes de « rotation du jeton npm et de passage à autre chose ». Si un package empoisonné est exécuté dans un environnement sensible, le rayon d’explosion est probablement beaucoup plus grand.

Indicateurs indiquant que vous pouvez être affecté

Les équipes de sécurité enquêtant sur l’exposition potentielle doivent examiner à la fois les dépendances et le comportement des endpoints. Il ne s’agit pas seulement d’un problème de composition logicielle.

Signes de niveau de dépendance

Commencez par :

• Fichiers de verrouillage faisant référence aux versions affectées
• Journaux d’installation du package à partir de 11 mai
• Scripts de cycle de vie inattendus tels que la préinstallation ou la préparation
• Dépendances facultatives suspectes ou références de package basées sur Git
• Des bâches inhabituellement volumineuses ou des fichiers masqués intégrés

Signes au niveau des endpoints et de l’environnement

Recherchez également :

• Changements inattendus dans .vscode/ ou .claude/ les répertoires
• Lancement non autoriséAgents ou services système au niveau de l’utilisateur
• Nouveaux fichiers de workflow ajoutés aux référentiels
• Connexions sortantes à une infrastructure suspecte pendant l’installation du package
• Événements de publication de package que les gestionnaires ne reconnaissent pas
• Référentiels publics suspects ou engagements créés avec des informations d’identification volées

Signes réseau et comportementaux

Les principaux rapports d’incidents indiquent également des canaux d’exfiltration redondants. Cela signifie que les défenseurs ne doivent pas supposer que le blocage d’un domaine met fin au risque. Surveillez :

• Appels API inhabituels vers les plateformes d’hébergement de code
• Trafic vers des domaines contrôlés par des attaquants connus, des API d’hébergement de code public utilisées pour l’exfiltration, des endpoints webhook, une infrastructure liée à Tor ou des passerelles IPFS, si celles-ci ont été observées
• Accès soudain aux services de métadonnées, aux chambres fortes locales ou aux magasins de jetons
• Comportement du processus qui lit les variables d’environnement, les magasins de jetons, l’historique de shell, les informations d’identification du gestionnaire de packages ou d’autres fichiers portant le secret sur les postes de travail des développeurs et les exécuteurs d’EC

Comment réagir à l’attaque de la chaîne d’approvisionnement Mini Shai-Hulud

Il s’agit d’un incident qui nécessite à la fois la coordination de la sécurité et des opérations informatiques. Une réponse efficace suit généralement une séquence stricte.

Actions immédiates

• Identifiez si les versions de package affectées ont été installées.
• Isolez les postes de travail de développeur et les environnements CI/CD affectés avant de révoquer les informations d’identification.
• Coordonnez-vous avec IR afin que la révocation du jeton ne déclenche pas de logique destructrice connue sur les hôtes toujours connectés.
• Recherchez les artefacts de persistance avant d’effectuer des modifications importantes.
• Conservez les preuves médico-légales lorsque cela est possible.
• Vérifiez si des packages sous votre contrôle ont été republiés de manière inattendue.

Pourquoi le séquençage est important

Le logiciel malveillant inclut un commutateur d’homme mort. Un démon de persistance (moniteur de jetongh) interroge GitHub toutes les 60 secondes. Lorsqu’il détecte la révocation du jeton (réponse HTTP 40X ), il exécute rm -rf ~/—une suppression complète du répertoire d’accueil. Cela signifie que les défenseurs doivent isoler les environnements compromis avant de révoquer les informations d’identification. Le fait de le faire dans le mauvais ordre déclenche la charge utile destructrice. Pour cette raison, la réponse mature ici n’est pas simplement « tout annuler maintenant ». C’est :

• Isoler en premier
• Inspecter la persistance
• Image si nécessaire
• Puis tourner et corriger selon une séquence contrôlée

Les équipes qui ont investi dans la réponse aux incidents et les opérations de sécurité sont mieux positionnées pour coordonner cette séquence entre les endpoints, les identités et les flux de travail judiciaires.

Ce que cet incident dit sur la confiance logicielle

L’attaque de la chaîne d’approvisionnement Mini Shai-Hulud expose un angle mort que de nombreuses organisations ont encore : elles valent signées, officielles ou soutenues par une provenance avec un coffre-fort.

Ce sont toujours des signaux précieux. Mais ils ne sont pas suffisants seuls.

Un modèle plus solide comprend désormais tous les éléments suivants :

• Vérification de l’origine du logiciel
• Retarder l’adoption des nouvelles versions publiées
• Restreindre l’exécution du script au moment de l’installation
• Surveillance du comportement d’exécution pendant les constructions et les installations
• Réduire l’exposition secrète dans CI/CD
• Regarder les endpoints des développeurs avec la même rigueur que celle utilisée pour les serveurs

Mesures pratiques de renforcement que les équipes doivent mettre en œuvre dès maintenant

La bonne réponse à long terme n’est pas l’évitement des colis motivé par la panique. Il s’agit d’un durcissement par couches.

Contrôles de création et de package

Elles font toutes partie d’une stratégie de défense plus large de la chaîne d’approvisionnement logicielle qui suppose que les workflows de confiance peuvent toujours être utilisés de manière abusive.

Contrôles d’identité et de secrets

• Réduire les informations d’identification de publication à long terme
• Définir étroitement les identités CI/CD
• Permissions de création, de publication et de déploiement distinctes
• Minimiser les secrets présents sur les runners
• Vérifiez régulièrement les paramètres d’accès à la publication des packages et de contournement de l’authentification à deux facteurs

Contrôles des endpoints et de l’environnement des développeurs

• Surveiller les chemins de configuration IDE et les crochets de démarrage
• Traiter les répertoires d’outils de développeur comme pertinents pour la sécurité, et non bénins
• Inventaire où les informations d’identification cloud et les jetons de registre sont stockés
• Vérifier la suppression de la persistance, pas seulement la suppression du package

Ce qu’exige une réponse efficace de la chaîne d’approvisionnement

Il ne s’agit pas seulement d’un problème de vulnérabilité du package logiciel. Il s’agit d’un problème d’endpoint, d’identité et de réponse opérationnelle en même temps.

En fin de compte : si les développeurs ou les systèmes de construction automatisés de votre organisation ont installé des composants affectés depuis 11 mai, traitez ces environnements comme compromis. Étant donné que la propagation reposait sur des identités volées, chaque environnement compromis pourrait devenir un point de distribution.

Il s’agit du premier cas documenté d’attaque auto-propagée de la chaîne d’approvisionnement qui a produit des packages malveillants avec des attestations de provenance valides et conformes aux normes du secteur. Les niveaux de chaîne d’approvisionnement pour les artefacts logiciels (SLSA) ont fonctionné comme prévu. L’écosystème a supposé avoir résolu plus de problèmes qu’il ne le fait. Provenance confirme quel pipeline a créé un artefact, et non si le pipeline se comportait comme prévu.

L’attaquant n’a pas falsifié de faux reçu. Ils sont entrés dans la cuisine et ont préparé un repas empoisonné à l’aide de la cuisinière du restaurant. Le reçu était techniquement exact.

TeamPCP (également suivi comme DeadCatx3, PCPcat, ShellForce, CipherForce) a systématiquement ciblé la chaîne de confiance elle-même :

• 2026 mars : Trivy, un scanner de sécurité open source, les outils que les défenseurs utilisent (Microsoft)
• 2026 avril : Bitwarden CLI, un gestionnaire de mots de passe, magasins d’informations
• 2026 mai : ver de l’écosystème npm/PyPI, la chaîne d’approvisionnement logicielle élargie

Le groupe a annoncé un partenariat avec Vect, une opération de ransomware en tant que service (Unité 42). Les indicateurs d’attribution comprennent un commutateur de destruction russe (Microsoft). Qu’un opérateur ou plusieurs affiliés soient impliqués, le modèle suggère que les outils d’attaque de la chaîne d’approvisionnement arrivent à maturité dans les réseaux affiliés aux ransomwares.

Les attaques de la chaîne d’approvisionnement sont souvent des précurseurs d’attaques plus importantes, y compris les ransomwares, plutôt que des événements isolés de vol d’informations d’identification. Les campagnes récentes abusant de marques logicielles de confiance telles que Notepad++ et les canaux de téléchargement renforcent le fait que les chemins de distribution de logiciels restent des cibles de grande valeur.

Pour les défenseurs, cela se divise en trois phases et leurs délais :

1. Actions immédiates à hiérarchiser (heures)

• Vérifiez les fichiers de verrouillage et les journaux d’EC pour toutes les versions de package affectées installées depuis 11 mai
• Si l’exposition est confirmée, isolez l’environnement avant de révoquer les jetons
• Vérifiez les noms de persistance d’échantillon connu tels que com.user.gh-token-monitor.plist et gh-token-monitor.service, et recherchez également des LaunchAgents non autorisés fonctionnellement équivalents, des services utilisateur, des tâches cron, des modifications de démarrage de shell et des crochets de démarrage IDE/outil
• Vérifiez les fichiers .claude/ et .vscode/répertoires pour les charges utiles de persistance injectées
• Faites pivoter toutes les informations d’identification accessibles à partir de n’importe quel environnement exposé, et pas uniquement les jetons npm

2. Actions à court terme (jours)

• Manifestes de dépendance d’audit, fichiers de verrouillage, journaux d’EC, caches, images d’exécuteur et toute SBOM générée pour les packages et versions affectés, y compris les packages liés au frontend, à l’automatisation d’entreprise, à la recherche et à l’outillage d’IA
• Si les runners CI/CD disposaient d’informations d’identification de publication PyPI tout en exécutant des packages npm compromis, faites-les également pivoter
• Examinez les workflows GitHub Actions qui utilisent pull_request_target avec le paiement de code non approuvé, GITHUB_TOKEN avec portée d’écriture, les secrets exposés ou la réutilisation du cache au-delà des limites de confiance, car ces combinaisons peuvent permettre une compromission du workflow

3. Actions stratégiques (cette semaine et au-delà)

• Retards d’âge minimum de publication : même un retard de 3 jours aurait fourni un tampon défensif contre cette campagne, conformément aux directives de la CISA sur l’atténuation des attaques de la chaîne d’approvisionnement en évolution rapide. Mettre en œuvre via l’âge de publication min en pnpm, ou appliquer via un registre proxy/moteur de politique d’artefact pour les gestionnaires de packages qui ne le prennent pas en charge nativement.
• Épinglez les dépendances aux versions exactes et appliquez les fichiers de verrouillage, y compris leurs hachages d’intégrité enregistrés
• Définir ignore-scripts=true dans .npmrc pour les environnements CI
• Traiter les attaques de la chaîne d’approvisionnement comme un précurseur d’une compromission plus large de l’entreprise

Questions que les équipes de sécurité devraient poser maintenant

Un développeur ou un environnement CI a-t-il installé les versions affectées après 11 mai ?

Si la réponse est oui, supposez un compromis jusqu’à preuve du contraire.

Quels secrets étaient présents dans ces environnements au moment de l’exécution ?

Concentrez-vous d’abord sur le cloud, la publication de packages, le contrôle des sources et les identités de déploiement.

Des référentiels ou des packages sous votre contrôle ont-ils été modifiés ou republiés de manière inattendue ?

Cette campagne s’auto-propagait. Votre environnement a peut-être été à la fois une victime et un point de distribution. Si oui, vos informations d’identification de publication peuvent avoir été utilisées pour compromettre d’autres personnes.

Pouvez-vous vérifier la suppression de la persistance des endpoints ?

Ne vous arrêtez pas à la suppression des modules de nœuds ou à la restauration des fichiers de verrouillage.

Transformer le risque de la chaîne d’approvisionnement en réponse exploitable avec Tanium

Tanium Guardian et le tableau de bord de compromission de la chaîne d’approvisionnement Mini Shai-Hulud offrent aux équipes chargées de la sécurité et des opérations informatiques une vue partagée et en temps réel de l’état des endpoints sur la surface d’attaque des développeurs :

• Aider à identifier les endpoints où les packages npm et PyPI impactés peuvent être exécutés, à l’aide des données SBOM, le cas échéant
• Portée de l’exposition des machines de surfaçage avec des outils Node.js, Python et IA tels que Claude Code installés
• Recherche d’indicateurs de persistance : lancementAgents, services au niveau de l’utilisateur et crochets de démarrage IDE ou d’outillage, à l’aide de questions prédéfinies qui s’exécutent par rapport à la télémétrie en temps réel des endpoints
• Vérifier le statut de nettoyage sur les configurations de runner CI/CD et les surfaces d’exposition des informations d’identification, pas uniquement les registres de package

Les organisations avec l’agent Tanium déjà déployé peuvent utiliser le contenu Guardian existant sans déploiement d’agent supplémentaire requis.

La réponse ne doit pas s’arrêter à l’examen du registre ou du référentiel. Les endpoints de développeur et les exécuteurs CI/CD font partie du chemin d’attaque. Tanium permet aux opérations informatiques et de sécurité de confirmer l’exposition, de vérifier la suppression de la persistance et de coordonner la remédiation à partir de la même vue de l’état actuel plutôt que de s’appuyer sur des artefacts de construction statiques ou des vérifications manuelles retardées.

FAQ sur l’attaque de la chaîne d’approvisionnement Mini Shai-Hulud

Les attaques de la chaîne d’approvisionnement comme Mini Shai-Hulud soulèvent des questions qui vont bien au-delà des manuels de réponse aux incidents standard.

Vous trouverez ci-dessous quelques questions courantes que les équipes de sécurité se posent sur cette campagne et ce que cela signifie pour la confiance dans les logiciels à l’avenir.

La provenance valide du package peut-elle toujours être approuvée ?

Il peut toujours être utile, mais il ne doit pas être traité comme un signal de sécurité complet. La Provenance vous dit d’où vient quelque chose. Cela ne prouve pas que le pipeline n’a pas été abusé.

Les équipes doivent-elles révoquer immédiatement les jetons volés ?

Pas aveuglément. Dans les incidents avec une logique de révocation destructrice, l’isolation et l’enquête doivent passer en premier afin que les actions de réponse ne déclenchent pas de dommages supplémentaires.

Quel est le contrôle préventif le plus pratique que la plupart des équipes manquent encore ?

Une période d’attente avant de consommer les versions de package nouvellement publiées reste l’un des contrôles les plus simples et les plus efficaces, en particulier contre les événements de chaîne d’approvisionnement en évolution rapide.

Pourquoi cette campagne est-elle importante au-delà des développeurs ?

Parce que les postes de travail des développeurs et les runners CI/CD détiennent souvent des informations d’identification cloud, des droits de déploiement et des identités de publication de package. Les compromettre peut rapidement devenir un incident d’entreprise plus vaste.

Tanium est conçu pour compléter les efforts et contrôles de sécurité de la chaîne d ’approvisionnement existants en connectant l’exposition aux packages, l’état des endpoints, la validation de la persistance et la vérification des réponses, afin que les opérations informatiques et de sécurité puissent agir à partir de la même image en temps réel.
Planifiez une démo dès aujourd’hui pour découvrir comment Tanium coordonne la réponse de la chaîne d’approvisionnement entre les endpoints et les identités.