Water of Life: Drowning a little maker

The untreated liquid was retrieved from the [Shai-Hulud] as it was drowned in water. The liquid exhalation only emerged right before the creature's moment of death. - Dune Wiki: Water of Life

Update Nov 25, 2025: In addition to identifying the threat and scale of this campaign, the Fitretech team has identified and validated an effective “killswitch” and de-worming capability to collapse this campaign and revert the npm repositories in time. The killswitch will be immediate, once deployed, for all persisted machines, and includes the functionality to remove the poisoned javascript files from the impacted npm repositories. We are coordinating with the FBI to pursue a legal and thorough takedown of this campaign, and more details will be released as they are available.

Update Nov 26, 2026: It appears that the majority of GitHub exfiltration pages are offline or switched to private. Our team is continuing to track more compromised repositories and updating our breach database search tool.

The Fitretech Security team has identified a sophisticated supply chain attack targeting the npm ecosystem that represents one of the most advanced threats to open-source software infrastructure we've encountered. This has been repeatedly posted about by every AAA service provider, however, due to our advanced red-team and offensive operations, have deciphered the method behind this behemoth’s madness. This malware uses a novel peer-to-peer coordination mechanism that leverages GitHub's public infrastructure as a distributed command-and-control platform, eliminating the need for traditional attacker-controlled servers. At this time, we’ve identified their infrastructure, methods for communication (read more if this seems repetitive), and the kill switch to keep them at bay.

We are actively working with the Federal Bureau of Investigation (FBI) to coordinate a comprehensive takedown of this campaign. Due to the ongoing nature of law enforcement operations, certain technical details are being withheld to preserve the integrity of the investigation. Keep in touch with this series, as we will show the process from turning a colossal, seemingly unkillable monstrosity into soup by reverse engineering their sophisticated techniques into soup.

Note: Due to the limitations of this platform, we are actively investigating solutions to include code blocks, as they are not currently supported or visually useful. In the coming days, expect an update that includes these codeblocks as updates to this post.

What we’ve found

Our team has analyzed a sophisticated malware campaign that propagates through the npm package ecosystem using a worm-like mechanism. When developers or CI/CD systems install an infected package, malicious preinstall hooks execute a payload that:

1. Establishes persistent backdoor access on compromised systems

2. Exfiltrates sensitive credentials including GitHub tokens, npm tokens, and cloud provider secrets (AWS, Azure and GCP specific)

3. Poisons additional npm packages owned by the victim, creating exponential spread

4. Coordinates with other infected systems through an innovative distributed architecture

What makes this threat particularly concerning is its self-propagating nature and abuse of trusted platforms. Unlike traditional malware that relies on attacker-controlled infrastructure, this campaign uses GitHub repositories and npm's package registry as both distribution and coordination mechanisms.

We are releasing this post and series because it appears that other posts are revealing indicators of compromise (IOCs) that are inaccurate, or reveal information that otherwise can be false due to the fast-evolving nature of the malware.

The Scale

This attack specifically exploits systems that use or are used by:

• Software developers using npm packages

• CI/CD pipelines (GitHub Actions, GitLab CI, CircleCI, BuildKite, AWS CodeBuild)

• Container environments including Kubernetes clusters

• Cloud infrastructure with access to AWS, GCP, and Azure secrets

The malware is designed for automated build environments where it has access to production secrets and can reach into production infrastructure. It makes assumptions, based on experience, that it has elevated privileges wherever it is executed. This usually is in an automated CI infrastructure such as a Kubernetes cluster, but also includes developer machines as they commonly have elevated privileges by default.

How It Works (High-Level Overview)

Stage 1: Initial Infection

The malware spreads through npm package dependencies. When a package with a malicious preinstall script is installed, it downloads and executes additional payloads. The infection is designed to be stealthy. If it successfully steals credentials, the build process appears to complete normally. The list of compromised npm repos is currently under investigation, due to conflicting information.

Stage 2: Credential Harvesting

