Hackers Use Blockchain for Resilient Command-and-Control in Supply Chain Attacks
Threat actors are leveraging public blockchain networks as a resilient command-and-control (C2) layer for supply chain malware, evading traditional defenses and enabling dynamic infrastructure rotation.
Threat actors are increasingly turning public blockchain networks into a command-and-control (C2) layer for software supply chain malware, helping them rotate infrastructure without changing the malicious code already running on developer systems. This method provides criminals with a resilient way to direct infected packages toward new data-theft servers while rendering traditional domain blocklists less effective. The risk is particularly acute for cloud-focused organizations, as poisoned open-source packages can execute within developer laptops and CI/CD pipelines, potentially accessing temporary cloud identity tokens, deployment secrets, service-account keys, GitHub credentials, and other high-value data.
A recent investigation into the ChainDrop npm worm revealed how compromised trusted publishing paths can transform ordinary dependency updates and project settings into a conduit for credential theft. Analysts at Unit 42 identified ChainDrop as a self-propagating npm worm that infected over 400 packages. The malware was found to collect cloud credentials, npm and GitHub tokens, SSH keys, Kubernetes tokens, Terraform state files, Vault tokens, and secrets stored within developer environments. It also scanned the memory of GitHub Actions runner processes for short-lived OpenID Connect (OIDC) tokens and runner secrets.
In a typical malware operation, attackers hard-code a domain or IP address directly into the malware, creating a clear target for defenders. Security teams can block the address, registrars can suspend the domain, and package platforms can scan the code for it. Blockchain C2 fundamentally alters this model. Instead of containing a fixed C2 address, the malware queries a smart contract or blockchain transaction at runtime to retrieve the current destination. ChainDrop exemplified this by querying an Ethereum smart contract to obtain its data-theft address, subsequently moving its C2 from npm-cache[.]com to awqhnjewqjkl[.]icu through a single Ethereum transaction. This rotation occurred without the attackers needing to republish packages or deploy a new malware version to victims.
This technique, often referred to as EtherHiding, does not imply the blockchain itself is malicious. Instead, criminals are exploiting its public and decentralized design as a de facto address book, payload store, or dead-drop service. Previous reports on EtherHiding have detailed how smart contracts can return encoded JavaScript payloads, allowing operators to alter delivery content without modifying a compromised website.
The ChainDrop infection begins with a modified npm package containing a preinstall command. This command executes setup.mjs, which, if absent, downloads the legitimate Bun JavaScript runtime and uses it to run an obfuscated payload. Bun itself was not compromised; threat actors merely utilized the legitimate runtime to execute their malicious code. Once active, the malware probes local files, environment variables, and cloud metadata services for credentials. Crucially, it also inspects running build processes, as CI/CD systems frequently employ temporary credentials that do not persist on disk. These ephemeral tokens can still grant attackers direct access to cloud APIs, deployment environments, or source-code systems while they are valid.
ChainDrop also established persistence through developer tools. It installed a VS Code task designed to run upon folder opening and added 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. The same risk is highlighted by the broader ChainDrop campaign's exposure of trusted local project files as an execution route.
A second campaign, tracked as PolinRider, demonstrates that this model is expanding beyond npm. Researchers have linked this campaign to North Korea-aligned activity, discovering malicious loaders within npm, Packagist, Go modules, and Chrome extensions. These loaders utilized blockchain and public RPC services connected to TRON, Aptos, and BNB Smart Chain to retrieve encrypted follow-on payloads. The campaign concealed its code within files that appeared normal to many developers, such as vite.config.js, fake .woff2 font files, and .vscode/tasks.json. This approach is significant because many dependency scanning tools focus on package manifests and lockfiles, overlooking editor settings, workspace automation, or repository configurations.
For defenders, any blockchain traffic originating from build runners and developer endpoints should be treated as a significant indicator, especially if the organization has no legitimate Web3 business requirements. Security teams should meticulously review package lifecycle scripts, inspect repository configuration files, isolate CI runners, restrict outbound connections from build systems, and implement a policy of rotating every credential reachable from an affected host.