IronWorm

JFrog identified the activity while investigating suspicious behavior linked to a developer account within the Arweave/WeaveDB open source ecosystem.

The campaign, which JFrog has dubbed "IronWorm," targets developers through compromised npm publishing workflows and malicious package updates.

The attack is built to spread itself through trusted developer workflows... When the malware runs inside a CI environment, it uses npm’s own Trusted Publishing flow to get short-lived publish credentials.

The developer or CI runner executes npm install ... The preinstall script ./tools/setup fires before npm resolves dependencies. No build step, no manual confirmation, no user interaction. | The supported command set is intentionally small: upload extracted credentials, drop a file from the attacker-controlled server, or execute a remote shell command on the infected host.

The package.json gave away the trick: { "scripts" : { "preinstall" : "./tools/setup" } } preinstall runs before npm even starts resolving dependencies.

The package.json gave away the trick: { "name" : "weavedb-sdk" , "version" : "0.45.3" , "scripts" : { "preinstall" : "./tools/setup" } } preinstall runs before npm even starts resolving dependencies. Type npm install , and the binary executes

If the repository shipped a package -npm, PyPI, Cargo, Conan, or vcpkg(C++) - the malware took a more direct route: it dropped a binary into the project and modified the build system to execute it.

JFrog identified the activity while investigating suspicious behavior linked to a developer account within the Arweave/WeaveDB open source ecosystem.

One of them targets the Exodus desktop wallet by injecting a JavaScript hook into the application... Its goal is not subtle: capture the wallet password and seed mnemonic.

JFrog identified the activity while investigating suspicious behavior linked to a developer account within the Arweave/WeaveDB open source ecosystem.

The security vendor's analysis showed IronWorm uses a rootkit that abuses the Linux kernel's extended Berkeley Packet Filter (eBPF) to hide malicious processes, files, network activity, and other behavior from security systems.

The sample was a Linux ELF executable packed with a lightly modified UPX stub... The sample also hid most of its useful strings... each call site used its own parameters.

This was committed under the author name claude <claude@users.noreply.github.com> , mimicking an AI coding assistant... Workflow commits are using a rotating cast of familiar automation identities - dependabot , renovate , github-actions | The payload was placed under an innocuous-looking path such as tools/setup or .github/scripts/precheck . This was committed under the author name claude <claude@users.noreply.github.com> ... Workflow commits are using a rotating cast of familiar automation identities - dependabot , renovate , github-actions.

the disassembly confirmed the trick: the malware copies the timestamp of the repository's most recent real commit, so the malicious change appears to have been made whenever the project was last legitimately touched.

JFrog identified the activity while investigating suspicious behavior linked to a developer account within the Arweave/WeaveDB open source ecosystem.

The rootkit parses /proc/net/tcp as it is read and removes rows belonging to hidden sockets. Similar filtering applies to the netlink interface used by ss, so the implant’s Tor connections disappear | The rootkit hides processes by rewriting /proc directory listings in place, removing PIDs on a hidden-set watchlist before userland tools can see them.

When anything in /proc was listed , the rootkit rewrote the results in place, removing hidden PIDs before userland tools could see them. | The same hiding strategy extended to the network. The rootkit parsed /proc/net/tcp as it was read and removed rows belonging to hidden sockets. It also applied similar filtering to the netlink interface used by tools like ss

The rootkit parsed /proc/net/tcp as it was read and removed rows belonging to hidden sockets. It also applied similar filtering to the netlink interface used by tools like ss

If the repository shipped a package -npm, PyPI, Cargo, Conan, or vcpkg(C++) - the malware took a more direct route: it dropped a binary into the project and modified the build system to execute it.

Then came the anti-debugging logic. Attempts to ptrace a protected process were answered with SIGKILL . In practice, trying to strace the malware could kill the shell running the command.

One of them targets the Exodus desktop wallet by injecting a JavaScript hook into the application... Its goal is not subtle: capture the wallet password and seed mnemonic.

The credential sweep is exhaustive. The binary reaches for 86 environment variables spanning every major platform... source-control and package-registry tokens, CI/CD systems, messaging platforms, Vault and Kubernetes. | If the repository already had GitHub Actions workflows... it replaced an existing one -swapping a real workflow for a secret-exfiltration job... The ${{ toJSON(secrets) }} expression serializes the secrets available to the workflow run into a single value

The malware scans for 86 different environment variables covering cloud platforms, databases, CI/CD systems, source control tokens, and AI service API keys. It also reads more than 20 credential file paths from disk, including wallet configs and authentication files.

The binary reaches for 86 environment variables spanning every major platform a developer touches: the cloud providers, object storage, databases, source-control and package-registry tokens, CI/CD systems

It goes after files, too: more than twenty credential paths, including ones for tools that barely existed a year ago ... alongside the classics like ~/.aws/credentials , ~/.kube/config , and ~/.docker/config.json . | The credential sweep is exhaustive... It goes after files, too: more than twenty credential paths, including... ~/.aws/credentials , ~/.kube/config , and ~/.docker/config.json

One of them targets the Exodus desktop wallet by injecting a JavaScript hook into the application... Its goal is not subtle: capture the wallet password and seed mnemonic.

The malware, written in Rust, harvests a wide range of developer secrets, including API keys, cloud credentials, SSH keys, and npm publishing tokens, and reuses them to spread further across the software supply chain.

Another, running inside a Kubernetes pod, reads the service-account token, walks the namespaces, and dumps every Secret it can reach and if it finds a Vault instance, it logs in with that same token and enumerates the secret backends.

Another, running inside a Kubernetes pod, reads the service-account token, walks the namespaces, and dumps every Secret it can reach

Then came the anti-debugging logic. Attempts to ptrace a protected process were answered with SIGKILL . In practice, trying to strace the malware could kill the shell running the command.

The ${{ toJSON(secrets) }} expression serializes the secrets available to the workflow run into a single value; the next step writes it to a file with a harmless-looking name.

Then it beacons out to an endpoint called /api/agent , and waits for orders. The conversation itself is plain HTTP wrapped inside the Tor tunnel

Then it beacons out to an endpoint called /api/agent ... The conversation itself is plain HTTP wrapped inside the Tor tunnel

For its command channel, the malware downloads the Tor expert bundle and its libraries, writes its own torrc , starts the daemon, and waits for the circuit to come up.

The commands are limited: uploading extracted secrets, drop the file from the malicious controlled server or running a remote shell on the infected machine.

The commands are limited: uploading extracted secrets... Another piece of code suggests a possible fallback path... The agent uploads it to temp.sh ... and reports the resulting link back over C2.

The agent uploads it to temp.sh , a public file host, which is tunneled through the same Tor circuit, and reports the resulting link back over C2. | the final step uploads that file as a build artifact, where it can be downloaded by anyone with sufficient access... Another piece of code suggests a possible fallback path... The agent uploads it to temp.sh , a public file host