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

KUALA LUMPUR, 13 AUGUST 2026 —

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. If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team .

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. 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. The pattern of encryption keys for the Aeternum loader (i.e., \x00\x00\x00[ENC bytes]\x00[KEY bytes]\x00\x00\x00 ) consists of: 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.

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. Figure 2 shows an example of the communications traffic filtered in Wireshark.

This section explores how Aeternum performed C2 communications on the Polygon blockchain and how it uses different smart contract addresses to retrieve C2 commands. 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 . Following the JSON-RPC request, if the RPC response is an HTTP 200 OK, it will include a JSON object containing the result field with its corresponding payload. This is structured with the following byte sequence: Building on existing research, we observed that Aeternum implements a substandard encryption scheme. Specifically, it uses a self-salting password.

The US National Institute of Standards and Technology (NIST) considers a self-salting password a critical cryptographic flaw via predictable salt and public key derivation source, in their remediation standard: NIST SP 800-132 . This oversight allows the decryption of the malicious payload by using two known variables: the smart contract address and the payload.

We used a custom Python script to automate the decryption process, which expects the two values passed to it: the contract address and the hex-string payload, as mentioned above. Figure 4 shows the results of this script run on an encrypted Aeternum blockchain value.

In this case, the decrypted string contains the Aeternum command all:url: <URI for putty.exe > , which is a command used to instruct the botnet to proceed and fetch the target file. Although the analyzed sample uses encryption, we found additional samples using plain-text C2 commands, as well as an unknown encrypted payload. The malware download requested two different files, putty.exe and DotNetZip.dll , as Figure 5 below shows.

While investigating the malware’s downloader activity, we found requests for file artifacts hosted on GitHub in two different Github projects. Figure 6 shows the malicious DLL in an October 2025 commit from one repository. The hosted putty.exe file is a copy of a legitimate installer for PuTTY version 0.83. The DotNetZip.dll file is a malicious DLL file. While this Aeternum loader sample retrieved legitimate files like PuTTY, this is likely for testing.

Attackers could easily swap files in these repositories for malware using the same filename, instantly compromising the safety of anyone who downloads them. After successfully downloading DotNetZip.dll from GitHub and executing it, the malware sample initiated new communications to an endpoint at Telegram’s API ( api.telegram[.]org ). As a DLL, the malware's entry point DllMain() first checks for a specific condition by comparing fwReason to 1 to confirm it is being called.

Then it invokes the CollectAndSendSystemInfo() function, as shown below in Figure 7. This function is in charge of all the information gathering and data exfiltration from the compromised machine. The most notable information about this sample is its lack of obfuscation or encryption, as both the chat_id value ( -4991861036 ) and the bot’s API token ( 8305917772:AAHAou... ) are hard-coded, as Figure 8 shows in the disassembled code.

Once the malware has collected all the information, it constructs an HTTP request to exfiltrate the information. The structure of this HTTPS request through the Telegram API follows: Figure 9 shows an exfiltration request revealed using Burp Suite that contains an example of the data collected by the malware sample.

The text in the image is in Russian (i.e., ДОПОЛНИТЕЛЬНАЯ ИНФОРМАЦИЯ , which translates to Additional Information ) and uses Cyrillic characters, which require… (AI-assisted rewrite, based on the original source)

Related: Intel