The malware comprehensively searches for:

• GitHub personal access tokens and authentication credentials (for proliferation)

• npm authentication tokens from .npmrc configuration files (for further worming behavior)

• AWS, Google Cloud Platform, and Azure credentials

• All environment variables

• Secrets stored in Kubernetes environments

Stage 3: Data Exfiltration

Stolen credentials are uploaded to GitHub repositories that serve as both data collection points and coordination hubs. The malware uses multiple layers of base64 encoding to obfuscate the stolen data from automated scanning tools.

Note: During the course of reverse engineering the malware, we discovered a discrepancy between our de-encoding process from exploited systems and the systems currently being exploited. We noticed that the GitHub exfiltrated files were double-base64 encoded, but the polled malware was triple-encoding the files. This indicates an incredibly fast paced update cycle that keeps the malware alive and fighting.

Stage 4: Worm Propagation

If the malware obtains a valid npm token, it searches for all packages maintained by the compromised account, modifies them to include the malicious preinstall script, increments the version number, and republishes them. This creates a cascading effect where every downstream user of those packages becomes infected.

This creates an exponential growth of the botnet, which effectively allows a huge chunk of maintained code to be backdoored due to npm’s vast dependency lifecycle. This blog post demonstrates the dangerously vast dependency tree that npm repositories tend to abide by, due to how the technology is utilized. We have concerns for the efficacy of software bill of materials (SBOMs) due to this reason, and currently advocate for more advanced technology to track this kind of dependency hell.

Stage 5: Persistence and C2

The malware establishes multiple independent persistence mechanisms and creates covert communication channels using legitimate GitHub features. This allows attackers to maintain long-term access and issue commands to compromised systems without operating any servers of their own.

The C2 method is currently in technical disclosure to law enforcement, as we’ve identified the “killswitch” to deactivate the persistence methods utilized by this malware strain. In general however, it is utilizing one of GitHub’s services to communicate and issue commands.

In addition to persistence, the malware attempts to escalate privileges by performing a passwordless sudo, as well as attempting to abuse the docker socket to mount the host drive in a privileged container. No indicators of container-escape (from context of compromised container) are currently identified within the malware.

The Distributed Coordination Mechanism

The most innovative aspect of this malware is its peer-to-peer coordination system. Unlike traditional botnets that rely on centralized command-and-control servers, this campaign uses GitHub's search API and public repositories to enable infected systems to discover and communicate with each other.

Each infected system creates a GitHub repository with a specific marker in its description. New infections search for these markers, discover repositories created by other victims, and extract valid credentials from them. If one victim's token is revoked, infections simply find and use tokens from other victims. This creates a self-healing network that's extremely difficult to disrupt. At this time, we are actively working with law enforcement to deploy a killswitch to disabled and dismember this campaign from persisting on existing systems. This does not guarantee a block of proliferation, however, we’ve found a novel method to reverse the worm’s methodology. This reverts the repositories to a “good” state.

Back to how the attacker is proliferating. The attacker can seed the network with high-privilege GitHub tokens by creating their own repositories with the coordination markers, instantly upgrading the capabilities of every infected system. This distributed architecture means there's no single point of failure to take down.

Warning Signs

Package-Level Indicators

• npm packages in your dependency tree with unusual preinstall or postinstall scripts

• Recent package updates that only increment the patch version and add scripts

• Packages that install/download the Bun javascript toolkit

System-Level Indicators

• Unfamiliar background processes with names bun/bun.exe and node/node.exe

• Unexpected GitHub API traffic from CI/CD systems or developer workstations

• Self-hosted GitHub Actions runners that weren't explicitly configured by your team

  • Specifically, runners named SHA1HULUD

• Unusual directory structures in user home directories (particularly hidden directories with configuration files; e.g., $HOME/.dev-env)

Network-Level Indicators

• Elevated GitHub API usage, particularly repository search queries

• npm publish activities from CI/CD systems (unless this is expected)

