IronWorm : un ver npm écrit en Rust qui vole vos clés cloud et IA

Après la compromission des paquets @asyncapi, un autre incident npm confirme que la chaîne d'approvisionnement JavaScript est un champ de bataille permanent. IronWorm, documenté par JFrog et suivi par OX Security, est un ver auto-répliquant écrit en Rust qui a infecté une trentaine de paquets npm. Il se distingue par une sophistication technique inhabituelle et par une cible qui devrait alerter toute équipe de développement moderne : les secrets cloud et les clés d'API des fournisseurs d'intelligence artificielle.

Un implant Rust, pas du JavaScript obfusqué

La première particularité d'IronWorm est de ne pas reposer sur du JavaScript obfusqué, comme la majorité des menaces npm. Le malware se cache dans un fichier exécutable binaire déclenché par un hook preinstall du paquet. Il s'agit d'un binaire ELF Rust d'environ 976 kilo-octets, exécuté au moment de l'installation, technique T1195.002 (Supply Chain Compromise).

Ce choix du Rust et du binaire natif n'est pas anodin : il complique l'analyse et échappe aux outils qui inspectent uniquement le code JavaScript des paquets. L'implant embarque un stub UPX modifié sur mesure pour déjouer les dépaqueteurs fondés sur signature, chiffre chaque chaîne interne avec une clé unique par site d'appel, et transporte un rootkit noyau de type eBPF. Sa communication de commande et contrôle passe par Tor, T1071.

Une cible taillée pour le développeur de 2026

Une fois actif, l'implant balaie 86 variables d'environnement et plus de vingt chemins de fichiers d'identifiants, couvrant AWS, GCP, Azure, Vault, Kubernetes, npm, Docker, GitHub, ainsi que l'ensemble des clés des fournisseurs d'IA. C'est la technique T1552.001 (Unsecured Credentials: Credentials In Files). Cette liste dessine le portrait d'un poste de développeur ou d'un environnement d'intégration continue moderne : c'est exactement là que se trouvent, souvent en clair dans des variables d'environnement, les clés qui donnent accès à l'infrastructure entière.

Le mécanisme d'auto-propagation est le plus préoccupant. IronWorm se réplique en volant des identifiants puis en poussant des commits GitHub qui publient automatiquement de nouveaux paquets malveillants. Une fois un développeur ou un environnement d'intégration compromis, il peut publier des versions trojanisées de paquets appartenant à la victime, qui infectent à leur tour d'autres développeurs et systèmes. C'est ce qui en fait un ver au sens propre, et non une simple compromission ponctuelle.

Une règle YARA sur le binaire Rust et le contexte preinstall

La détection la plus robuste vise le binaire lui-même, en s'appuyant sur les marqueurs d'un ELF Rust empaqueté et sur les artefacts caractéristiques. Un paquet npm légitime n'embarque pratiquement jamais un binaire ELF Rust déclenché au preinstall.

rule IronWorm_Npm_Rust_Implant
{
    meta:
        description = "Detecte l implant Rust IronWorm distribue via npm (preinstall)"
        reference = "https://www.ox.security/blog/ironworm-supply-chain-malware-hits-npm/"
        author = "ThreatClaw"
        date = "2026-07-18"
    strings:
        $elf = { 7f 45 4c 46 }
        $rust1 = "rustc" ascii
        $rust2 = "cargo" ascii
        $panic = "called `Result::unwrap()`" ascii
        $upx = "UPX!" ascii
        $tor = ".onion" ascii
    condition:
        $elf at 0 and
        filesize < 3MB and
        2 of ($rust1, $rust2, $panic) and
        ( $upx or $tor )
}

Cette règle exige un en-tête ELF, une taille compatible avec un implant compact, des marqueurs Rust, et au moins un indice de compression sur mesure ou de commande et contrôle par Tor. Complétez-la par une inspection statique des fichiers package.json cherchant un hook preinstall ou postinstall qui exécute un binaire local plutôt qu'un script, un schéma inhabituel qui mérite toujours une revue.

Les mesures de fond pour une équipe de développement

Au delà de la détection, deux principes limitent l'impact d'un tel ver. Le premier est de ne jamais laisser de secrets durables dans les variables d'environnement d'un poste ou d'un runner : privilégier des secrets à durée de vie courte, injectés au moment du besoin et révoqués ensuite, prive l'implant de matière à voler. Le second est de contrôler la publication npm et les jetons GitHub : exiger une authentification forte pour publier, et surveiller les publications de paquets inattendues, casse le mécanisme d'auto-propagation.

Détecter un implant natif embarqué dans la chaîne d'approvisionnement demande des signatures maintenues sur les binaires réels, pas seulement des règles sur le code JavaScript. C'est ce que fournit le feed YARA ThreatClaw : des règles construites à partir d'échantillons réels et testées contre un corpus de code légitime, pour repérer les charges natives que les inspections de surface laissent passer.