A Technical Overview of Sha1-Hulud: How a Self-Replicating Worm Compromised 26,000 Credentials in 72 Hours

The rise of modern software supply chains has accelerated rapidly and with it, a new wave of highly sophisticated, often invisible cyberattacks. One of the most concerning threats to emerge is Sha1-Hulud: The Second Coming, a supply-chain–driven campaign designed specifically to harvest sensitive credentials at scale.

This campaign demonstrates advanced capabilities, including the theft of GitHub access tokens and multi-cloud credentials spanning AWS, Azure, and Google Cloud Platform. Its focus on infiltrating the development ecosystem makes it particularly dangerous, as it targets authentication secrets directly at the source.

According to data from Wiz, the impact has been immediate and extensive: more than 25,000 malicious repositories across approximately 350 GitHub accounts were compromised on the first day alone of the campaign’s discovery. This highlights not only the growing sophistication of supply chain attacks but also the immense speed at which they can propagate through widely used development platforms.

How it Works

The initial phase of the attack begins by targeting popular NPM packages that are widely integrated into services such as Zapier, ENS Domains, PostHog, and Postman. These packages were intentionally selected to maximize the reach and downstream impact of the supply chain compromise.

Once a victim installs the malicious NPM package, the package automatically triggers a curl or PowerShell command, depending on the operating system.

This command downloads an additional JavaScript payload typically named setup_bun.js or bun_environment.js , which acts as the next-stage dropper. Now this secondary payload creates a file with a randomly generated string, using either the .degu name pattern or the .pile file extension and this newly dropped file functions as the primary malicious payload.

The main payload carries out several high-risk operations:

• Scraping sensitive credentials from local .env files and other configuration sources

• Exfiltrating the harvested secrets by uploading them to a GitHub repository controlled by the attacker

• Abusing the compromised GitHub account to create a malicious GitHub Action workflow, effectively turning the victim’s GitHub profile into a command-and-control (C2) node for further propagation

Through this technique, the attacker leverages GitHub’s own automation capabilities to persist, spread laterally, and orchestrate follow-on exploitation.

Inside the Payload

Phase 1 : Establishing GitHub Actions as a Command-and-Control (C2) Channel

In the first stage, the malware creates a malicious GitHub Action workflow within the compromised account. This workflow is engineered to execute arbitrary commands, effectively transforming GitHub Actions into a remote command execution point.

Phase 2 : Harvesting Exposed Credentials from .env Files

The second phase focuses on extracting credentials—specifically those stored in .env environment configuration files. The attackers deliberately designed the payload to avoid interacting with internal system credentials or secrets that could trigger alerts in security monitoring tools.

Instead, the malware targets plaintext credentials stored in environment files, as these often contain API keys, tokens, service credentials, and cloud secrets.

Once collected, these credentials are exfiltrated to attacker-controlled GitHub repositories or used to expand access across cloud platforms. This approach allows the attacker to quietly obtain sensitive information without setting off security anomaly detection systems.

Additionally we observed requests targeting cloud-native secret storage services, indicating that the attackers attempted to broaden their access beyond local .env files. These attempts included probing and extracting secrets from:

• GCP Secret Manager

• Azure Key Vault

• AWS Secrets Manager

Furthermore, telemetry revealed the use of AssumeRoleWithWebIdentity API calls, suggesting that the threat actors were trying to leverage federated identity mechanisms to escalate privileges or pivot across cloud accounts.

Phase 3: Docker Abuse for Privilege Escalation

The other interesting code which focuses on container-based privilege escalation. The code might attempt to interact with the Docker daemon, a critical point of concern because the Docker socket (/var/run/docker.sock) typically runs with root-level privileges.

If successfully exploited, this access would allow the attacker to:

• Create and run privileged containers

• Escape the container boundary

• Execute commands directly as root on the host machine

By targeting Docker, the adversaries may attempt to escalate their privileges beyond what was available to the compromised service or CI/CD runner, potentially achieving full host takeover.

Workflow

This flow outlines the operational execution of the supply chain campaign known as Sha1-Hulud: The Second Coming.

The Exfilteration

The exfiltrated credentials were directly pushed to GitHub, as no external network communication was observed. The repository contained multiple JSON files, each holding sensitive data:

• Cloud.json – Included AWS, Azure, and GCP credentials.

• Contents.json – Contained GitHub user details and a PAT token with sufficient privileges to commit the exfiltrated data.

• Environment.json – Stored various GitHub tokens, secrets, and related configuration information.

All exfiltrated data was double-obfuscated using Base64, making it significantly more difficult to search for or identify the leaked credentials on GitHub.