• Downloads of secret scanning tools from public repositories

  • Look specifically for downloads from trufflehog tool from GitHub (https://github.com/trufflesecurity/trufflehog/releases/download/<version>/trufflehog_<version>_<os>_<arch>.tar.gz)

GitHub Activity

• Repositories in your organization descriptions matching “Sha1-Hulud: The Second Coming.”

• Recently created repositories with random alphanumeric names

• Self-hosted runners with name SHA1HULUD appearing in your GitHub Actions configuration

• Workflow files that weren't created by known team members

Immediate Actions for Potentially Affected Organizations

1. Inventory Self-Hosted Runners

Audit all self-hosted GitHub Actions runners in your organization. Remove any runners that aren't explicitly documented and approved. Pay special attention to runners that appear on individual contributers rather than organization-wide runners. Any runners with name SHA1HULUD indicate a compromise, and your organization should contact incident response immediately. See the bottom for how to contact us.

2. Rotate Credentials

Immediately rotate:

• All GitHub personal access tokens and OAuth tokens

• npm authentication tokens

• AWS access keys and secret keys

• Google Cloud Platform service account keys

• Azure service principal credentials

• Database passwords and API keys stored in environment variables

If you have been compromised, rotate:

• All secrets available to runner service accounts

• All secrets potentially visible in environment variables of runners

The malware is incredibly capable, and should assume that any secrets available to list and retrieve are compromised. This is by-far the most sophisticated stealer method seen for stealing AWS/Azure/GCP secrets in the wild by the Fitretech team.

3. Audit npm Packages

Review the package.json files across your codebase for:

• Preinstall, postinstall, and prepare scripts

• Dependencies that weren't explicitly added by your team

• Recent updates to dependencies that only changed version numbers slightly

Run npm audit and investigate any packages flagged for suspicious activity.

Stand-by for our release of compromised npm repositories. The list appears to be over 1000 repositories at this time.

4. Review CI/CD Logs

Examine logs from your CI/CD systems for:

• Unexpected network connections during build processes

• Downloads of unfamiliar binaries or scripts

• Failed authentication attempts to GitHub or npm

• Unusual command executions in build logs

5. Scan for Secrets in Code

Use secret scanning tools to identify any hardcoded credentials in your codebase or configuration files that may have been exfiltrated. As a general rule, if you can see the secrets, so can an attacker. If you would like assistance with this kind of service, see the bottom to contact the Fitretech team for attacker focused discovery.

Our Collaboration with Law Enforcement

Fitretech is actively coordinating with:

• Federal Bureau of Investigation (FBI) Cyber Division

Due to the ongoing nature of this investigation, we will not disclose specific technical details about the coordination mechanism or provide the exact indicators that would allow identification of all infected repositories. These details are being shared directly with law enforcement and platform providers to facilitate a coordinated takedown while minimizing the risk of the attacker modifying their techniques.

We expect to publish a comprehensive technical analysis after law enforcement operations are complete, including:

• Complete source code analysis

• Detailed attack flow diagrams

• Network traffic signatures

• YARA rules for detection

• Indicators of compromise (IOCs)

For Security Researchers

If you are investigating this threat or have discovered related indicators, please do not publicly disclose specific technical details that could interfere with the ongoing takedown operation.

We request that researchers:

• Contact law enforcement through appropriate channels

• Coordinate with applicable service (npm, GitHub) to coordinate efforts with known information

• Reach out to our team at research@fitretech.com for coordination

Public disclosure of operational details at this time could allow the threat actors to modify their infrastructure and evade the coordinated takedown. To allow for a fast and thorough takedown, we advise coordinating with our team, Github, npm, and/or the FBI directly.

Why This Attack Represents a New Threat Model

No Infrastructure Costs

By abusing free, trusted platforms like GitHub and npm, the attackers eliminate infrastructure costs and the risks associated with operating malicious servers. All traffic goes to legitimate, trusted domains that are rarely blocked. Traditional killswitches, as seen in the notpetya and wannacry, do not apply for large SaaS services like GitHub. This creates a novel method for self-healing and resilience not commonly seen in mainline botnet malware.

Distributed Resilience

Traditional botnet takedowns involve seizing command-and-control servers. This attack has no such servers—the coordination is peer-to-peer through GitHub. Taking down one repository doesn't affect the others, and the network can self-heal by finding new valid credentials from other victims.

Abuse of Trust

Developers and security tools inherently trust GitHub and npm. Traffic to these platforms typically bypasses security controls, and connections from CI/CD systems to these services are considered normal and necessary. This makes the attack difficult to detect with conventional network security tools.

Supply Chain Wormability

The worm mechanism creates exponential spread. One infected developer account can poison dozens of popular packages, each of which may have thousands of downstream users. Within hours, a single compromised account can create a network of hundreds or thousands of infected systems.

Self-Propagating Credential Theft

Perhaps most concerning is the malware's ability to steal tokens, use those tokens to spread further, and share those tokens with other infected systems. This creates a network where credentials propagate among all infections, making traditional token revocation strategies less effective.

Long-Term Implications for Open Source Security

Package Script Execution

The npm ecosystem allows packages to execute arbitrary code during installation through lifecycle scripts (preinstall, postinstall, etc.). While this functionality is necessary for many legitimate use cases, it creates a significant attack surface. The community needs to have serious discussions about:

• Whether scripts should be opt-in rather than automatic

• Improved sandboxing for package installation

• Better visibility into what scripts are doing

• Mechanisms for cryptographically signing and verifying package scripts

Transitive Dependencies

Modern applications can have thousands of transitive dependencies. A vulnerability in any single package can cascade through the entire ecosystem. This attack exploited that trust relationship—if you trust package A, and package A depends on package B, you implicitly trust package B even if you've never heard of it.

Credential Management in CI/CD

This attack succeeded in part because CI/CD systems often have broad access to credentials for convenience. Organizations need to implement:

• Principle of least privilege for build systems

• Rotation of credentials used in CI/CD

• Secret scanning before credentials reach CI/CD systems

• Network segmentation for build environments

Platform Responsibility

While platforms like GitHub and npm have strong security teams, they were not designed to detect abuse patterns like peer-to-peer botnet coordination. This attack demonstrates that platforms need to develop capabilities to detect novel abuse patterns that don't fit traditional threat models.

Fitretech's Ongoing Monitoring

Our team continues to:

• Monitor for variants of this malware campaign

• Analyze the full scope of affected systems

• Develop detection signatures and hunting queries

• Coordinate with law enforcement and platform providers

• Prepare comprehensive technical documentation for post-takedown publication

We are committed to supporting the security community through this incident and will release detailed technical analysis once law enforcement operations are complete.

How to Contact Us

If You Believe You're Affected

Email: research@fitretech.com
Subject line: "npm Supply Chain Incident"

Please include:

• Description of suspicious activity

• Affected systems or accounts

• Timeline of when you first noticed issues

• Any logs or evidence you've collected

For Security Researchers

If you have information relevant to this investigation or have discovered related indicators, please contact us at research@fitretech.com. We are actively coordinating with law enforcement and will ensure your findings contribute to the takedown effort.

For Media Inquiries

Email: press@fitretech.com

Stay Informed

We will publish updates as the situation develops and additional information can be safely disclosed:

• Check our blog for updates: fitretech.com/blog

Threat Intel Data

The following download contains all compromised GitHub user accounts 11/25/2025:

Check if your hostname/username/Github account has been breached with our database search tool:

Disclosure Timeline:

• November 24, 2025: Initial discovery and analysis

• November 24, 2025: Killswitch and deworming capability tested and validated

• November 24, 2025: Notification to FBI

• November 25, 2025: Public disclosure of threat (this advisory)

• November 25, 2025: Updated with compromised GitHub account list

• November 25, 2025: Updated with compromise search tool