Source: Unit 42, “The Permanent Threat: Analyzing Aeternum’s Blockchain-Based C2 Operations and Communications”.

Unit 42’s latest Aeternum research is a good reminder that command-and-control is no longer limited to domains, VPS infrastructure, or throwaway cloud accounts. Aeternum moves part of that control plane onto the public Polygon blockchain, where infected Windows systems can query public RPC endpoints and read commands from smart contracts. That makes the operation cheaper to run, harder to remove, and awkward for defenders who still treat “C2” as a simple domain-blocking problem.

What Unit 42 Found

Aeternum is described as a C++ botnet loader that establishes persistence, performs host reconnaissance, and then pulls instructions from Polygon smart contracts. Instead of beaconing to a traditional C2 server, the loader sends JSON-RPC requests to public Polygon RPC infrastructure. The smart contract response contains command data that the malware can decrypt and act on.

Unit 42 analyzed multiple related samples and activity paths, including:

  • A Windows loader that persists through the user’s Startup folder and retrieves commands from Polygon-based smart contracts.
  • Payload staging through GitHub-hosted files, including a malicious DLL paired with legitimate-looking tooling.
  • Telegram API usage for exfiltration from infected hosts.
  • A separate blended intrusion chain involving XWorm RAT, XMRig cryptocurrency mining, and data theft.

The practical takeaway is that Aeternum is not just “malware using crypto buzzwords.” It is an example of adversaries using public, resilient infrastructure as part of the operational stack: blockchain for command retrieval, GitHub for payload staging, Telegram for exfiltration, and commodity malware for access and monetization.

Why Blockchain-Based C2 Changes the Defender’s Problem

Traditional C2 takedowns often depend on removing or blocking attacker-controlled domains, servers, or hosting accounts. Aeternum complicates that model. If commands are stored in a public smart contract and bots can query widely used RPC endpoints, there may be no single attacker-owned server to seize. Blocking the entire public service is often unrealistic because legitimate applications may rely on the same ecosystem.

That creates a defensive tension: the infrastructure looks “trusted enough” at the domain layer, while the malicious behavior is visible in the pattern, payload, and endpoint context. For small businesses and government contractors, this matters because commodity security stacks may allow traffic to well-known services unless the endpoint and network telemetry are correlated.

What to Watch For

A few detection angles stand out from Unit 42’s analysis:

  • Unexpected JSON-RPC traffic from user workstations. Most accounting, HR, engineering, and admin endpoints should not be making Polygon RPC calls. Treat that as suspicious unless there is a known business reason.
  • Startup-folder persistence combined with unusual AppData execution. Aeternum’s persistence path is not exotic, but it is effective. Monitor new shortcuts and binaries launched from user-writable locations.
  • GitHub downloads followed by DLL execution. GitHub is heavily used by legitimate developers, which is exactly why attackers abuse it. Non-developer endpoints pulling executables or DLLs from raw repositories deserve scrutiny.
  • Telegram API traffic from servers or user endpoints. Telegram may be legitimate in some environments, but outbound bot API usage from corporate endpoints is a strong investigation candidate.
  • Miner and RAT behaviors in the same chain. XMRig activity is often treated as low-priority “resource theft,” but in this case it appears alongside remote access and data exfiltration behavior.

Defensive Actions for SMBs and Gov Contractors

This is the kind of threat where basic hygiene still matters, but it needs to be paired with better egress awareness.

  • Baseline outbound traffic. Know which systems actually need GitHub, Telegram, Pastebin, public blockchain RPC endpoints, and other developer or messaging platforms.
  • Block or alert on high-risk services by role. A developer workstation may need GitHub. A finance laptop probably does not need to download DLLs from it. A file server should not be talking to Telegram’s bot API.
  • Monitor user-writable execution paths. AppData, Temp, Downloads, and Startup folder changes should be visible in EDR or logging.
  • Use DNS and HTTP telemetry together. Domain allowlists alone will miss this class of abuse. Look at URL paths, request methods, user agents, process lineage, and destination category.
  • Separate “allowed service” from “allowed behavior.” Public infrastructure can be abused. Treat GitHub, Telegram, Pastebin, and blockchain RPC as services that require context, not automatic trust.
  • Hunt for commodity payload overlap. Look for XWorm indicators, miner process names, suspicious process injection, and security-tool termination attempts.

Bulwark Black Assessment

Aeternum is a useful case study because it shows where cyber defense is headed: not necessarily more sophisticated malware on every host, but more resilient abuse of public infrastructure around the host. The loader, persistence, and payload execution are familiar. The durable command layer is the twist.

For smaller organizations, the answer is not to become blockchain experts overnight. The answer is to get serious about endpoint visibility, role-based egress controls, and alerting on unexpected use of public platforms. If your network cannot explain why a workstation is querying blockchain RPC endpoints, pulling binaries from GitHub, and talking to Telegram APIs, you have a hunting lead worth pursuing.

Read the original Unit 42 research here: The Permanent Threat: Analyzing Aeternum’s Blockchain-Based C2 Operations and Communications.