IronWorm: eBPF Rootkit and Tor C2 Target npm Supply Chain

Key Takeaways

• IronWorm is a Rust-built infostealer worm discovered in early June 2026 that spread across 37 npm packages from a compromised account (initial reporting cited 36 packages as the investigation was ongoing), executing a 976 KB ELF binary via preinstall hooks before dependency resolution [1][2][10].
• The malware deploys an embedded eBPF kernel rootkit that hides its processes from standard Linux tooling, filters network connections from both /proc/net/tcp and the netlink interface used by ss, and kills any process that attempts to ptrace it — making it invisible to defenders relying on conventional host inspection [1].
• Command-and-control communication runs exclusively over Tor: the implant downloads the Tor expert bundle, writes its own torrc, establishes a circuit, and beacons to an attacker-controlled hidden service — preventing network-layer defenders from seeing C2 traffic or identifying operator infrastructure [1][2].
• IronWorm targets 86 environment variables and over 20 credential file paths, spanning AWS, GCP, Azure, Kubernetes, Docker, npm, GitHub, and a 2026-generation sweep of AI provider keys including Anthropic, OpenAI, Google Gemini, Cohere, Mistral, Groq, and xAI [1][3].
• Self-propagation weaponizes stolen credentials directly: the worm commits trojanized code into victims’ GitHub repositories under convincing generic commit messages and then abuses npm’s Trusted Publishing (OIDC) flow to publish poisoned versions of packages owned by compromised developers, extending infection to their downstream consumers [1][4].
• JFrog researchers who discovered the campaign found no match with any known infostealer, eBPF rootkit framework, or C2 toolkit, indicating a custom-built operation with dedicated infrastructure rather than a commodity toolkit — a level of investment not commonly observed in npm supply chain campaigns [1][10][12].

Background

The npm ecosystem has become a high-value target for supply chain adversaries because a single successful package compromise can propagate malicious code to thousands of dependent projects and CI/CD pipelines in a matter of hours. Earlier campaigns established the template: compromise a developer account, inject a malicious payload into a published package version, and let the dependency graph deliver the attack automatically [5]. The Shai-Hulud campaign, documented by Palo Alto Networks’ Unit 42, demonstrated how stolen developer credentials could be cycled back into the supply chain to self-replicate across the npm registry [5]. IronWorm follows the same propagation model while substantially raising the technical sophistication of the payload itself.

JFrog Security Research detected the IronWorm campaign in early June 2026 through scanning of newly published npm packages. The initial vector was the asteroiddao account, which had been compromised by attackers, and the campaign ultimately touched nine GitHub organizations: ocrybit, asteroid-dao, alisista, warashibe, kakedashi-hacker, weavedb, ArweaveOasis, arthursimao, and mlebjerg [1]. The affected packages were concentrated in the web3 and decentralized application space — including weavedb-sdk, weavedb-client, weavedb-base, arnext, and roidjs among the 37 total [1][11] — though the credential sweep the malware performs is technology-agnostic and targets any developer whose environment holds cloud, CI/CD, or AI platform credentials [1][2].

The malware’s dropped binary is named claude, matching the filename of Anthropic’s Claude CLI tool and suggesting deliberate social engineering in the choice of payload disguise. Similarly, the commit messages injected into victims’ repositories — “fix: resolve lint warnings,” “test: add missing edge case,” “ci: update workflow configuration” — are indistinguishable from legitimate maintenance commits without inspecting the changed file content [1][12]. The payload filename and commit message choices are consistent with sustained operational security awareness, minimizing the behavioral signatures that defender tooling commonly flags.

Security Analysis

Infection Vector and Binary Obfuscation

IronWorm’s delivery mechanism relies on npm’s preinstall lifecycle hook, which executes before the package’s dependencies are resolved. The malicious package.json contains the entry "preinstall": "./tools/setup", causing the Rust ELF binary to run with whatever permissions the installing process holds — typically the full privileges of the developer or CI runner performing the npm install. While blocking all lifecycle scripts globally via --ignore-scripts is technically feasible, it may require workflow adjustments for legitimate native-code packages that rely on compilation hooks, making selective enforcement a more practical starting control for many development environments [1][4].

The 976 KB binary employs two primary obfuscation techniques to resist static analysis. First, it uses a UPX packer with a modified magic signature, which defeats the automated unpacking tools that security scanners apply to flag known-packed binaries. Second, and more significantly, every string within the binary is encrypted with a unique per-call-site key rather than a single master decryption key — meaning that recovering one decryption key yields only the specific strings associated with that code path, not the entire string table. This per-site encryption substantially increases the reverse engineering effort required [1]. Analysts at JFrog note, however, that the operator left compiler debug metadata intact in the .BTF.ext section of the eBPF object, which revealed 214 source lines with line numbers and all ten BPF maps and struct field definitions — a significant operational security failure that aided forensic reconstruction of the rootkit’s capabilities [1].

