Dead Drops on the Chain: Why Blockchain Became the C2 Infrastructure Defenders Can't Take Down

Your incident response playbook has a step that says “take down the C2 infrastructure.” File abuse reports, contact the hosting provider, coordinate with domain registrars, maybe get law enforcement involved. The domain goes dark. The campaign collapses.

That playbook has a hole in it now, and attackers spent 2025 and early 2026 systematically exploiting it. When a malware campaign’s command-and-control channel runs through a smart contract on Polygon or a memo field in a Solana transaction or a canister on the Internet Computer Protocol network, there is no abuse report to file. There is no hosting provider to call. The C2 infrastructure is distributed across thousands of nodes in dozens of countries, replicated indefinitely, and will continue to function regardless of what any individual defender or law enforcement agency does.

This is not a theoretical concern. In the first quarter of 2026 alone, at least five distinct malware campaigns used blockchain as C2 infrastructure. Two of them hit your CI/CD pipeline directly. One was a self-propagating worm that spread to 141 npm packages before detection. The other compromised Trivy — the container scanner that’s embedded in most modern pipelines — and used it as a beachhead.

The technique has graduated from proof-of-concept to operational standard. Here’s what’s happened, how each variant works, and what you can realistically do about it.

The Evolution: From October 2023 to March 2026

The core insight behind blockchain C2 is simple: if you store a URL (or a command, or an encryption key) in a blockchain transaction, that data becomes permanently immutable and globally accessible. There’s no single point of failure for defenders to target.

EtherHiding (October 2023) was the first public documentation of this technique in active campaigns. Threat actors injected malicious JavaScript into compromised WordPress sites. The JS retrieved its next-stage payload URL not from a traditional C2 server but from a smart contract deployed on BNB Smart Chain. The contract simply stored a URL string. Whenever the attacker wanted to rotate payloads, they updated the contract. No domain to seize. No IP to block. The campaign ran for months before researchers understood the full architecture.

By 2025, EtherHiding had been adopted by nation-state actors. Google Threat Intelligence Group documented UNC5342 — a DPRK-linked group — incorporating BNB Smart Chain contracts into the Contagious Interview campaign. A second group, UNC5142, built a three-tier contract architecture on BNB Smart Chain: an anchor contract pointing to a router contract pointing to payload contracts. This design allowed them to rotate payloads without touching the anchor contract, making it harder to track through blockchain explorers.

NeoShadow (December 2025) brought the technique into the npm supply chain. Four malicious npm packages queried an Ethereum smart contract via the Etherscan API to resolve a dynamic C2 base URL. The Etherscan query looked like routine developer activity in environments where Web3 code is common. If the smart contract approach failed, the malware fell back to a hardcoded domain — suggesting the blockchain channel was being used specifically for its resilience, not its secrecy.

Aeternum (December 2025, publicly disclosed February 2026) commercialized the technique. A threat actor operating under the alias LenAI began advertising a C2 framework on underground forums: $200 for a configured build, $4,000 for full source code. The loader is a native C++ binary — 32-bit and 64-bit builds — that reads encrypted commands from Polygon smart contracts by querying public RPC endpoints. The operational cost to the attacker is negligible: $1 in MATIC covers 100 to 150 command transactions. Aeternum includes anti-analysis checks for virtualized environments and integrates with Kleenscan to verify builds against AV signatures before deployment. This is commodity tooling, not nation-state capability.

CanisterWorm (March 2026) introduced a new blockchain: the Internet Computer Protocol. And it introduced a new delivery mechanism: a self-propagating worm. The initial foothold was a compromised Trivy maintainer account — Trivy being the container vulnerability scanner embedded in most Kubernetes-focused CI/CD pipelines. The malicious Trivy versions shipped a backdoor that beaconed to an ICP canister every 50 minutes, fetching a URL to download and execute. The worm component extracted npm auth tokens from infected developer machines and used them to publish backdoored versions of other packages, which then continued the cycle. By the time containment was achieved, 141 malicious package artifacts across 66+ npm packages had been published.

GlassWorm (January–March 2026) took a different approach to the same problem. Instead of smart contracts, it used transaction memo fields on the Solana blockchain. Each infected system polls transactions from a hardcoded wallet address and reads the memo field for a base64-encoded payload URL. Between November 2025 and March 2026, researchers identified 50 memo transactions updating the payload URL as the attacker rotated infrastructure. GlassWorm infected 433+ components across GitHub, npm, VS Code, and OpenVSX, stealing SSH keys, npm tokens, GitHub PATs, browser sessions, and credentials for 49 cryptocurrency wallet extensions. A later wave switched from Unicode-based obfuscation to compiled Rust binaries.

