Attackers are increasingly exploiting public blockchains as command-and-control (C2) channels in software supply chain attacks, especially targeting cloud credentials. Rather than baking fixed malicious domains or IP addresses into malware, threat actors are querying smart contracts or on-chain transactions at runtime to determine where to send stolen data. This approach evades static domain blacklists and hardens malicious infrastructure against takedowns.
How these attacks unfold
One recent case—dubbed “ChainDrop”—illustrates this shift toward Web3-enabled C2 methods. Over 400 npm packages were compromised with a self-propagating worm. Once installed, the malicious packages harvested sensitive developer credentials: service account keys, GitHub and npm tokens, SSH keys, credentials from Kubernetes, Terraform state files, and secret tokens stored in memory and environment or metadata services. Continuous integration pipelines and developer workstations were both affected.
The malware leverages an Ethereum smart contract for C2 resolution. When launched, it queries the contract to determine its data exfiltration endpoint—a domain that can be switched at will via on-chain transactions. ChainDrop, for example, rotated its active C2 domain from npm-cache[.]com to awqhnjewqjkl[.]icu without needing to update or re-publish the compromised packages.
PolinRider and other campaigns widen the scope
A separate campaign, PolinRider, has pushed beyond npm into Go modules, Packagist, and Chrome extensions. This activity—linked to North Korea–aligned actors—used public RPC endpoints on TRON, Aptos, and BNB Smart Chain to fetch follow-on encrypted payloads. To hide in plain sight, loaders were disguised within normal-looking files like vite.config.js, fake font files, and workspace configurations.
These tactics subvert common defenses: dependency manifest and lockfile scanning often miss malicious delivery via editor settings, workspace automation, or repository-level configuration files. This makes attacks harder to detect before the damage is done.
Detection and mitigation strategies
Organizations without legit Web3 use should treat unexpected blockchain interactions from build environments or developer machines as a significant red flag. It’s critical to audit package lifecycle hooks (preinstall scripts, etc.), review repository and editor configuration files, isolate CI/CD runners, restrict outbound connections from build agents, and rotate any credentials exposed during an incident.
Threat intelligence has identified several indicators of compromise (IoCs) in these campaigns, including specific Ethereum smart contract addresses, wallet addresses, domains (both original and rotated ones used for exfiltration), and file artifacts like obfuscated JavaScript payloads and workspace configuration files set to trigger on project open or coding session start.
These new forms of attack tap into the very tools developers use daily—package managers, CI/CD workflows, editor extensions—underscoring the vulnerability of modern software supply chains. By using Web3 infrastructure as dynamic, decentralized back-ends, attackers gain flexibility and stealth at the cost of traditional detection methods.
What this means: supply chain security is entering a Web3 era. Implementing rigorous credential hygiene, build isolation, and thorough scanning of both code and configuration files are no longer optional—they’re essential. And security teams must treat blockchain traffic—especially when unexpected—as a signal, not noise.
