Web3 Blockchain C2 Conceals Supply Chain Attacks on Cloud Credentials

Key Takeaways

• Threat actors are increasingly leveraging public blockchain networks as a resilient command-and-control (C2) infrastructure for supply chain malware.
• This method allows attackers to dynamically update C2 servers without altering malicious code on infected systems, bypassing traditional domain blocklists.
• The ChainDrop npm worm, a self-propagating malware, infected over 400 packages and was observed exfiltrating a wide array of sensitive cloud and development credentials.
• Another campaign, PolinRider, demonstrates the expansion of this technique beyond npm, utilizing various package managers and public RPC services to deliver encrypted payloads.
• Organizations, especially those with cloud-focused operations, face heightened risk as compromised open-source packages can steal temporary cloud identity tokens and other critical data from developer environments and CI/CD pipelines.

Blockchain C2: A New Frontier for Supply Chain Attacks

Cybersecurity researchers are observing a significant shift in attacker tactics, with malicious actors now employing public blockchain networks to establish command-and-control (C2) channels for software supply chain malware. This innovative approach grants attackers a robust mechanism to update their infrastructure without needing to modify the malicious code already deployed on compromised developer systems. The implications are particularly severe for organizations heavily reliant on cloud environments.

This method provides a resilient pathway for criminals to redirect infected software packages to new data exfiltration servers, thereby diminishing the effectiveness of conventional domain blocklisting strategies. The danger is amplified for cloud-centric organizations, as tainted open-source packages can execute within developer workstations and CI/CD pipelines. From these vantage points, they can access highly sensitive data, including temporary cloud identity tokens, deployment secrets, service-account keys, and GitHub credentials.

ChainDrop: A Case Study in Blockchain-Enabled Credential Theft

A recent investigation into the ChainDrop npm worm highlighted how trusted publishing channels can be exploited. Ordinary dependency updates and project configurations were weaponized to facilitate credential theft. Analysts at Unit 42 identified ChainDrop as a self-propagating npm worm that infiltrated more than 400 packages.

The research revealed that ChainDrop systematically harvested a broad spectrum of credentials, including cloud credentials, npm and GitHub tokens, SSH keys, Kubernetes tokens, Terraform state files, and Vault tokens, along with other secrets present in developer environments. Furthermore, the malware was designed to scan the memory of GitHub Actions runner processes for ephemeral OpenID Connect (OIDC) tokens and runner secrets.

Hackers Leverage Web3 and Blockchain for C2 Evasion

Traditionally, malware operations involve hard-coding a specific domain or IP address into the malicious code for C2 communication. This practice offers a clear target for defense, allowing security teams to block the address, registrars to suspend the domain, and package platforms to scan for known indicators. Blockchain C2 fundamentally alters this paradigm.

Instead of a static C2 address, the malware queries a smart contract or blockchain transaction during runtime to retrieve its current destination. ChainDrop exemplified this technique by utilizing an Ethereum smart contract. Unit 42 reported that the worm queried this contract to obtain the data exfiltration address, subsequently shifting its C2 from npm-cache[.]com to awqhnjewqjkl[.]icu via a single Ethereum transaction. This C2 rotation required no re-publishing of packages or distribution of new malware versions to victims, a technique commonly known as EtherHiding.

It is crucial to understand that the blockchain itself is not inherently malicious. Rather, its public and decentralized architecture is being misused by criminals as a dynamic address book, a repository for payloads, or a dead-drop service. Previous reports on EtherHiding malware delivery have detailed how smart contracts can return encoded JavaScript payloads, empowering operators to modify delivery content without altering compromised websites.

ChainDrop’s Attack on Development Workflows

The ChainDrop infection typically initiates through a modified npm package containing a preinstall command. This command triggers setup.mjs, which downloads the legitimate Bun JavaScript runtime if not already present, then uses it to execute an obfuscated payload. It’s important to note that the Bun runtime itself was not compromised; attackers merely leveraged it for code execution.

Once activated, the malware scans local files, environment variables, and cloud metadata services for credentials. It also targets active build processes, a critical detail given that CI/CD systems frequently employ temporary credentials that are not persistently stored on disk. While valid, these temporary tokens can provide attackers with direct access to cloud APIs, deployment environments, or source-code systems.

ChainDrop also established persistence within developer toolchains. It achieved this by writing a VS Code task designed to execute upon folder opening and by adding a Claude Code SessionStart hook. This means a developer could inadvertently trigger the malware simply by opening a project or initiating an AI coding session. This vulnerability mirrors the broader ChainDrop campaign’s exposure of developer tool configurations, where trusted local project files became an execution vector.

PolinRider: Expanding the Blockchain C2 Threat

A separate campaign, dubbed PolinRider, indicates that this blockchain C2 model is expanding beyond the npm ecosystem. Researchers have linked PolinRider to North Korea-aligned threat activity, uncovering malicious loaders in npm, Packagist, Go modules, and Chrome extensions. These loaders employed blockchain technology and public RPC services connected to TRON, Aptos, and BNB Smart Chain to retrieve encrypted follow-on payloads.

The campaign ingeniously concealed its code within files that appear innocuous to many developers, such as vite.config.js, fake .woff2 font files, and .vscode/tasks.json. This tactic is effective because many dependency scanning tools primarily focus on package manifests and lockfiles, often overlooking editor settings, workspace automation, or repository configurations. The earlier hidden JavaScript loader campaign also demonstrated how PolinRider utilized such files to deliver DEV#POPPER and OmniStealer payloads.

What You Should Do

• Organizations should scrutinize blockchain traffic originating from build runners and developer endpoints, especially if there is no legitimate Web3 business requirement.
• Regularly review package lifecycle scripts and thoroughly inspect repository configuration files for anomalies.
• Implement strict isolation for CI/CD runners to limit the blast radius of potential compromises.
• Restrict outbound network connections from build systems to only essential services.
• Immediately rotate all credentials accessible from any host identified as affected by these campaigns.

Indicators of Compromise (IoCs)

Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.