Why Each Blockchain Choice Matters

These campaigns didn’t all pick the same chain by accident. The choice of blockchain encodes specific operational priorities.

BNB Smart Chain is cheap and fast. A smart contract update costs fractions of a cent. The chain has enough legitimate Web3 traffic that querying it doesn’t stand out in aggregate flow analysis, and it’s less scrutinized than Ethereum mainnet.

Ethereum is the most widely trusted chain for anything involving developer tooling or Web3 applications. Querying an Ethereum contract via Infura or Alchemy looks indistinguishable from any dApp or development workflow. The Etherscan API is particularly useful: it’s a legitimate public service, and querying it for contract state generates no alerts in most environments.

Polygon is Ethereum’s primary Layer 2 — it inherits Ethereum’s legitimacy while offering lower transaction costs. For a C2 framework that needs to send hundreds of commands per infected host per day, Polygon’s economics make sense. Aeternum’s $1-per-150-transactions price point is achievable because of Polygon’s fee structure.

ICP canisters are a fundamentally different beast. A canister isn’t just data storage — it’s a running computation that can update its own state, serve HTTP responses, and be programmed with access controls. The ICP canister CanisterWorm used supported get_latest_link, http_request, and update_link methods. The last one allowed the attacker to change the payload URL at will without re-deploying anything. The canister also functions as a kill switch: when the attacker points it at youtube.com, all implants enter a dormant state. This is more sophisticated C2 logic than “store a URL in a transaction.”

Solana memos are the lowest-friction approach. Memo fields on Solana were designed for attaching human-readable notes to transactions — things like payment references or exchange withdrawal tags. GlassWorm repurposes them as dead drops. Each memo transaction costs a fraction of a cent. The data is permanent, public, and indexed by every Solana RPC provider. Rotating infrastructure requires publishing a new transaction from any wallet address, with no contract deployment required.

How Detection Fails

The reason blockchain C2 has accelerated so quickly is that it defeats most of the assumptions underlying traditional C2 detection.

Domain reputation is irrelevant. The C2 channel doesn’t use a freshly registered domain or a bulletproof hosting provider. It uses api.mainnet-beta.solana.com, rpc.ankr.com/polygon, or ic0.app. These are production infrastructure domains for major blockchain networks. They have impeccable reputations. They’re used by legitimate applications every day.

Takedown doesn’t apply. Standard incident response includes submitting abuse complaints to domain registrars and hosting providers. There is no registrar for ic0.app. The ICP Foundation cannot remove a deployed canister (by design — that’s the whole point of the platform). Solana validators will not stop processing memo transactions because one wallet address was used for malware C2.

Flow analysis catches the wrong thing. If you’re looking for unusual outbound connections to unfamiliar infrastructure, you’ll miss this entirely. The traffic flows to well-known, high-reputation endpoints that your security tools have probably already greenlit for Web3 developers on your team.

Payload is one hop away. The blockchain doesn’t carry the actual malware — it carries a URL. The malware fetches the payload from a conventional HTTP server. This separation means that even if you detect and block the actual payload delivery, you haven’t disrupted the C2 channel itself. The attacker can stand up a new payload server in minutes while the blockchain URL pointer remains unchanged.

What You Can Actually Do

I’ll be direct here: you cannot prevent attackers from publishing blockchain transactions. You cannot get C2 channels taken down. Your options are limited to detection and disruption at your own network perimeter. But those options are more meaningful than they might appear.

Block blockchain RPC endpoints you don’t use

Most enterprise networks have no legitimate reason to query Solana RPC nodes, ICP canisters, or Polygon JSON-RPC endpoints. If your engineering team isn’t building Web3 applications, these endpoints should be blocked at your egress proxy or firewall.

Key domains to block or alert on for non-Web3 environments:

• api.mainnet-beta.solana.com (Solana)
• ic0.app and *.ic0.app (ICP)
• rpc-mainnet.polygon.technology, polygon-mainnet.g.alchemy.com, rpc.ankr.com/polygon (Polygon)
• bsc-dataseed.bnbchain.org and variants (BNB Smart Chain)
• mainnet.infura.io, eth-mainnet.g.alchemy.com (Ethereum — harder to block if you have Web3 devs)
• api.etherscan.io — commonly abused for contract state queries

