Shai-hulud 2.0 Campaign Targets Cloud and Developer Ecosystems

Shai-hulud 2.0 campaign features a sophisticated variant capable of stealing credentials and secrets from major cloud platforms and developer services, while automating the backdooring of NPM packages maintained by victims. Its advanced tactics enable rapid, stealthy propagation across the software supply chain, putting countless downstream users at risk.

Cyber Threats

Shai-hulud 2.0 Campaign Targets Cloud and Developer Ecosystems

Shai-hulud 2.0 campaign features a sophisticated variant capable of stealing credentials and secrets from major cloud platforms and developer services, while automating the backdooring of NPM packages maintained by victims. Its advanced tactics enable rapid, stealthy propagation across the software supply chain, putting countless downstream users at risk.

By: Jeffrey Francis Bonaobra

Nov 27, 2025

Read time: ( words)

Save to Folio

Key takeaways:

• Shai-hulud 2.0 continues the first variant’s credential theft by stealing credentials and secrets from major cloud platforms as well as NPM tokens and GitHub authentication credentials, but introduces backdoor capabilities.

• The malware automates supply chain compromise by backdooring all NPM packages maintained by the victim, republishing them with malicious payloads that execute on installation, creating a highly wormable threat with the potential to impact thousands of downstream users.

• The malware uses stolen cloud credentials to access cloud-native secret management services, while also exhibiting destructive code that wipes user data when unsuccessful in harvesting data.

• Trend Vision One™ detects and blocks the indicators of compromise (IOCs) outlined in this blog, and provides customers with tailored threat hunting queries, threat insights, and intelligence reports.

This blog continues our investigation on the Node Package Manager (NPM) supply chain attack that took place on September 15, where attackers executed a highly targeted phishing campaign to compromise the account of an NPM package maintainer. Our previous blog detailed how the malicious code injected onto JavaScript packages diverted cryptocurrency assets by hijacking web APIs and manipulating network traffic, and how the Shai-hulud worm in the attack payload steals cloud service tokens, deploys secret-scanning tools, and spreads to additional accounts. An incident this November 24 reported hundreds of NPM repositories compromised by what appears to be a new Shai-hulud campaign with the repository description, "Sha1-Hulud: The Second Coming."

This blog discusses Trend™ Research findings on Shai-hulud 2.0 and reveals new functions that weren’t observed in its first variant.

Our analysis of Shai-hulud 2.0 reveals that it can steal credentials from AWS, GCP, and Azure cloud providers, which can contain API keys, tokens, and passwords, along with NPM tokens and GitHub authentication credentials. The malware also creates GitHub Actions workflows that allow for command-and-control (C&C). It also injects GitHub Actions workflow mechanisms that are specifically designed to steal repository secrets.

Beyond stealing static credentials, the malware uses stolen cloud credentials to access cloud-native secret management services: it can retrieve secrets from AWS using the AWS Secrets Manager API, extracts Google Cloud secrets through the GCP Secret Manager API, and collects Azure secrets via Azure Key Vault. The malware also targets credentials from Azure Pod Identity, a legacy system that remains widely used for providing Azure identities to Kubernetes pods.

To top all the capabilities, the malware also automatically backdoors every NPM package maintained by the victim, republishing them with malicious payloads that run during package installation, creating a wormable vector capable of spreading exponentially across the NPM ecosystem and potentially compromising thousands of downstream users who trust the affected packages. This entire workflow is automated and parallelized across up to 100 packages at once, maximizing propagation while keeping detection opportunities minimal.

Shai-hulud 2.0 attack chain analysis

Shai-Hulud 2.0 is delivered as an NPM package with a malicious preinstall script that executes automatically during the NPM installation process (modified package.json with "preinstall": "node setup_bun.js").

[Figure 1. Shai-hulud 2.0 high-Level workflow]

Figure 1. Shai-hulud 2.0 high-Level workflow

download

setup_bun.js (Loader)

The initial dropper setup_bun.js script serves as a loader that executes during the NPM package installation process. Its primary purpose is to ensure that a Bun JavaScript runtime is available on the victim's system and then uses it to execute the main malware payload (bun_environment.js).

[Figure 2. setup_bun.js execution flow]

Figure 2. setup_bun.js execution flow

download

Bun runtime detection and installation

The initial phase of the setup script involves detecting whether a Bun JavaScript runtime is already installed on the victim's system. This detection process uses platform-specific commands to search the system PATH for the Bun executable. On Windows systems, the script executes the where command, while Unix-like systems (Linux and macOS) use the which command.

If Bun is not detected in the system PATH, the script initiates an automatic download and installation process. This process uses official Bun installation scripts provided by bun.sh, which adds legitimacy to the installation and reduces the likelihood of detection by security software.

On Windows, the script uses PowerShell to download and execute the installation script via the Invoke-RestMethod and Invoke-Expression cmdlets. On Unix-like systems, it uses curl to download the installation script and pipes it directly to bash for execution. This approach mirrors the official Bun installation instructions, making the malware's behavior appear legitimate.

[Figure 3. Checks if Bun is available on system PATH before attempting installation]

Figure 3. Checks if Bun is available on system PATH before attempting installation

Reloading PATH environment

After installing the Bun runtime, the setup script must reload the system PATH environment variable to detect the newly installed executable. This is necessary because the Bun installation process modifies the user's PATH, but these changes are not immediately visible to the already-running Node.js process executing the setup script. The PATH reloading mechanism uses platform-specific techniques to retrieve the updated environment configuration.

On Windows systems, the script queries the Windows Registry using PowerShell to retrieve both user-level and machine-level PATH variables, then combines them into a single PATH string. This approach ensures that the Bun installation is detected regardless of whether it was installed to the user's profile directory or a system-wide location. The script uses the [Environment]::GetEnvironmentVariable() .NET method accessed through PowerShell to read these registry values.

[Figure 4. Powershell execution to query updated PATH from registry]

Figure 4. Powershell execution to query updated PATH from registry

download

On Unix-like systems, the PATH reloading process is more complex due to the variety of shell configurations that might be in use. The script attempts to source common shell profile files including .bashrc, .bash_profile, .profile, and .zshrc in the user's home directory.

[Figure 5. Powershell execution to query updated PATH from registry]

Figure 5. Powershell execution to query updated PATH from registry

Payload execution

The final phase of the setup script orchestrates the execution of the actual malware payload.

[...]

Original source