Threat Intel

IronWorm: Self-Spreading Linux Credential Theft and Supply Chain Risk

Malware attack chain showing credential theft from developer workstation to supply chain compromise.

The Threat Changed: Your Workstation Is Your Supply Chain

A developer's machine gets compromised. Credentials are stolen—SSH keys, cloud tokens, npm publishing credentials. The attacker uses those stolen tokens to push malicious code to dependencies. The developer's next package update reaches thousands of users, and none of them know their build system is now compromised.

This is IronWorm. Not a simple credential stealer. Not a one-off attack. A self-spreading supply chain weapon designed to turn developer trust into automated infrastructure compromise.

What IronWorm Does

IronWorm is a malware campaign targeting npm and Linux developers with surgical precision. It ignores browser history, personal files, and standard user data. It hunts for one thing: digital keys.

SSH keys: Access to internal repositories and production systems.

Cloud tokens: AWS, GCP, Azure credentials with broad permissions.

Package publishing credentials: npm tokens, GitHub publishing access, registry credentials.

Once stolen, those credentials become a launchpad. The attacker doesn't just compromise one machine. They compromise the software you publish, the infrastructure you build, and every downstream user of your code.

Researchers found IronWorm inside dozens of malicious npm packages on the public registry, distributed directly to developers.

Why IronWorm Is Different

Most malware follows a predictable cycle: infect, scrape, persist. IronWorm is engineered for expansion.

The traditional attack: Attacker compromises one workstation, steals what they can, moves laterally.

The IronWorm attack:

Attacker compromises developer's workstation (or pushes malicious npm package)
Malware harvests SSH keys, cloud tokens, publishing credentials
Attacker uses stolen credentials to compromise additional packages
Malware spreads through your dependency tree
Each downstream developer becomes a new victim
The cycle repeats at scale

This is not credential theft. This is automated supply chain assault. The attacker weaponizes your own reputation to lure the next target.

Who's at Risk?

Linux Developers

Linux workstations are not just office computers. They're development hubs holding:

SSH keys to internal repositories
Cloud credentials (AWS keys, GCP service accounts)
Git tokens with high permissions
Container registry credentials
Deployment keys

A compromised Linux development machine is not just a data loss incident. It's a bridge into your entire infrastructure.

Linux Build Servers and CI/CD Pipelines

Build servers are the engine room of software delivery. They run GitHub Actions, GitLab CI, Jenkins, or custom build automation. If IronWorm compromises a machine managing build infrastructure:

Attacker gains ability to tamper with software before release
CI/CD artifacts become trusted attack vectors
Every build is potentially compromised
Detection is difficult (builds look normal, just with injected malicious code)

Open Source Maintainers

If you maintain public packages, you're a primary target. IronWorm specifically hunts for npm publishing tokens. Once stolen:

Attacker pushes malicious code under your name
Downstream users trust the update (it came from you)
Compromise reaches anyone using your package
Your reputation is weaponized against your users

Trust is the hardest thing to build in open source. IronWorm is engineered to destroy it.

The eBPF Rootkit Connection

Beyond credential theft, IronWorm adds a persistence layer using eBPF (extended Berkeley Packet Filter).

eBPF is a powerful Linux kernel technology typically used for:

Network monitoring and performance tuning
Security observability and intrusion detection
System call tracing and profiling

The attacker realized the same power that lets security tools inspect the kernel also lets malware hide. By leveraging eBPF, IronWorm:

Manipulates system calls at the kernel level
Bypasses traditional monitoring and detection
Hides its own processes and network activity
Remains stealthy while harvesting credentials

This is not user-space malware that shows up in ps aux output. This is kernel-level persistence that requires specialized eBPF-aware monitoring to detect.

The Broader Supply Chain Problem

IronWorm is not an isolated incident. It's part of a trend in which attackers target trusted software distribution channels rather than individual users.

XZ Utils backdoor (2024): Compromise inserted directly into a trusted open-source project, rippling through Linux distributions and enterprises.

SolarWinds (2020): Legitimate supply chain attack injected into trusted software updates.

