IronWorm: A Rust-Built npm Worm That Steals Your Cloud and AI Keys
IronWorm hides a Rust binary triggered at preinstall, harvests cloud and AI keys, then self-propagates via GitHub. Here is the YARA rule to detect it.
After the @asyncapi package compromise, another npm incident confirms that the JavaScript supply chain is a permanent battlefield. IronWorm, documented by JFrog and tracked by OX Security, is a self-replicating worm written in Rust that infected around three dozen npm packages. It stands out for unusual technical sophistication and for a target that should alert any modern development team: cloud secrets and AI provider API keys.
A Rust implant, not obfuscated JavaScript
IronWorm's first distinctive trait is that it does not rely on obfuscated JavaScript, like most npm threats. The malware hides inside a binary executable file triggered by a package preinstall hook. It is a Rust ELF binary of roughly 976 kilobytes, executed at install time, technique T1195.002 (Supply Chain Compromise).
This choice of Rust and a native binary is not incidental: it complicates analysis and evades tools that inspect only the JavaScript code of packages. The implant embeds a custom-modified UPX stub to defeat signature-based unpackers, encrypts every internal string with a unique per-call-site key, and carries an embedded eBPF kernel-level rootkit. Its command and control communication goes through Tor, T1071.
A target tailored for the 2026 developer
Once active, the implant sweeps 86 environment variables and over twenty credential file paths, covering AWS, GCP, Azure, Vault, Kubernetes, npm, Docker, GitHub, and the full set of AI provider keys. This is T1552.001 (Unsecured Credentials: Credentials In Files). This list paints the picture of a modern developer workstation or continuous integration environment: that is exactly where the keys granting access to the entire infrastructure sit, often in cleartext in environment variables.
The self-propagation mechanism is the most concerning. IronWorm replicates by stealing credentials then pushing GitHub commits that automatically publish new malicious packages. Once a developer or an integration environment is compromised, it can publish trojanized versions of packages owned by the victim, which in turn infect other developers and systems. That is what makes it a worm in the true sense, and not just a one-off compromise.
A YARA rule on the Rust binary and preinstall context
The most robust detection targets the binary itself, relying on markers of a packed Rust ELF and characteristic artifacts. A legitimate npm package almost never embeds a Rust ELF binary triggered at preinstall.
rule IronWorm_Npm_Rust_Implant
{
meta:
description = "Detects the IronWorm Rust implant distributed 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 )
}This rule requires an ELF header, a size consistent with a compact implant, Rust markers, and at least one hint of custom compression or Tor command and control. Complement it with a static inspection of package.json files looking for a preinstall or postinstall hook that runs a local binary rather than a script, an unusual pattern that always warrants review.
The fundamental measures for a development team
Beyond detection, two principles limit the impact of such a worm. The first is to never leave durable secrets in the environment variables of a workstation or a runner: favoring short-lived secrets, injected on demand and revoked afterward, deprives the implant of material to steal. The second is to control npm publishing and GitHub tokens: requiring strong authentication to publish, and watching for unexpected package publications, breaks the self-propagation mechanism.
Detecting a native implant embedded in the supply chain requires maintained signatures on the real binaries, not just rules on the JavaScript code. That is what the ThreatClaw YARA feed provides: rules built from real samples and tested against a corpus of legitimate code, to spot the native payloads that surface inspections let through.
Related articles
The @asyncapi package compromise runs its payload at module load, not at install. Why --ignore-scripts fails and how to detect it with YARA.
A rule feed is not worth its rule count. It is worth the proof that the rules fire and what you do when they trigger. Tested on real engines, false-positive-proven, signed, and every rule ships an investigation playbook wired to our other engines.
From June to August 2026, ThreatClaw forged 72 new malware families into its YARA feed: Prometei, WannaCry, EternalBlue, GhostNFC, SpyNote, Mamont, Neshta… each tested against 5,694 legitimate binaries, zero false positives.
Prometei botnet on Linux, Windows code injection, Office macros, Android, downloaders. ThreatClaw adds 14 fresh malware families to its YARA feed, 391 rules, tested against 5,694 legitimate binaries with zero false positives.