Listen to this Post
Introduction:
The software supply chain is under siege by a new breed of self-propagating worm that doesn’t just steal secrets—it weaponizes them to spread across registries, repositories, and CI/CD pipelines in minutes. The Mini Shai-Hulud malware family, along with its Miasma and Hades variants, has escalated from targeting npm packages to compromising GitHub Actions workflows, PyPI ecosystems, and even Go modules, all while evading traditional security tooling through a novel technique called “Phantom Gyp.” This campaign represents a fundamental shift in supply chain attacks: attackers are no longer just injecting code; they are building autonomous worms that propagate using the very credentials they steal.
Learning Objectives:
- Understand the technical mechanics of the Phantom Gyp attack vector and how it bypasses npm’s traditional security controls.
- Identify the full attack chain—from registry poisoning and Bun-staged JavaScript loaders to GitHub Actions abuse and AI coding assistant persistence.
- Learn actionable detection, mitigation, and remediation strategies to protect developer workstations, CI/CD environments, and package registries from self-propagating supply chain worms.
You Should Know:
- Phantom Gyp: The 157-Byte File That Broke npm Security
The cornerstone of this attack wave is a technique security researchers have named “Phantom Gyp.” Instead of hiding malicious code in the commonly monitored `preinstall` or `postinstall` scripts within package.json, the attacker weaponized a tiny, often-overlooked file: binding.gyp.
Here’s how it works: When npm detects a `binding.gyp` file in a package’s root directory—and the `package.json` does not specify custom install scripts—it automatically invokes `node-gyp rebuild` to compile what it assumes is native C/C++ code. The attacker exploited this by embedding a shell command directly into the `binding.gyp` file using gyp’s own command substitution syntax. This 157-byte file silently launches a malicious payload while returning a fake source filename, so the build process shows no errors.
Step-by-Step Guide: What This Does and How to Use It (for Defenders)
- Detection: Scan your `node_modules` and lockfiles for any `binding.gyp` files that do not correspond to legitimate native addons. Compare the file size—malicious `binding.gyp` files are often suspiciously small (around 157 bytes).
- Inspection: Examine the contents of any `binding.gyp` file for shell commands or unusual substitution syntax. A typical benign file contains JSON-like configuration, not embedded commands.
- Prevention: Implement a policy that blocks or quarantines npm packages containing `binding.gyp` files unless they are explicitly whitelisted from trusted sources. Use tooling that scans the entire package tarball, not just
package.json. - Linux Command (Audit): Recursively find all `binding.gyp` files in your project and check their contents for suspicious commands:
find . -1ame "binding.gyp" -exec grep -l "exec|eval|sh|curl|wget" {} \; - Windows Command (Audit):
Get-ChildItem -Recurse -Filter "binding.gyp" | Select-String -Pattern "exec|eval|sh|curl|wget"
2. The Multi-Stage Payload: Bun, Obfuscation, and Evasion
Once the `binding.gyp` file triggers execution, it launches a JavaScript loader that initiates a sophisticated multi-stage payload. The initial loader is heavily obfuscated—buried under four layers of obfuscation including a ROT cipher and AES-128-GCM encryption. This loader then checks if the Bun JavaScript runtime is installed; if not, it downloads and installs it in under one second.
The use of Bun is a critical evasion tactic. By executing the final credential-stealing payload outside of Node.js, the malware specifically bypasses security tooling that only monitors Node.js process activity. The final stage is a 4.5 MB obfuscated script (compared to a legitimate 27 KB entry point) that operates as a comprehensive credential harvester.
Step-by-Step Guide: What This Does and How to Use It (for Defenders)
- Detection: Monitor for unexpected downloads or executions of the Bun runtime (
bunorbun.exe) in your development and CI/CD environments. Alert on any process that downloads and executes unsigned binaries from the internet. - Inspection: Analyze network logs for outbound connections to
api.anthropic[.]com:443/v1/api—the malware’s encrypted exfiltration endpoint. Also monitor for commits to public GitHub repositories with descriptions like “Alright Lets See If This Works” or “Miasma: The Spreading Blight.” - Prevention: Restrict outbound internet access from CI/CD runners and build containers to only essential services. Implement application allowlisting to prevent execution of unsigned binaries like Bun.
- Linux Command (Monitor for Bun):
ps aux | grep -i bun
- Windows Command (Monitor for Bun):
Get-Process -1ame "bun" -ErrorAction SilentlyContinue
3. GitHub Actions Abuse and OIDC Token Theft
The worm’s propagation mechanism is where it becomes truly dangerous. After harvesting credentials, the malware aggressively targets GitHub Actions environments. It drops a workflow named “Run Copilot” that captures CI/CD environment secrets directly from the runner’s memory. It also calls the OIDC token exchange endpoints, repackages malicious tarballs, and signs the artifacts through Sigstore, giving the poisoned packages valid SLSA Build Level 3 provenance attestations.
This is a game-changer: the malicious packages appear to come from legitimate sources with verifiable signatures, defeating the highest tier of supply-chain integrity verification. The attacker then uses the stolen OIDC tokens and Personal Access Tokens to publish poisoned versions of every package the victim maintains and inject malicious steps into every CI workflow they can reach.
Step-by-Step Guide: What This Does and How to Use It (for Defenders)
- Detection: Audit your GitHub Actions workflow logs for unexpected workflow runs, especially those named “Run Copilot” or similar generic names. Review the `action.yml` or `action.yaml` files in your repositories for unauthorized changes.
- Inspection: Check your GitHub organization’s OIDC configuration. Ensure that trusted publisher policies are tightly scoped and that tokens cannot be used to publish to namespaces they shouldn’t access.
- Prevention: Implement branch protection rules that require human review and approval for any changes to GitHub Actions workflows. Use environment protection rules with required reviewers for production deployments.
- GitHub CLI Command (List Recent Workflow Runs):
gh run list --limit 50
- GitHub API Command (Check for Suspicious Workflows):
curl -H "Authorization: token YOUR_TOKEN" https://api.github.com/repos/OWNER/REPO/actions/workflows
- AI Coding Assistant Persistence: The Backdoor That Won’t Die
The Miasma campaign’s third wave introduced a significant escalation: persistence mechanisms that target AI coding assistants. The malware injects a `SessionStart` hook into Anthropic Claude Code and creates a `tasks.json` file with `”runOn”: “folderOpen”` for Microsoft Visual Studio Code projects. This means the malware is automatically launched every time a developer opens the compromised project in their IDE or AI assistant.
This persistence mechanism is particularly insidious because it survives package removal entirely. Even if the developer uninstalls the malicious package, the backdoor configuration remains in their AI assistant or IDE settings, continuing to steal credentials and exfiltrate data. The malware also polls GitHub every hour for commits matching the string “firedalazer” to retrieve and execute the Hades variant, ensuring the worm can update itself and receive new commands.
Step-by-Step Guide: What This Does and How to Use It (for Defenders)
- Detection: Check your `~/.config/claude/` directory for unexpected `session-start.sh` or similar hooks. In VS Code, inspect the `.vscode/tasks.json` file for tasks with `”runOn”: “folderOpen”` that you did not create.
- Inspection: Review your AI assistant’s configuration files and VS Code workspace settings for any unauthorized commands or scripts.
- Remediation: Delete any suspicious hook files or tasks. Rotate all credentials from a clean machine—do not trust any machine that has been compromised.
- Linux Command (Check Claude Hooks):
cat ~/.config/claude/session-start.sh
- Linux Command (Check VS Code Tasks):
find . -1ame "tasks.json" -exec grep -l "\"runOn\"" {} \;
5. The Russian Locale Killswitch and Self-Destruction
The malware contains several defensive mechanisms to evade analysis. It avoids execution on Russian-language systems, a pattern also observed in the GlassWorm supply chain campaigns. This killswitch is likely designed to avoid attracting attention from Russian-speaking threat actors or security researchers.
Even more alarming is the worm’s self-destruction capability: it contains a tripwire that wipes the home directory (rm -rf ~/) if a planted decoy token is touched. This means that any attempt to investigate or contain the infection could trigger a destructive payload that erases the developer’s entire workstation.
Step-by-Step Guide: What This Does and How to Use It (for Defenders)
- Detection: If you suspect a compromise, do not run any commands or touch any files on the affected machine. Isolate the machine from the network immediately.
- Investigation: Use a read-only forensic image or a separate analysis machine to examine the compromised system. Do not execute any commands that could trigger the tripwire.
- Remediation: The only safe course of action is to wipe the compromised machine completely and rebuild it from a known-good image. Rotate all credentials that were present on the machine from a separate, clean system.
- Linux Command (Safe Investigation – Do Not Run on Compromised Host):
Use a forensics tool like Autopsy or FTK Imager to create a disk image Analyze the image in a sandboxed environment
What Undercode Say:
- Key Takeaway 1: The public open-sourcing of the Mini Shai-Hulud toolchain by TeamPCP has democratized supply chain attacks, enabling any actor to replicate these campaigns. The barrier to entry for sophisticated supply chain compromise has effectively dropped to zero.
- Key Takeaway 2: Traditional security controls are failing. Phantom Gyp bypasses install-script monitoring, Bun execution evades Node.js process monitoring, and SLSA-signed packages defeat integrity verification. Organizations must adopt a defense-in-depth approach that includes behavioral detection, network monitoring, and strict access controls.
Analysis:
The Mini Shai-Hulud, Miasma, and Hades campaign represents a watershed moment in software supply chain security. The attack is not just technically sophisticated—it is operationally industrial. The stolen Red Hat credential sat in infostealer logs for seven weeks before weaponization, highlighting the emerging “Developer Credential Economy” where stolen credentials are traded and stockpiled for future attacks. The worm’s ability to propagate autonomously using stolen credentials, combined with its persistence mechanisms in AI coding assistants, means that a single compromised package can cascade into a widespread organizational breach within hours. The fact that the malware produces valid SLSA provenance attestations is particularly concerning, as it undermines trust in one of the most promising supply chain security frameworks. Organizations must shift from a reactive “detect and respond” posture to a proactive “harden and assume breach” mindset, treating developer credentials as critical control-plane infrastructure.
Prediction:
- +1 The public disclosure and analysis of these attacks will accelerate the development of next-generation supply chain security tools, including AI-powered behavioral detection that can identify anomalous installation patterns and runtime behaviors.
- -1 The open-sourcing of the Mini Shai-Hulud toolchain will lead to a proliferation of copycat attacks, with threat actors of all skill levels launching similar campaigns across npm, PyPI, and other package registries.
- -1 AI coding assistants will become a primary target for supply chain attacks, as their persistence mechanisms and access to developer credentials make them ideal backdoors for long-term espionage.
- +1 The industry will see increased adoption of zero-trust principles for CI/CD pipelines, including short-lived credentials, human-gated publishing controls, and mandatory code reviews for all package releases.
- -1 The infostealer-to-supply-chain pipeline will mature, with attackers actively hunting for developer credentials in underground markets and weaponizing them within days rather than weeks.
▶️ Related Video (78% Match):
🎯Let’s Practice For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
IT/Security Reporter URL:
Reported By: Mayura Kathiresh – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