For Web3 development environments, this is harder. Consider alert-only rules that flag unexpected processes (CI/CD runners, production services) making blockchain API calls, as distinct from developer workstations.

Write a detection rule for the process making the blockchain call

The Elastic detection rule for EtherHiding catches this correctly: the signal isn’t the destination domain, it’s the combination of process and destination. A bash or python3 process spawned as a systemd user service querying ic0.app is anomalous. A Chrome browser process doing it is not.

Pseudocode for a detection rule:

1
2
3

process.name in ("bash", "sh", "python3", "node", "curl") AND
destination.domain matches (blockchain_rpc_list) AND
NOT process.parent.name in ("code", "cursor", "electron", "chrome", "firefox")

Adjust the process whitelist for your environment. The goal is to catch scripted/automated blockchain queries from non-interactive processes.

Hunt for the CanisterWorm persistence pattern

If you run npm-based CI/CD, check for the CanisterWorm persistence artifacts:

1
2
3
4
5
6
7
8
9

# Check for the persistence unit
find / -name "pgmon.service" -path "*/systemd/user/*" 2>/dev/null

# Check for the working files
find /tmp -name "pglog" -o -name ".pg_state" 2>/dev/null
find ~/.local/share -name "pgmon" -type d 2>/dev/null

# Check for active service
systemctl --user list-units | grep pgmon

The backdoor sleeps five minutes before first beaconing — specifically designed to outlast shallow sandbox analysis. If you’re doing dynamic analysis of suspicious packages, extend your sandbox dwell time to at least 10 minutes.

Audit your supply chain exposure window

Both CanisterWorm and GlassWorm exploited the window between publication and detection. CanisterWorm was live for roughly 48 hours before containment; GlassWorm had months of operational time before full exposure.

If your builds consume packages by floating version (^1.0.0 or latest) rather than pinned digests, you’re accepting that window as part of your threat model. The mitigation is:

1. Pin package versions with exact specifiers
2. Use lockfiles (package-lock.json, Cargo.lock) and commit them
3. Verify package integrity using npm audit signatures
4. Consider a private registry mirror that delays new versions by 24-48 hours for inspection

The last option is operationally annoying but it’s the most effective control against zero-day supply chain attacks. CanisterWorm’s active window was under 48 hours. A 48-hour hold on new package versions would have stopped it entirely.

Monitor for exfiltrated npm tokens

GlassWorm and CanisterWorm both target npm authentication tokens. After the disclosure of either campaign, you should rotate all npm tokens associated with developer machines in your environment. Additionally:

1
2
3
4
5
6
7
8
9

# Check for npm token exposure in environment variables
env | grep -i npm
env | grep -i node_auth

# Audit active npm tokens
npm token list

# Rotate all tokens
npm token revoke $(npm token list --json | jq -r '.[].token')

GitHub Actions workflows that use NODE_AUTH_TOKEN or NPM_TOKEN secrets should have those secrets rotated, and you should verify that your OIDC-based publishing configurations don’t fall back to long-lived tokens.

The Uncomfortable Implication

Here’s the part that doesn’t get said often enough: the security community’s standard C2 disruption model is built on the assumption that attackers need infrastructure that can be seized or shut down. That assumption is now wrong for a growing class of threats.

The EtherHiding technique was documented in 2023. It was adopted by DPRK nation-state actors in 2025. It was packaged into a commodity MaaS tool available on underground forums in late 2025. By March 2026, two separate supply chain campaigns were using blockchain C2 against npm and Rust ecosystems simultaneously. This is the standard diffusion timeline for effective attacker techniques: nation-state use → commoditization → widespread adoption. We’re at stage three now.

The answer isn’t to abandon the existing IR playbook — you still need to handle the cases where C2 uses traditional infrastructure. But any detection or response program that doesn’t account for blockchain-hosted C2 has a significant gap that attackers are actively exploiting.

The tools to address that gap exist: process-aware network detection, egress controls on blockchain RPC endpoints, supply chain controls that shrink the exposure window. None of them require you to wait for the blockchain ecosystem to develop an abuse program. They require you to accept that the C2 infrastructure isn’t going away, and design your defenses around blocking access to it rather than taking it down.

Your incident response playbook needs a new step: “If C2 infrastructure is blockchain-hosted, proceed to network-level blocking of RPC endpoints and extend post-incident hunt scope to cover developer credential theft.” The old step — “take down the C2” — doesn’t apply.

Quick Reference: Blockchain C2 in Q1 2026