IronWorm (2026): Steals developer credentials to compromise additional packages, turning maintainers into unwitting delivery vectors.

The strategy shifts, but the goal remains: abuse trust to reach as many downstream systems as possible.

Detection Signals

IronWorm is designed to stay hidden, but behavioral signals exist:

On compromised workstation:

Unusual file access to ~/.ssh, ~/.aws, ~/.config/npm
Unexpected child processes from package managers
Outbound connections to unknown IP addresses
Recent SSH key generation or credential rotation
New entries in .ssh/authorized_keys

In build pipelines:

Unexpected changes to build artifacts
Build logs showing unusual commands or downloads
Modified environment variables or secrets
Failed credential validation (attacker tried but failed)

In package repositories:

Sudden version bumps or unexpected releases
Code changes that don't match commit history
New dependencies or build scripts
Artifacts built with unusual tools or configurations

⚠️ eBPF-level detection is hard without specialized monitoring. Standard tools like auditctl may not see eBPF rootkit activity.

Immediate Actions

1. Audit Dependencies

Review your package.json, package-lock.json, and dependency trees:

npm list --depth=0
npm audit

Look for:

Recently added dependencies with unclear purpose
Unusual package names (typosquatting variants)
Packages from unknown maintainers
Recent version changes that introduced new code

2. Rotate All Secrets

Assume every credential on an affected machine has been exposed:

# Rotate SSH keys
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_new -N ""
# Back up old key, replace with new

# Rotate cloud credentials
aws iam create-access-key --user-name $USERNAME
aws iam delete-access-key --user-name $USERNAME --access-key-id $OLD_KEY

# Rotate npm publishing tokens
npm token revoke $TOKEN
npm token create

3. Restrict Token Scope

Move away from long-lived master keys:

npm: Use granular publish tokens scoped to specific packages
Git: Use short-lived deploy keys with read-only access where possible
Cloud: Use IAM roles with least-privilege permissions, not long-lived credentials
SSH: Use certificate-based authentication with short validity periods instead of key pairs

4. Isolate CI/CD Infrastructure

Build runners should not persist secrets on disk:

# In GitHub Actions, use OIDC to assume temporary AWS role (no keys stored)
# In GitLab CI, use CI_JOB_JWT_V2 to request temporary tokens
# In Jenkins, use Vault integration to fetch secrets at build time (not persisted)

5. Monitor eBPF Activity

Configure detection for unauthorized eBPF loading:

# auditctl rule to log eBPF programs
auditctl -a always,exit -F arch=b64 -S bpf -k ebpf_programs
ausearch -k ebpf_programs | grep -v "^type=CONFIG_CHANGE"

For kernel 5.8+, watch /sys/kernel/debug/tracing/trace_pipe for unexpected eBPF activity.

6. Enforce Least Privilege

Developer accounts should not have direct access to production systems
Build service accounts should have only the permissions needed for that specific build
Separate credentials for local development vs CI/CD vs production
Use temporary credentials (assume-role, STS tokens) instead of permanent keys

7. Monitor Credential Access

Track when credentials are read or modified:

# Monitor ~/.ssh access
auditctl -w ~/.ssh -p wa -k ssh_key_access

# Monitor ~/.aws access
auditctl -w ~/.aws -p wa -k aws_credential_access

# Monitor npm credentials
auditctl -w ~/.npmrc -p wa -k npm_token_access

The Real Risk: Credentials Over Code

For defenders, the interesting part isn't the Linux infection itself. It's the focus on credentials.

Once an attacker has access to developer tokens, SSH keys, and deployment accounts, the scope of the incident changes instantly. A compromised workstation is contained. A compromised development pipeline is an existential problem.

The question is no longer "was the malware found?" The question is "what credentials did it steal, and how far did it spread?"

Supply Chain Resilience

No single tool solves this. Resilience comes from:

Assumption: Workstations will be compromised at some point
Defense: Assume developer credentials are leaked; design systems that don't rely on them being secret forever
Detection: Monitor for credential usage patterns, not just compromise
Isolation: Build infrastructure that doesn't let one compromised machine reach everything
Verification: Verify software artifacts independently, don't trust the build system alone