Unit 42 recently reported on a resurgent and highly sophisticated npm supply chain attack, now referred to as Shai-Hulud 2.0, affecting tens of thousands of GitHub repositories and compromising trusted open-source packages. The campaign uses malicious package updates to steal credentials, establish persistent backdoors and self-propagate across developer environments and CI/CD systems.
Today’s blog post looks at how Cortex® CloudTM, Cortex XDR® and Prisma Cloud® can help organizations detect, block and contain the behaviors used in this campaign, as well as what steps organizations should take to stay secure—even if they rely on other security tools.
Anatomy of a Software Supply Chain Attack
The current 2.0 campaign, aka “Shai-Hulud: The Second Coming”, affects tens of thousands of GitHub repositories, including over 25,000 malicious repos spread across roughly 350 unique users. But to understand the severity of Shai-Hulud 2.0, it helps to look at the mechanics of a supply chain attack. The threat actor doesn’t target the final product (an individual's application) directly. Instead, they target a trusted component within the product's supply chain.
Related Article: Breakdown: Widespread npm Supply Chain Attack Puts Billions of Weekly Downloads at Risk
Imagine a thief trying to break into a safe. Instead of attacking the steel door, they tamper with the factory that manufactures the safe and slip in a faulty lock. The manufacturer unknowingly installs the compromised lock on every safe that rolls off the line. When customers buy those safes from a trusted brand, the thief can break in with ease because they know the built-in weakness.
- The Component Supplier: The package maintainer and the npm registry act as the trusted suppliers.
- The Component Part: The npm packages are the individual parts (the “locks”).
- The Manufacturer: Developers are the manufacturers, assembling applications using those trusted components.
- The Final Product: The software, services and systems developers deliver.
By poisoning the open-source packages, the malicious code is automatically distributed downstream to every developer, build server and application that installs or updates those packages.
The Attack: What Is Shai-Hulud 2.0?
The Shai-Hulud malware behaves like a worm because once it compromises an npm package, it can spread to others. It steals credentials, republishes trojanized packages and moves through the ecosystem on its own, not before leaving a persistent backdoor that attackers can utilize in the future for direct command execution on a developer workstation.
The recent 2.0 variant introduces new tactics such as earlier preinstall execution, a redesigned payload structure and, in some cases, Docker privilege escalation. It infects package.json with malicious pre-install scripts, and when a developer or CI/CD runner installs a compromised package, the script kicks off a sequence of actions designed to steal secrets and extend the infection.
The diagram in figure 1 reflects the major differences between Shai-Hulud 1.0 and 2.0.
As mentioned, the 2.0 version attempts to set up a persistent backdoor through GitHub Discussions. With this, attackers can potentially execute commands on the developer workstation simply by opening a discussion in a repository that contains a malicious workflow. The backdoor will survive reboots and credential rotation.
Key Attack Stages
- The Initial Spark: Though the worm spreads automatically now, the threat actor initially used stolen credentials to manually publish the infected version of @asyncapi/specs.
- Dropper Execution: The script deploys
setup_bun.js, which installs the Bun runtime if missing. - Persistence & Payload: A heavily obfuscated payload,
bun_environment.js, is launched as a detached background process. - Credential Harvesting: The malware scans for credentials in standard locations (
~/.aws/,~/.azure/,~/.npmrc) and scrapes environment variables. It has also been observed utilizing TruffleHog to aggressively scan for secrets. - Exfiltration: Stolen secrets are dumped into new GitHub repositories created with stolen tokens, often sporting descriptions like "Sha1-Hulud: The Second Coming".
- Propagation: Leveraging stolen npm tokens, the malware publishes new, infected versions of the victim's packages, perpetuating the cycle.
Global Mirroring of npm Adds Security Challenges
Global mirroring of npm across public mirrors, company proxies and private enterprise registries improves speed and reliability, as well as regional access. It also amplifies supply chain risk, however. Mirrors replicate packages automatically and can often retain cached versions even after removal upstream. To mitigate heightened risk, organizations can enforce strict version pinning and use dependency allowlists to ensure only verified package versions are installed, reducing exposure to malicious cached packages.
Secure Your Software Supply Chain with Cortex Cloud
Cortex Cloud offers extensive ASPM and supply chain security capabilities to help identify the vulnerabilities and misconfigurations that Shai-Hulud exploits.
*Prisma Cloud customers who haven’t yet migrated to Cortex Cloud should take the same precautions.
1. Identifying Vulnerable Packages (SCA & SBOM)
Since CVEs for these malicious packages may lag behind the attack, organizations must rely on real-time visibility into their software bill of materials (SBOM).
- SBOM Querying: Cortex Cloud allows you to query your organization's SBOM against the list of known malicious packages to immediately identify impact.
- Operational risk model: For packages without published CVEs, our proprietary Operational Risk model provides additional protection. It evaluates open-source packages based on factors such as maintainer activity, deprecation status and community adoption, allowing us to identify risky components even in the absence of known vulnerabilities.
2. Hardening CI/CD Policies: Out-of-the-Box Rules
Shai-Hulud thrives in insecure environments. Palo Alto Networks customers can leverage the following Cortex Cloud out-of-the-box (OOTB) CI/CD rules to prevent similar attacks. These rules map to industry standards like the OWASP Top 10 CI/CD Risks and CIS Software Supply Chain Security Guide.
- Repository missing npm lock file: Detects repositories missing
package-lock.json. If a lock file is not used when running "npm ci" during the build, packages are installed without integrity checks, allowing tampered versions to slip in. - Packages insecurely installed through "npm install" command: In common configurations, "npm install" updates and installs versions without checking package integrity. This allows attackers who control a dependency to upload a malicious version that’s automatically downloaded.
- npm package downloaded from git without commit hash reference: Without a specific commit hash, the integrity of a package downloaded from a git URL can’t be guaranteed, which potentially allows a build server to download a malicious version.
- npm project contains unused dependencies: Unused dependencies widen the attack surface without justification. If an unused dependency is compromised by Shai-Hulud, it exposes the project to risk even if the code isn't actively used.
Prevent and Hunt Threats with Cortex XDR
Cortex XDR and WildFire® automatically detect and block the malicious payloads and behaviors associated with this campaign, fully protecting you from this attack and any similar threats.
To ensure you’re fully protected, simply verify that your Cortex XDR agents are configured in "Block" mode (which is the default setting). This will prevent the malicious scripts from executing on your endpoints.
For active threats on developer endpoints, build servers and clouds, Cortex XDR provides layered protection.
1. IoC Blocking (Behavioral & Static)
Malicious File Prevention: Cortex XDR prevents the execution of known malicious JavaScript payloads. Ensure your agents are set to "Block" for malware.
Known Hash Indicators:
- bun_environment.js:
62ee164b9b306250c1172583f138c9614139264f889fa99614903c12755468d0f099c5d9ec417d4445a0328ac0ada9cde79fc37410914103ae9c609cbc0ee068
- setup_bun.js:
a3894003ad1d293ba96d77881ccd2071446dc3f65f434669b49b3da92421901a
2. XQL Hunting Queries
Security teams can use Cortex XDR's XQL (Cortex Query Language) to hunt for signs of compromise within their environments.
Query 1: Reports indicate only Linux+Mac is targeted due to an os.platform() check. Ensure agent coverage on these devices.
Query 2: Check for connections to any webhook.site domains in raw NGFW URL logs. Optional filter for specific URI observed in use by threat actor.
Query 3: Check for connections to any webhook.site domains in XDR telemetry. Optional filter for specific URI observed in use by threat actor.
Query 4: Detect malicious YAML file.
Query 5: Detects Trufflehog usage. Legitimate tool abused by threat actor for secrets discovery. False positives may occur if there is legitimate use.
Query 6: Detect malicious bundle.js file.
Cortex researchers continue to monitor for malware targeting vulnerable npm packages and ensure that Wildfire® is maintained to accurately flag known malware samples as malicious.
3. Cloud & Identity Protection
For cloud environments, Cortex XDR and XSIAM analytics can detect the aftermath of the infection.
- Anomalous API Usage: Detection of unusual secrets manager or key vault access patterns.
- Identity Abuse: Alerts on new user creation or unusual role assumptions (AWS STS) originating from developer endpoints.
Mitigation Recommendations
- Block Known Hashes: Ensure that your XDR agent is set to block (the default setting). For Cortex XDR customers, WildFire has automatically added the known SHA256 hashes listed above to your block list.
- Rotate Credentials: If any machine has triggered alerts for these IoCs, consider all credentials on that machine (AWS, Azure, GCP, npm, GitHub) compromised. Rotate them immediately.
- Update Policies: Use Cortex Cloud ASPM to enforce the presence of lock files and vet external packages before they enter your pipeline.
- Isolate & Remediate: Use Cortex XDR to isolate affected endpoints and initiate a "Search and Destroy" action for the malicious JS files.
For more information on the affected packages and continuous updates, refer to the Unit 42® Threat Brief.