Dev

IronWorm Targets npm Supply Chain, Infecting 36 Packages

Rust-based malware IronWorm infects 36 npm packages. Details on its use of eBPF rootkits, Tor communication, and credential theft, along with countermeasures.

6 min read Reviewed & edited by the SINGULISM Editorial Team

IronWorm Targets npm Supply Chain, Infecting 36 Packages
Photo by Shubham Dhage on Unsplash

A new attack targeting the software supply chain has come to light. According to a report from supply chain and DevOps company JFrog on June 4, the Rust-based information-stealing malware named IronWorm has been confirmed to have infected 36 packages in the npm registry.

The attack targets developers and CI (Continuous Integration) environments, aiming to steal credentials and propagate itself through advanced techniques. Based on reporting by BleepingComputer, here are the details of the incident.

Overview of the Attack

IronWorm, discovered by JFrog researchers, is a multi-layered attack that goes beyond merely contaminating packages. According to BleepingComputer, this malware specifically targets 86 environment variables (key-value pairs) and 20 credential files.

The targets include credentials for OpenAI, AWS, Anthropic, npm, Vault configuration files, SSH keys, and Exodus cryptocurrency wallet files. Notably, the inclusion of API keys for AI services like OpenAI and Anthropic reflects the ongoing AI boom.

Threats Posed by Rust and eBPF

The technical features of IronWorm that stand out are its programming language and obfuscation techniques.

Cross-Platform Versatility of Rust

The core malware is written in Rust, a language known for its strong memory safety features and high performance. While these characteristics have drawn positive attention to Rust, they also benefit attackers. The malware’s implementation in Rust allows it to operate across various platforms, including Linux, macOS, and Windows, enabling broader deployment across diverse development environments.

Concealment through eBPF Rootkit

IronWorm also hides behind a eBPF (extended Berkeley Packet Filter)-based kernel-level rootkit. eBPF is a technology designed to safely extend the functionality of the Linux kernel, but when exploited, it can be used to conceal processes and network communication at the kernel level. This makes detection by conventional user-space security tools significantly more challenging.

Communication via Tor Network

Communication between the malware and its C2 (Command and Control) server is routed through the Tor network. By using Tor, the source IP address is concealed, making it extremely difficult to trace. The communication is also believed to be encrypted, further complicating the task of identifying the C2 server through network monitoring.

Smart Design with Self-Replication

The most dangerous aspect of IronWorm is its ability to self-replicate.

Exploiting npm’s Trusted Publishing

The malware steals credentials used for publishing packages on npm. It specifically targets secrets related to npm’s recommended Trusted Publishing workflow, which uses OIDC (OpenID Connect) to enable direct publishing from CI/CD pipelines to npm. With stolen tokens, the attacker can publish packages as if they were a legitimate developer.

Chain of Infection

Once a developer or CI environment is compromised, IronWorm uses the victim’s npm account to publish a Trojanized version of the package. When another developer installs this package, their environment becomes infected as well, creating a chain reaction of infection. BleepingComputer has described this as a “chain of viral infection within the supply chain.”

Connections to Shai Hulud

This attack bears similarities to malware recently published on GitHub, known as Shai Hulud. While JFrog researchers have not found a direct link between the two, they have observed that both attacks use the same commit names.

This suggests that IronWorm may be an evolved payload from a group known as TeamPCP, which has previously conducted supply chain attacks targeting npm and PyPI. According to researchers, IronWorm appears to be “a custom, carefully developed implant by an organization with its own infrastructure”, indicating this is far from the work of amateur hackers.

Affected Packages and Visibility

JFrog’s report includes a full list of the affected package names and versions. Developers are advised to immediately check if their projects use any of the listed packages.

At the same time, Endor Labs and StepSecurity have identified another attack deployed around the same period. This separate attack involves a JavaScript-based malware called binding.gyp, which targets registry poisoning and GitHub Actions. While unrelated to IronWorm, the timing highlights the multi-faceted attacks currently targeting the npm ecosystem.

In light of this attack, JFrog recommends that developers and organizations immediately implement the following measures:

Upgrade to Fixed Versions

Most affected packages already have patched versions available. The first step is to update project dependencies to the latest secure versions and regenerate lock files like package-lock.json or yarn.lock.

Rotate Credentials

Since IronWorm targets credentials for services like OpenAI, AWS, and Anthropic, these keys may have been compromised. All potentially affected credentials should be replaced with new ones. This includes tokens and secrets used in CI/CD pipelines, whether or not a leak has been confirmed.

Enable Multi-Factor Authentication (2FA)

Enable multi-factor authentication for all accounts, including npm accounts. With 2FA enabled, even if passwords or tokens are compromised, unauthorized access to accounts can be significantly reduced.

Audit CI Environments

Review CI/CD pipelines (e.g., GitHub Actions, GitLab CI/CD, CircleCI) to ensure that no unnecessary permissions have been granted. If using Trusted Publishing, reassess how tokens are managed and secured.

Editorial Perspective

Short-Term Impact: The IronWorm attack poses an immediate threat to the npm ecosystem. With 36 contaminated packages, some of them potentially popular, the actual scope of the impact could be broader than initially expected. In the coming weeks, expect a flurry of updates to remove malicious code from affected applications. Additionally, the use of eBPF rootkits—a relatively new technology in supply chain attacks—will prompt security vendors to accelerate the development of eBPF-based malware detection methods. Organizations should waste no time in scanning their used packages and reviewing dependencies.

Long-Term Implications: This incident raises fundamental concerns about the trustworthiness of the software supply chain. While traditional package managers and CI/CD pipelines have improved productivity, features like Trusted Publishing inadvertently create new attack vectors. Over the next one to two years, there may be an increased focus on implementing stricter package signing protocols, alternative registries to npm, and the adoption of Rust-based security tools. Furthermore, the targeting of API keys for AI services may prompt startups and major corporations to introduce new authentication management policies to protect their AI assets.

Questions for the Community: A key concern from this incident is how 36 packages were simultaneously infected, who created them, and why they remained undetected for so long. While evidence links IronWorm to Shai Hulud via shared commit names, the direct relationship remains unclear. The community must strive to determine whether these malwares are the work of the same threat actor or if different groups are replicating similar techniques. Readers are encouraged to consider enhancing their CI/CD pipeline monitoring and implementing multi-layered verification processes for package publishing as preventive measures.

References

Frequently Asked Questions

What is IronWorm?
IronWorm is an information-stealing malware written in Rust and discovered by JFrog researchers. It has infected 36 npm packages, targeting credentials for services like OpenAI, AWS, and Anthropic. It hides using eBPF rootkits and communicates with its command-and-control server via the Tor network.
How can I check if my packages are affected?
JFrog has published a report listing all affected package names and versions. Check your project’s `package-lock.json` or `yarn.lock` files to verify if any listed packages are in use.
What actions should developers take?
Developers should upgrade affected packages to their patched versions, rotate all potentially compromised credentials, enable multi-factor authentication (2FA) on all accounts, and audit CI/CD pipelines to ensure no excessive permissions are granted.
Source: Slashdot

Comments

← Back to Home