By Korben Kirscht, MSCIA
The software supply chain is under siege again. In late November 2025, security researchers detected a sophisticated evolution of the "Shai-Hulud" malware—a self-replicating worm targeting the npm ecosystem. Dubbed "The Second Coming" by its operators, this variant (V2) is far more aggressive and resilient than its predecessor observed in September.
This is not a standard malware infection; it is an automated worm that weaponizes developer accounts to infect legitimate software packages, steal cloud secrets, and establish persistent backdoors. Most alarmingly, it features a "dead man's switch" designed to wipe user data if the infection is contained.
Here is a deep dive into how Shai-Hulud V2 operates and the critical steps security teams must take to defend their environments.
The Evolution: From V1 to V2
The original Shai-Hulud attack, detected in mid-September 2025, utilized postinstall scripts to execute Node.js payloads. The V2 variant represents a major escalation in tactics:
- Preinstall Execution: V2 executes during the
preinstallphase rather thanpostinstall. This means the malicious code runs before the package installation completes, triggering even if the installation eventually fails. - The Bun Loader: Instead of relying solely on Node.js, the malware downloads and installs Bun, a legitimate JavaScript runtime, via a loader script named
setup_bun.js. It uses this runtime to execute a heavy, 10MB obfuscated payload calledbun_environment.js. - Exfiltration via GitHub: While V1 relied on external webhooks (which were easily rate-limited), V2 exfiltrates stolen data by creating public GitHub repositories with the description "Sha1-Hulud: The Second Coming". This allows the traffic to blend in with legitimate GitHub API usage.
The Kill Chain: How It Works
Once a developer or CI/CD pipeline installs an infected package (such as compromised versions of Zapier, Postman, or AsyncAPI libraries), the worm initiates a multi-stage attack:
- Credential Harvesting: The malware scans for credentials using an embedded version of TruffleHog. It targets:
- GitHub Personal Access Tokens (PATs) and OAuth tokens.
- npm publishing tokens from
.npmrcfiles. - Cloud credentials for AWS, Azure, and GCP (scanning environment variables, config files, and metadata services).
- Persistence & Backdoors: The malware registers the infected machine as a self-hosted GitHub Actions runner named "SHA1HULUD". It also injects a malicious workflow file (e.g.,
.github/workflows/discussion.yaml) that contains a command-injection vulnerability, allowing the attacker to execute code by posting in the repository's "Discussions" section. - Self-Replication: Using stolen npm tokens, the worm downloads other packages maintained by the victim, injects the
setup_bun.jsloader, increments the version number, and republishes them to the registry.
The "Dead Man's Switch": A Destructive Failsafe
Perhaps the most dangerous feature of Shai-Hulud V2 is its destructive failsafe. The malware continuously monitors its access to GitHub (for exfiltration) and npm (for propagation).
If the malware detects that it has lost access to both channels—implying the victim is attempting containment—it triggers a wiper function.
- On Windows: It attempts to delete user profiles and overwrite disk sectors using
cipher /W. - On Linux/macOS: It uses the
shredcommand to overwrite files in the home directory before deleting them, making forensic recovery nearly impossible.
Immediate Incident Response
If you detect Indicators of Compromise (IoCs) such as files named setup_bun.js, cloud.json, or repositories with "Sha1-Hulud" in the description, follow this strict order of operations to prevent data destruction and re-infection.
1. Containment (Do NOT Delete Yet) Do not immediately delete the malicious GitHub repositories created by the worm. Instead, change their visibility to Private. Deleting them immediately removes forensic evidence needed to identify exactly which secrets were stolen.
2. Eradication
- Neutralize Runners: Navigate to GitHub Settings > Actions > Runners and remove any self-hosted runner named SHA1HULUD.
- Remove Workflows: Delete malicious workflow files like
discussion.yamlorformatter_*.yml. - Clean Environment: Remove
node_modulesand clear the npm cache (npm cache clean --force).
3. Remediation (Credential Rotation) Only after the malware is removed should you rotate credentials. If you rotate keys while the worm is active, it will simply steal the new keys.
- Decode the exfiltrated JSON files (found in the malicious repo) to see exactly what was exposed.
- Rotate ALL GitHub PATs, npm tokens, and cloud keys (AWS, Azure, GCP) found in those files.
Long-Term Defenses
To defend against the next iteration of supply chain worms, organizations must harden their development pipelines:
- Pin Dependencies: Use lockfiles (
package-lock.jsonoryarn.lock) to ensure deterministic installations and prevent the automatic pulling of compromised new versions. - Enforce MFA: Require phishing-resistant Multi-Factor Authentication for all developer accounts on npm and GitHub.
- Audit Pipelines: regularly audit GitHub Actions for unauthorized workflows or runners.
Conclusion
Shai-Hulud V2 demonstrates that threat actors are moving beyond simple credential theft toward resilient, automated botnets that live inside the software supply chain. The introduction of destructive wipers and preinstall execution requires a shift in how we secure developer endpoints and CI/CD environments.
Analogy: Think of Shai-Hulud not as a burglar breaking into a house, but as a parasitic vine infecting a shipment of seeds. When a farmer (developer) plants these seeds (packages), the vine doesn't just grow; it immediately steals the keys to the farm (credentials), unlocks the gates for more vines, and sends seeds to every other farm the farmer does business with. Worse, if the vine senses the farmer trying to cut it down, it releases a toxin that salts the earth (the wiper), destroying the field entirely.
No comments:
Post a Comment