The eBPF Kernel Rootkit

The embedded eBPF program, derived from source file q2.bpf.c, represents the campaign’s most novel defensive evasion technique, one not commonly encountered in npm supply chain attacks to date [1]. Extended Berkeley Packet Filter programs run within a sandboxed virtual machine in the Linux kernel, allowing them to hook kernel events without requiring a traditional kernel module. This architecture makes eBPF programs harder to detect than loadable kernel module rootkits while offering comparable visibility into system internals [6].

IronWorm’s eBPF component achieves process hiding by rewriting the output of /proc listings to remove entries belonging to processes the malware wishes to conceal. When a user or security tool reads /proc/[pid] entries — as ps, top, and similar utilities do — the BPF program intercepts the read and filters out designated PIDs. Network connections receive analogous treatment: the rootkit parses and strips rows from /proc/net/tcp that correspond to hidden sockets, and it applies the same filtering to netlink responses used by the ss tool, which is a common replacement for netstat in modern Linux distributions. The combined effect is that both the implant’s process and its C2 connections disappear from the tools a defender would naturally consult during an investigation [1].

When a process attempts to attach ptrace to one of IronWorm’s protected processes — the mechanism used by strace, gdb, and similar debugging tools — the BPF program responds by delivering SIGKILL to the attaching process. This means that a security analyst attempting to inspect the malware using standard Linux debugging workflows may find their tooling killed rather than the malware interrupted [1].

These stealth capabilities have an important architectural dependency: they rely on BPF helpers that permit writes to userspace memory. On systems with kernel lockdown enabled — a hardened kernel configuration that restricts the capabilities available to BPF programs — the process and TCP hiding mechanisms fail, though the anti-debugging and partial netlink filtering capabilities remain functional. This represents a meaningful differentiation between hardened enterprise Linux distributions and standard developer workstations or default CI runner images [1].

Command-and-Control Architecture

Rather than communicating over cleartext protocols or even encrypted HTTPS — which would be visible at the network perimeter — IronWorm routes all C2 traffic over Tor. The implant downloads the official Tor expert bundle and required libraries, writes a custom torrc configuration, establishes a Tor circuit, and then sends HTTP requests to an attacker-operated hidden service at /api/agent. This design significantly complicates network-based detection and attribution: perimeter controls see Tor traffic rather than a direct C2 connection, and the operator’s hidden service address is not exposed to passive network observers [1][2].

Three primary command capabilities have been identified from the C2 protocol analysis: uploading exfiltrated credentials and secrets, dropping attacker-supplied files onto the compromised host, and executing remote shell commands. The shell execution capability transforms IronWorm from a one-time exfiltration tool into a persistent remote access implant capable of issuing arbitrary commands to the compromised developer workstation or CI environment. Researchers also identified what appears to be a fallback exfiltration path: the malware can upload credential packages to the public file hosting service temp.sh over Tor and then report the resulting URL over the C2 channel, providing resilience against C2 infrastructure takedowns [1].

Credential Scope and AI Platform Targeting

The breadth of IronWorm’s credential sweep reflects a deliberate strategy to harvest high-value access across the full modern developer credential stack. The 86 targeted environment variables encompass the standard cloud infrastructure trifecta of AWS, Azure, and GCP, along with Kubernetes service account tokens, Docker registry credentials, CI/CD platform tokens, GitHub Personal Access Tokens, and npm publish tokens. The inclusion of AI provider keys — covering Anthropic, OpenAI, Google Gemini, Cohere, Mistral, Groq, Perplexity, and xAI — signals that AI API credentials have become economically significant targets in the threat actor’s harvesting strategy [1][3].

The file-path sweep adds credential material not captured by environment variables: ~/.aws/credentials, ~/.kube/config, ~/.docker/config.json, and notably ~/.claude/.credentials.json and ~/.codex/auth.json — the local credential stores for Anthropic’s Claude and OpenAI’s Codex CLI tools, respectively. When executed within a Kubernetes pod environment, the malware extends its reach further: it reads pod service account tokens, enumerates cluster namespaces, dumps Secret objects, and attempts to enumerate Vault backend secrets configured in the cluster [1]. The Exodus cryptocurrency wallet is specifically targeted through JavaScript hook injection that disables Electron security protections to capture wallet passwords and seed mnemonics, suggesting the campaign incorporates direct financial theft alongside credential harvesting, or that the threat actor monetizes wallet access separately from credential resale [1].

