Supply Chain Alert: IronWorm & New Miasma Variant Target npm
Saw this drop on The Hacker News this morning. The npm ecosystem is taking another significant hit. We're looking at a coordinated attack involving over 50 packages—some malicious, some poisoned versions of legitimate libs. The payload? A Rust-based stealer (IronWorm) and a fresh Miasma worm variant.
What concerns me most is the evolution in evasion tactics. The JFrog report indicates the IronWorm stealer is utilizing an eBPF kernel rootkit to hide its presence. If they're loading eBPF programs, they effectively own the kernel, making traditional userland EDR detection nearly impossible. This isn't just a simple crypto miner; it's scraping secrets and persisting at the kernel level.
If you manage Node.js environments, I recommend an immediate audit of your package-lock. files against the published IOCs and ensuring your CI/CD pipelines aren't pulling from compromised registries.
Here is a quick command to audit your current environment for known vulnerabilities:
# Check for high-severity vulnerabilities
npm audit --audit-level=high
# List globally installed packages to check for anomalies
npm list -g --depth=0
Given the move towards kernel-level obfuscation, are we seeing enough coverage for eBPF monitoring in standard corporate stacks, or is this still a gap for most blue teams?
This is exactly why we switched to a strict allow-list policy for internal registries. Typosquatting is getting harder to spot when they hijack legitimate maintainer accounts.
For detection, we've had success querying for unusual child processes spawned by npm or node. A build process shouldn't be spawning a shell or interacting with lsass.exe.
// Example KQL for suspicious process lineage
Process
| where ProcessVersionInfoOriginalFileName in ("npm.exe", "node.exe")
| where InitiatingProcessFileName !in ("cmd.exe", "powershell.exe", "bash")
That said, the eBPF rootkit part is terrifying. Standard EDR agents usually sit at the user/kernel API boundary, so they might miss this if the rootkit hooks correctly.
The eBPF angle is a game changer. If the attackers are verifying the kernel version before dropping the payload, they are targeting specific distros very precisely.
I'd suggest checking for any unauthorized BPF programs loaded on your build runners. On Linux, you can inspect loaded programs, though it requires root.
# List loaded BPF programs
sudo bpftool prog list
# Check for suspicious maps associated with the programs
sudo bpftool map list
If you see programs linked to unknown PIDs or with unexpected 'type' tags (like `kprobe` on standard syscalls where they shouldn't be), isolate the host immediately.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access