Case Study

How StepSecurity Helped Customers During the Shai-Hulud Supply Chain Attack

The “Sha1-Hulud: The Second Coming” attack was one of the most sophisticated and destructive NPM supply chain compromises of 2025. The malware targeted both CI/CD runners and developer workstations, exfiltrating secrets, installing malicious GitHub Actions runners, and creating public repositories containing stolen credentials. Within hours, over 21,000 repositories were compromised.

This case study explains how StepSecurity’s Prevent, Detect, and Respond capabilities gave customers early warning, deep visibility, and actionable guidance throughout the incident.

Early Detection: StepSecurity Identifies the Compromise Within Minutes

What happened

As soon as the malicious packages were published, they began executing a multi-stage attack during npm install The malware:

Installed Bun using a disguised dropper
Executed a 10MB obfuscated payload
Performed full environment reconnaissance
Exfiltrated AWS/GCP/Azure secrets, GitHub tokens, NPM tokens
Uploaded stolen data via GitHub’s API
Installed malicious self-hosted runners (“SHA1HULUD”)
Sought persistence and evasion

How StepSecurity helped

StepSecurity’s automated detection systems flagged the malicious packages within minutes of publication, well before widespread exploitation.
Customers with SIEM integration received real-time alerts via S3 and webhook delivery — no new setup required.
Threat Intelligence surfaced:
- Affected package names and versions
- Attack behavior
- IoCs (exfil domains, GitHub API patterns, Bun installer calls)
- Remediation guidance tailored to the customer’s environment

Many customers received StepSecurity alerts before public advisories existed, giving them time to triage and initiate remediation while the attack was still unfolding.

Preventing Compromise: StepSecurity Blocks Adoption of Malicious Versions

What happened

Developers began opening PRs that implicitly upgraded dependencies — including the newly compromised versions.

How StepSecurity helped

NPM Package Cooldown prevented customers from adopting the malicious versions The cooldown control (default: 2 days) automatically failed PRs introducing the compromised versions, because they were published only hours earlier.

NPM Package Compromised Updates flagged PRs that attempted to pull in the malicious versions Once the packages were confirmed malicious, StepSecurity automatically:

Marked them as compromised
Failed any PR upgrading to those versions
Provided clear explanations inside the PR checks

Customers who had cooldown or compromised-package protection enabled were fully shielded from accidentally merging the malicious updates.

Detecting Exploitation Attempts in CI/CD: Harden-Runner Surfaces Malicious Network Behavior

What happened

During CI execution, the malware:

Downloaded Bun from bun.sh
Downloaded TruffleHog
Uploaded multiple JSON files containing harvested secrets
Communicated with GitHub’s API to create attacker-owned repos
Installed self-hosted GitHub runners

All of this happened during the preinstall lifecycle hook.

How StepSecurity helped

Harden-Runner detected and flagged:

Calls to bun.sh, which were unexpected for typical builds
Calls to GitHub Contents API PUT endpoints, unusual for most workflows
Execution of background processes spawned via Bun.spawn()
Drops of large, obfuscated files
Outbound traffic that deviated sharply from expected baseline behavior

These anomalies appeared as clear alerts in the StepSecurity dashboard.

Example (public demo) https://app.stepsecurity.io/github/actions-security-demo/compromised-packages/actions/runs/19633853432?tab=network-events

If customers had egress policies enabled (egress-policy: block), Harden-Runner would have blocked the exfiltration entirely.

Identifying Where the Malicious Packages Were Introduced: NPM Package Search

What happened

Teams needed to answer:

Which PRs introduced the malicious packages?
Which repos are affected?
Did developers install these versions locally and commit lockfile changes?

How StepSecurity helped

Customers used NPM Package Search to:

Immediately find all PRs that upgraded to the compromised versions
Filter by repository or date
Identify exposure windows
Prioritize remediation across multiple teams

This made the blast-radius assessment nearly instantaneous — critical for a fast-moving worm like Shai-Hulud.

Investigating Whether Persistence Occurred: Baseline Monitoring Exposes Runner Installation

What happened

The malware silently installed a malicious GitHub Actions self-hosted runner named "SHA1HULUD" on compromised machines.

It then exploited GitHub Discussions to achieve trivial remote code execution.

How StepSecurity helped

Network baselines allowed customers to:

Detect unexpected runner registration calls
Identify workflow runs contacting new or suspicious endpoints
Highlight repos with unusual network destinations
Drill down into workflows that executed suspicious commands

Because baseline states include:

Stable (predictable)
Unstable (erratic changes)
Creating (learning baseline)

Any workflow suddenly contacting bun.sh, GitHub registration endpoints, or attacker infrastructure triggered immediate attention.

This helped customers confirm whether persistence was established.

Responding at Scale: Coordinating Remediation Across the Organization

What customers needed to do

Roll back compromised dependencies
Delete malicious repos created via stolen tokens
Rotate NPM, GitHub, and cloud credentials
Remove malicious self-hosted runners
Reinstall development environments
Patch CI workflows

How StepSecurity helped

Threat Center (for IoCs and official remediation steps)
NPM Package Search (to find all affected repos)
Harden-Runner Baselines (to confirm or rule out exploitation)

Customers could:

Identify priority repos
Validate whether exfiltration occurred
Confirm whether self-hosted runners were installed
Ensure that no repo still depended on the compromised versions
Verify no new suspicious outbound calls occurred in CI

This ensured a complete and consistent organization-wide response.

Verified Recovery: Ensuring No Remaining Risk

After remediation, customers used StepSecurity tools to confirm the incident was fully closed.

NPM Package Search — confirmed no repo still used malicious versions
Baselines — ensured no suspicious network behavior persisted
Threat Center — cross-referenced IoCs with workflow logs

Customers confidently validated:

No malicious package remained in dependency graphs
No unauthorized runners still existed
No outbound calls continued to bun.sh or attacker domains

PreviousRespond

Last updated 27 days ago

Was this helpful?