Self-Propagation and Worm Mechanics

IronWorm’s self-propagation capability is what distinguishes it as a worm rather than an infostealer: it reproduces through the supply chain without requiring the operator to manually identify and compromise each new target. After exfiltrating credentials, the implant uses stolen GitHub tokens to commit malicious code into repositories belonging to the compromised developer. These commits are backdated by copying the repository’s existing commit timestamps and use commit messages drawn from a list of generic, plausible-looking maintenance phrases — the same commit message pattern previously observed in the Shai-Hulud campaign [1][5].

The npm propagation path exploits npm’s Trusted Publishing mechanism, which uses short-lived OIDC tokens issued by CI/CD providers to allow packageless publishing without stored credentials. When IronWorm steals a developer’s Trusted Publishing configuration, it can trigger CI/CD workflows that publish new, trojanized versions of packages owned by the victim to the npm registry. These new versions then infect any developer or automated system that installs the package, beginning a new infection cycle. The campaign also targets additional package registries beyond npm, with evidence of propagation attempts into PyPI, Cargo, Conan, and vcpkg — suggesting either a multi-ecosystem strategy or a common propagation framework that is registry-agnostic [1].

One notable operator security failure assists attribution efforts: the malware contains a hardcoded BIP-39 twelve-word recovery phrase in plaintext within its credential filter skip-list: "bench crane defense corn wheel trial news abuse finish better paddle slush", corresponding to Ethereum address 0x7e28D9889f414B06c19a22A9Bd316f0AC279a4d6. This provides a potential attribution anchor for tracking the threat actor’s cryptocurrency infrastructure, though the address’s negligible balance at the time of analysis suggests it may have been a test address or quickly abandoned [1].

Recommendations

Immediate Actions

Organizations using npm in their development or CI/CD pipelines should audit recently installed packages against the list of 37 affected package versions and verify their integrity against known-good checksums. Any developer or CI system that ran npm install on an affected package should treat all credentials present in that environment as potentially compromised and begin rotating them immediately — prioritizing cloud provider credentials, Kubernetes service account tokens, GitHub tokens, and any AI API keys present in environment variables or credential files. Credential rotation should precede any further investigation to limit the attacker’s window of access.

Teams should also review GitHub repository commit histories for the suspicious commit messages documented in this note (“fix: resolve lint warnings,” “test: add missing edge case,” “ci: update workflow configuration,” “fix: address review feedback,” “docs: update contributing guide,” “chore: sync lockfile,” “fix: handle null pointer case,” “build: bump patch version,” “chore: update dependencies”) and cross-reference commits from [email protected]. Any commits matching this pattern that were not made by known team members should be reverted and the associated package versions unpublished.

Short-Term Mitigations

Disable npm lifecycle scripts — specifically preinstall, install, and postinstall hooks — by default across all developer workstations and CI pipelines. npm supports this via the --ignore-scripts flag or the ignore-scripts=true setting in .npmrc. While this may require developer workflow adjustments for legitimate native-code packages, it removes the primary execution vector for IronWorm and the broader class of install-hook supply chain attacks [4]. Pin all dependency versions using lockfiles and verify package integrity hashes rather than accepting the latest published version automatically.

Implement network-layer controls to detect or block Tor traffic from developer workstations and CI environments. IronWorm downloads the Tor expert bundle as part of its infection sequence; network egress policies that flag or block connections to Tor entry guards and known Tor bootstrap endpoints can interrupt this initialization step and prevent C2 establishment. Because IronWorm communicates with an attacker-operated hidden service — traffic that never exits the Tor network to the clearnet — blocking only Tor exit nodes is insufficient; controls should target Tor entry guard connections and Tor directory authority bootstrap endpoints specifically [2].

Restrict the scope of AI API keys stored in developer environments. API keys for Anthropic, OpenAI, and other AI providers should follow least-privilege principles: use project-scoped keys with usage limits rather than organization-wide keys, enable provider-side usage monitoring and alerting, and rotate keys on a regular cadence. Treat AI API keys with the same sensitivity as cloud provider credentials.

Strategic Considerations

IronWorm’s eBPF rootkit capability signals that sophisticated supply chain threats are no longer constrained to userspace techniques. Traditional endpoint detection and response tooling that relies on userspace process enumeration, network connection enumeration, or standard Linux inspection utilities may fail to detect an active IronWorm infection on a compromised host. Security teams should evaluate whether their current Linux endpoint monitoring stack would detect an eBPF-based implant, considering approaches such as eBPF-aware detection tools, kernel lockdown enforcement on CI/CD runners, and behavioral anomaly detection that can identify Tor bundle downloads or anomalous CI/CD publishing activity.

