The Permanent Threat: Analyzing Aeternum’s Blockchain-Based C2 Operations and Communications

Executive Summary

Aeternum is a recently discovered C++ botnet loader that shifts its command-and-control (C2) infrastructure entirely to the public Polygon blockchain. Instead of relying on centralized servers or domains, threat actors operate Aeternum by writing encrypted and plaintext instructions directly using smart contracts. A smart contract is a self-executing program stored on a blockchain that automatically runs when specific conditions are met.

Infected devices continuously query public remote procedure call (RPC) endpoints to retrieve and execute these on-chain commands.

The Aeternum botnet uses decentralized networks and evasion techniques, such as virtual machine detection and antivirus scanning, to operate effectively. This combination establishes a highly resilient, low-cost threat that complicates existing law enforcement takedown methods.

In this article, we analyze three malware cases linked to the Aeternum botnet:

• Aeternum’s loader, C2 and downloader communications
• Related Python-based malware using the Telegram API for C2
• A blended threat consisting of XWorm RAT, the XMRig cryptocurrency miner and data exfiltration

Palo Alto Networks customers are better protected from the threats discussed in this article through the following products and services:

• Advanced WildFire
• Advanced URL Filtering and Advanced DNS Security
• Next-Generation Firewall with Advanced Threat Prevention
• Cortex XDR and XSIAM

If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team.

Background on Aeternum

This article builds upon research by the Ctrl-Alt-Intel team on the Aeternum C2 architecture and the loader binary. That previous research primarily focused on host-based activity.

This malware advertises itself as Aeternum C2 BotNet Loader, and security researchers call it either Aeternum C2 or Aeternum loader.

Our analysis focuses on three malware samples associated with Aeternum activity. Our first sample is the Aeternum loader.

Sample One: Aeternum Loader

SHA256 hash: 5bfb25b8255b61e5ffdf6804451534bcfa9f1dfd225e6c8cdcefb5f50d846898

Sample Characteristics

This Aeternum loader sample is named Build.exe. It is the initial UPX-packed 32-bit portable executable (PE) Windows malware file compiled in C++. Its primary functions are to establish a persistent presence, perform reconnaissance and communicate with the decentralized Polygon blockchain to retrieve encrypted C2 commands.

Behavioral Analysis

The overall flow of this sample executes in multiple stages:

1. Initial execution and self-unpacking
   1. Build.exe executes a multi-stage self-unpacking sequence
2. Persistence and setup
   1. Creates a folder under the user's AppData\Local directory and copies itself to it
   2. Creates a Windows shortcut under the program menu's Startup directory (Wmi_Framework_APIKEY_wmsnet_<random_value>.lnk) to ensure auto-launch upon reboot
   3. Executes supporting binaries (wmiframework.exe, ZrvEsJQzWQ.exe, STAAAAAS.exe)
3. Configuration retrieval and network communications
   1. Deobfuscates global configuration data to produce parameters used to construct network endpoint strings
   2. Sends JSON-RPC requests to Polygon RPC endpoints (decentralized C2 communication)
   3. Queries immutable smart contract addresses using the contract method 0xb68d1809 to retrieve encrypted C2 commands
   4. Decrypts the payload using a weak PBKDF2HMAC/AES-GCM routine
4. Downloader and payload execution
   1. Downloads files as instructed by the C2 server, such as a clean putty.exe and the malicious DotNetZip.dll, from GitHub repositories
   2. Executes the malicious DLL, which uses hard-coded credentials to connect to a Telegram C2 bot (DLLSendC2Bot)
5. Exfiltration
   1. Packages the stolen information for exfiltration over encrypted channels to trusted domains, code-hosting platforms and the Telegram API

Static Deobfuscation (XOR)

The pattern of encryption keys for the Aeternum loader (i.e., \x00\x00\x00[ENC bytes]\x00[KEY bytes]\x00\x00\x00) consists of:

• Three null bytes followed by the encrypted payload bytes
• A null byte, followed by the key bytes
• Three null bytes

Since the pattern is known, a script can identify the different number of occurrences along with its offsets. When found, we can then use the key to deobfuscate the hidden information.

Figure 1 shows two examples of the decryption process against two different obfuscated string matches and their deobfuscated values. These values consist of the JSON object strings used for HTTP-based C2 communication during the execution of the malware and its subsequent interaction with the Polygon blockchain.

Additional deobfuscated strings also include:

• Polygon RPC endpoints (i.e., hxxps[:]//polygon-mumbai-bor-rpc.publicnode[.]com)
• File extensions (.e.g, .ps1, .dll, .exe)
• HTTP header information (i.e., User-Agent)
• C2 command information (e.g., hwid, args, ping)
• Smart contract method (i.e., 0xb68d1809)

However, we suspect that this particular sample differs from others, since we did not find the smart contract addresses either through deobfuscation or plain-text pattern search. During network analysis, this sample used 22 different smart contract addresses during C2 communications.

The full table of deobfuscated strings can be found in the Indicators of Compromise section of this article.

Network Traffic

The Aeternum loader performed the following activities as part of its downloading and C2 communications:

• Communicating with the Polygon blockchain network
• Downloading files from GitHub repositories
• Interacting with social media via Telegram’s API (api.telegram[.]org)

Figure 2 shows an example of the communications traffic filtered in Wireshark.

Aeternum Polygon Blockchain C2 Communications

This section explores how Aeternum performed C2 communications on the Polygon blockchain and how it uses different smart contract addresses to retrieve C2 commands.

Polygon’s JSON-RPC (HTTP Request Analysis)

This sample made a JSON-RPC request using HTTP to the Polygon blockchain. Figure 3 shows the TCP stream of an HTTP POST request to the Polygon RPC endpoint, which includes a JSON object with two important fields: to and data. The to field contains the contract address, and the data field contains the Polygon contract's getDomain() method 0xb68d1809.