Your Firewall Just Let North Korea Phone Home: The Blockchain C2 Problem

In March 2026, an eSentire incident response team walked into a retail breach and found something new: the malware's C2 address was not in a domain, not in an IP, not in a hardcoded config. It was in an Ethereum smart contract.

The technique is called EtherHiding, and over the last six months it has become the operating model for at least four active malware families and one North Korean APT (UNC5342). It breaks the entire firewall-blocklist model — and most security teams have no detection in place.

How It Works

The mechanics are simple enough that the operating cost is measured in single-digit dollars per month.

1. Attacker deploys a smart contract to a public chain (Ethereum, BNB Smart Chain, or Polygon are the popular choices).
2. The contract stores either the live C2 address or an encrypted command blob — sometimes the full payload.
3. Compromised endpoints query a public RPC endpoint (Infura, Alchemy, polygon-rpc.com, bsc-dataseed.binance.org) over plain HTTPS to read that value.
4. To rotate infrastructure, the attacker sends one transaction updating the contract. Total cost on Polygon: about $0.01.

You cannot take a smart contract down. You cannot seize it. You cannot null-route it. Once it is on chain, it is there for as long as the chain exists.

Who Is Using It

Why Your Firewall Misses It

Traditional defenses break in three places:

• ✗Domain blocklists are useless. The chain is on infura.io, alchemy.com, polygon-rpc.com — legitimate developer infrastructure used by millions of dApps.
• ✗IP blocking does not work. RPC providers run on Cloudflare and AWS. Blocking their ranges breaks your engineering team.
• ✗TLS inspection sees JSON-RPC, not malware. The request looks like any other Web3 call. The malicious string only resolves to a C2 address after on-host parsing.

What Actually Works: Egress by Business Need

The blockchain C2 problem is a special case of the broader egress filtering problem: if a workstation has no legitimate reason to talk to a service, it should not be allowed to. Most networks have nobody on the finance or HR floor who needs to read Ethereum contracts.

Concretely, this means three firewall posture questions:

1. Which policies allow outbound to public RPC endpoints? Find every WAN egress rule that permits HTTPS to *.infura.io, *.alchemy.com, polygon-rpc.com, *.bsc-dataseed.binance.org, *.quicknode.com, *.ankr.com.
2. Which of those policies cover endpoints with no business need? Finance, HR, customer support, retail POS — none of these need to read smart contracts. Engineering and treasury might.
3. Are those policies behind deep inspection? If a JSON-RPC POST is hitting a contract address you have never seen before, that is signal. SSL inspection plus an outbound HTTPS DPI policy on a known-RPC FQDN list can catch it.

What We Are Adding to CRWLR

We are shipping a new check tier in the next release: Blockchain C2 Egress Exposure. For every firewall config CRWLR analyzes, we will flag:

• ✓WAN egress policies permitting HTTPS to the top public RPC providers
• ✓Whether those policies cover non-engineering zones (severity tiering)
• ✓Whether SSL inspection and IPS profiles are attached
• ✓Vendor-specific CLI remediation (FortiGate FQDN groups, PAN-OS URL category, Sophos web filter)

This is exactly the kind of check that does not exist in Tufin or AlgoSec. They think in terms of rule hygiene; we think in terms of what an attacker would actually use this firewall for.

Sources

• Endor Labs — The Unkillable C2
• eSentire — EtherRAT & SYS_INFO Module: C2 on Ethereum
• The Hacker News — Aeternum C2 Botnet on Polygon
• Infosecurity Magazine — North Korean Hackers Use EtherHiding
• MITRE ATT&CK — Tsundere Botnet (S9034)
• VMRay + Iknaio — Tracing Blockchain-Controlled Malware