The concurrent discovery of the Miasma worm variant — which exploited a minimalist 157-byte binding.gyp file to bypass install-script monitoring, ultimately spreading across 57 packages and 286 malicious versions — in the same reporting window confirms that npm supply chain attacks are both accelerating in frequency and diversifying in technique [3]. Organizations should treat npm package installation as an implicit code execution event and apply the same code review scrutiny to dependency updates that they apply to first-party code changes. Establishing a curated internal registry that mirrors only vetted package versions, combined with SBOM generation and automated integrity verification, provides systemic protection against this class of attack beyond the current campaign.

CSA Resource Alignment

IronWorm’s multi-layer attack surface maps directly to several areas of the CSA AI Controls Matrix (AICM), which supersedes and encompasses the Cloud Controls Matrix. Supply chain integrity controls within the AICM address the requirement for verifiable provenance and integrity checking of software components integrated into AI and cloud workflows — the absence of which is precisely the gap that install-hook malware exploits. Organizations implementing AICM-aligned supply chain controls should review whether package-level integrity verification is enforced as a technical control rather than a policy recommendation.

The theft of AI provider credentials connects IronWorm directly to the threat model addressed by CSA’s MAESTRO framework for agentic AI systems. AI API keys stolen from a developer’s environment do not merely enable credential abuse against the AI provider’s billing infrastructure; they may also allow an adversary to impersonate the developer’s agentic AI workflows, issue requests to AI systems with the developer’s identity, or manipulate AI-assisted pipelines that rely on the stolen credentials for authentication. MAESTRO’s guidance on protecting the identity and authorization context of AI agents is applicable here: agent credentials should be isolated from the development environment credential store and issued through short-lived, scoped mechanisms rather than long-lived API keys stored in plaintext files [7].

CSA’s Software Transparency: Securing the Digital Supply Chain publication establishes the foundational framework for SBOM adoption, CI/CD pipeline security, and open source risk management that provides systemic protection against campaigns of this type. The Trusted Publishing abuse demonstrated by IronWorm underscores the SBOM guidance’s emphasis on verifying not only that a package is what it claims to be but also that the publishing identity behind new versions is authorized — a verification gap that automated dependency update workflows commonly leave unaddressed [8].

Zero Trust principles, articulated in CSA’s Zero Trust Guidance for Achieving Operational Resilience, apply directly to the credential management failures that IronWorm exploits. Storing broad-scope credentials — organization-wide GitHub tokens, unrestricted cloud provider access keys, or AI API keys without usage limits — in developer environment variables or dot-files violates least-privilege and need-to-know access principles. A Zero Trust-aligned credential architecture would issue short-lived, scoped, environment-specific credentials through a secrets manager or workload identity system rather than relying on persistent credentials stored on developer workstations or in CI configuration [9].

References

[1] JFrog Security Research. “IronWorm: Shai-Hulud’s Rustier Cousin.” JFrog, June 2026.

[2] Bleeping Computer. “New IronWorm Malware Hits 36 Packages in npm Supply-Chain Attack.” Bleeping Computer, June 2026.

[3] The Hacker News. “IronWorm and New Miasma Worm Variant Hit npm in Supply Chain Attacks.” The Hacker News, June 5, 2026.

[4] CyberSecurityNews. “IronWorm Supply Chain Attack Uses Malicious npm Packages to Steal Developer Secrets.” CyberSecurityNews, June 2026.

[5] Palo Alto Networks Unit 42. “‘Shai-Hulud’ Worm Compromises npm Ecosystem in Supply Chain Attack.” Unit 42, 2025.

[6] Andrea Fortuna. “eBPF rootkits and the Volatility blind spot in Linux memory forensics.” Andrea Fortuna Security Blog, May 27, 2026.

[7] Cloud Security Alliance. “Agentic AI Threat Modeling Framework: MAESTRO.” CSA, 2025.

[8] Cloud Security Alliance. “Software Transparency: Securing the Digital Supply Chain.” CSA Research, 2022.

[9] Cloud Security Alliance. “Zero Trust Guidance for Achieving Operational Resilience.” CSA, 2024.

[10] Dark Reading. “Rust-Written IronWorm Hits NPM Supply Chain.” Dark Reading, June 2026.

[11] Phoenix Security. “IronWorm (No CVE): Rust-Built npm Worm Ships an eBPF Rootkit, Tor C2, and a Self-Propagating Supply Chain Implant Across 37 Packages.” Phoenix Security, June 2026.

[12] DevOps.com. “IronWorm Malware Shares Shai-Hulud Traits, Takes Threat to ‘Next Level.’” DevOps.com, June 2026.