How Traditional C2 Gets Taken Down

The standard playbook for neutralising a botnet is infrastructure disruption: identify the C2 servers, coordinate with hosting providers or law enforcement to seize them, sinkhole the domains so infected hosts connect to a controlled server instead of the attacker's.

It works. The Emotet botnet was taken down by coordinating takedowns across eight countries in 2021. Qakbot was dismantled by the FBI in 2023 through a similar operation. The disruption playbook is mature, internationally coordinated, and reasonably effective — against centralized infrastructure.

Aeternum doesn't have centralized infrastructure.

The Architecture: Ethereum Smart Contracts as C2

Here's what Aeternum does instead:

When the botnet operator wants to send a command to their infected machines, they don't POST to a C2 server. They write a transaction to a smart contract on the Polygon blockchain. The command is encrypted and stored in the transaction's calldata — permanently and immutably, replicated across every Polygon node worldwide.

The infected machines (bots) don't reach out to a C2 server. They poll public Polygon RPC endpoints — the same endpoints used by millions of legitimate Web3 applications, wallets, and DeFi protocols. They query for new transactions to the attacker's contract address. When a new encrypted command appears, they decrypt it and execute it.

The sequence looks like this:

Attacker wallet
   │
   │  ① Encrypt command with hardcoded bot key
   │  ② Submit tx to smart contract on Polygon
   ▼
Polygon blockchain (distributed — 2,000+ validator nodes)
   │
   │  ③ Transaction confirmed and replicated globally
   ▼
Infected machines polling polygon-rpc.com
   │
   │  ④ Detect new transaction to known contract address
   │  ⑤ Decrypt command → execute
   │  ⑥ Optionally write results back to chain or exfil channel
   ▼
Attacker receives results

Why This Is Resilient by Design

Every property that makes blockchains valuable for finance makes them catastrophic for C2 takedown efforts:

The only control point that defenders or law enforcement have is the attacker's wallet. If the private key is identified, it can theoretically be watched (but not seized). Blockchain forensics firms like Chainalysis can trace transaction patterns. But the C2 transactions themselves — every command ever issued to the botnet — will exist on the Polygon blockchain forever.

The Malware Itself

Aeternum's bot binary is a C++ native executable supporting x32 and x64 Windows architecture. Its capabilities include:

• Anti-VM detection — checks for virtualisation artifacts (CPUID tricks, VMware/VirtualBox registry keys, timing anomalies)
• Encrypted C2 polling — regular HTTPS calls to Polygon RPC endpoints
• Remote execution — executes commands received from the blockchain C2
• Standard botnet capabilities — typical for crimeware at this price point: credential theft, DDoS participation, downloader functionality
• C2 panel — a Next.js web application for botnet management (sold with the build)

The malware is sold commercially:

• $200 — panel + compiled bot builder (operator tier)
• $4,000 — full C++ source codebase (developer/reseller tier)

At $200, this puts a blockchain-resilient botnet within reach of relatively unsophisticated threat actors. The operator doesn't need to understand smart contracts, Ethereum, or Polygon. They get a panel. They build their bot. The blockchain infrastructure is handled by the malware itself.

Detection: What You Can Actually Do

You cannot take down the C2. You can detect its use.

Network — The Most Reliable Signal

Aeternum bots communicate via Polygon RPC endpoints. In enterprise environments, no workstation or server should ever be making requests to blockchain RPC infrastructure unless it's explicitly part of the software stack (and you'd know if it was).

Block and alert on DNS queries and HTTPS connections to:

# Polygon RPC endpoints to block / alert on:
polygon-rpc.com
rpc.ankr.com/polygon
rpc-mainnet.matic.network
matic.network (wildcard)
bor.blockpi.network
polygonzkevm-mainnet.g.alchemy.com

# JSON-RPC patterns (content inspection if you have it):
Content-Type: application/json to above hosts
POST bodies containing: {"jsonrpc":"2.0","method":"eth_getLogs"...}
POST bodies containing: "to":"0x[40-char-hex]" (smart contract address)

In a zero-trust environment, this traffic should never appear. A single alert on Polygon RPC access from a non-blockchain workstation warrants immediate investigation.

Endpoint Detection

At the endpoint level:

• Flag any process making regular HTTPS requests to blockchain RPC domains
• Anti-VM detection artifacts in the bot binary are detectable via behaviour analysis — look for CPUID instruction execution outside of known hypervisors
• C++ native binaries with no legitimate software signature making network connections to Web3 endpoints
• Signed certificate validation chains to polygon-rpc.com or related CDNs from unexpected processes

Threat Intel Integration

As Aeternum campaigns are documented, smart contract addresses used for C2 will appear in threat intelligence feeds. Blocking or alerting on connections to known-malicious contract addresses adds another detection layer — though this is inherently reactive rather than preventive.

The Broader Trend: Legitimate Infrastructure as C2

Aeternum is the latest evolution of a well-established attacker strategy: use legitimate, trusted, high-availability infrastructure that defenders can't block without massive collateral damage. We've seen:

• Google Sheets / Google Docs — UNC2814's GRIDTIDE used Google Sheets API as a C2 channel (can't block Google)
• Zoho WorkDrive — ScarCruft's Ruby Jumper campaign (Feb 2026) — North Korean APT using WorkDrive for C2 and USB relay for air-gap bridging
• GitHub, Pastebin, Discord — Various commodity malware families using these platforms for payload hosting and C2
• Blockchain — Aeternum (and earlier research demonstrations)

The defender's challenge in all these cases is the same: the legitimate platform has millions or billions of legitimate users, so you can't block it wholesale. You have to detect the pattern of use — not the destination, but the behaviour. Regular, structured, automated polling. JSON-RPC calls from unexpected processes. HTTPS to crypto infrastructure from non-crypto systems.

Behavioural detection, network baseline anomalies, and zero-trust egress controls are the answer. Perimeter rules and static blocklists are not.

What This Means for Red Teams

From an offensive security perspective, blockchain C2 is a legitimate technique to understand and test your defences against. Red teams should be:

• Testing whether your EDR flags processes making requests to Polygon/Ethereum RPC endpoints
• Validating that your network monitoring alerts on unexpected blockchain API calls
• Verifying that your SOC analysts understand this technique and can triage blockchain RPC alerts correctly

If your security tools pass zero Polygon RPC traffic to analysts today — that's not because you're safe, it's because you haven't built the detection.