IronWorm: l'attaque qui vole les identifiants et transforme npm en porte d'entrée pour les paquets malveillants

Une nouvelle attaque contre la chaîne d'approvisionnement de npm a révélé une nouvelle fois que les dépôts de paquets et les flux automatisés d'IC sont des cibles privilégiées pour les acteurs qui cherchent à accéder aux identifiants et aux secrets. Des chercheurs de JFrog ont identifié une campagne qui a infecté 36 paquets avec un pseudo infostealer IronWorm, un binaire écrit dans Rust qui combine des techniques avancées de persistance et de sigil: il est caché après une quille rootkit basée sur eBPF et communique avec son opérateur à travers le réseau Tor.

Ce qui distingue IronWorm n'est pas seulement sa technologie, mais sa stratégie de propagation : il vole les justificatifs des comptes engagés et publie ensuite des versions échouées de paquets npm au nom des victimes, en profitant de flux de publications fiables. Attaques jusqu'à 86 variables d'environnement et 20 types de fichiers d'identification y compris les clés et jetons OpenAI, AWS, Anthropic, npm, fichiers de configuration de voûte, clés SSH et fichiers portefeuille Exodus, ce qui explique leur intérêt pour les environnements de développement et CI où ces secrets sont généralement accessibles.

Les enquêteurs observent également des artefacts pour échapper à l'enquête médico-légale, tels que commis avec une fausse paternité et de vieux timstamps (il y a jusqu'à 13 ans) réécrits pour le rendre légitime. Une mécanisation a également été détectée à l'aide de GitHub Actions pour consolider les secrets volés dans un dispositif de construction inoculé, ce qui permet d'exfiltration sans avoir besoin d'un canal C2 externe - bien que JFrog indique que cette méthode n'a pas été utilisée dans la campagne analysée, sa simple existence modifie la surface de risque des pipelines automatisés. Vous trouverez ici l'analyse technique de JFrog : Rearch.jfrog.com.

L'opération montre des similarités conceptuelles avec les campagnes précédentes telles que Shai Hallud : utilisation de la publication automatisée pour se reproduire et se concentrer sur les références de publication. Bien que JFrog n'établisse pas de lien direct avec TeamPCP ou Shai Hallud, le chevauchement des noms de commit et l'évolution technique laissent ouverte la possibilité que nous sommes confrontés à une nouvelle étape d'une opération plus sophistiquée et consolidée avec sa propre infrastructure.

Pour les développeurs et les équipements de sécurité, les implications sont claires et urgentes: un jeton unique engagé peut convertir un environnement CI ou un compte npm en une passerelle pour une épidémie de paquets malveillants. En plus du risque classique de vol de secrets dans l'hôte, ce modus operandi attaque la chaîne de confiance de l'écosystème : des paquets avec des dépendances légitimes se déplacent pour distribuer du code malveillant à des milliers de projets en aval.

Les mesures immédiates qui devraient être prises comprennent la rotation et la révocation des jetons et des clés affectées, permettant 2FA dans tous les comptes avec permis de publication, et la mise à jour des versions des paquets triées identifiées par les analyses. Il est également essentiel de vérifier les flux de travail de l'IC pour identifier les scripts pré-installés ou les artefacts inattendus, limiter l'accès pour construire des artefacts et réduire l'exposition des secrets dans les variables d'environnement. Les guides opérationnels pertinents de la plateforme peuvent aider à mettre en œuvre des contre-mesures spécifiques, telles que la documentation npm et les pratiques des artefacts dans GitHub Actions: docs.npmjs.com et Docs.github.com (GitHub Actions artefacts).

Au niveau technique de la détection, il convient de vérifier la présence de dispositifs ou le comportement indicatif des rootkits eBPF (par exemple, des charges inhabituelles dans / sys / fs / bpf ou des modules/objets suspects du noyau), de rechercher des binaires ELF intégrés dans des paquets npm, d'examiner les journaux de publication et de les corréler avec des adresses IP, et de surveiller les binaires inhabituels Sorties Tor ou modèles de connexion à partir d'environnements de développement et d'IC. Les solutions EDR et les règles de détection comportementale qui identifient les changements dans les processus de construction ou les exécutions de scripts préinstallés augmentent la probabilité de détecter de telles opérations avant qu'elles ne se propagent.

Les organisations et les plateformes ont un rôle essentiel à jouer : les fournisseurs de npm et d'IC devraient renforcer les contrôles des flux de travail qui peuvent publier des paquets (politiques d'approbation, vérification d'identité et signatures de publication), améliorer la détection des paquets contenant des binaires compilés et faciliter la rotation forcée des jetons après les incidents. Pour ceux qui gèrent les dépôts et les dépendances, adopter des pratiques telles que la signature d'objets, la surveillance continue de la chaîne d'approvisionnement et l'adoption de cadres d'intégrité tels que l'ASLS réduit le risque systémique.

Cet incident montre que les attaquants investissent dans la sophistication (Rust, rootkits eBPF, Tor) et dans des tactiques furtives (faux métadonnées, utilisation de pipelines légitimes pour exfilter). Une défense efficace exige une combinaison de l'hygiène des titres de compétence, le principe de moins de privilège dans l'IC, des examens de sécurité sur chaque couche et la visibilité des artefacts de construction. Pour ceux qui veulent approfondir l'analyse complémentaire et d'autres attaques contemporaines détectées dans npm, veuillez consulter les rapports de tiers tels que Endor Labs: Endorlabs.com et les avis de réponse des équipes émergentes.

La leçon à long terme est que la sécurité des logiciels ne peut plus se limiter au code source : elle nécessite des contrôles sur les identifiants, les pipelines et les plateformes de publication. Ceux qui développent et maintiennent des paquets doivent supposer que, tôt ou tard, un jeton exposé peut devenir un vecteur d'attaque de masse et planifier en conséquence : la détection, la réponse et la résilience font maintenant partie du cycle de vie du logiciel.