In-app reader
18 min read
Related Products Advanced DNS SecurityAdvanced Threat PreventionAdvanced URL FilteringAdvanced WildFireCloud-Delivered Security ServicesCortexCortex XDRCortex XSIAMNext-Generation FirewallUnit 42 Incident Response
By:
Published: August 10, 2026
Categories:
Tags:
Share
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:
Cortex XDR and XSIAM
If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team.
Related Unit 42 Topics Malware, Blockchain, C2
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.
SHA256 hash: 5bfb25b8255b61e5ffdf6804451534bcfa9f1dfd225e6c8cdcefb5f50d846898
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 overall flow of this sample executes in multiple stages:
Initial execution and self-unpacking
Build.exe executes a multi-stage self-unpacking sequence
Persistence and setup
Creates a folder under the user's AppData\Local directory and copies itself to it
Creates a Windows shortcut under the program menu's Startup directory ( Wmi_Framework_APIKEY_wmsnet_<random_value>.lnk ) to ensure auto-launch upon reboot
Executes supporting binaries ( wmiframework.exe, ZrvEsJQzWQ.exe, STAAAAAS.exe )
Configuration retrieval and network communications
Deobfuscates global configuration data to produce parameters used to construct network endpoint strings
Sends JSON-RPC requests to Polygon RPC endpoints (decentralized C2 communication)
Queries immutable smart contract addresses using the contract method 0xb68d1809 to retrieve encrypted C2 commands
Decrypts the payload using a weak PBKDF2HMAC/AES-GCM routine
Downloader and payload execution
Downloads files as instructed by the C2 server, such as a clean putty.exe and the malicious DotNetZip.dll , from GitHub repositories
Executes the malicious DLL, which uses hard-coded credentials to connect to a Telegram C2 bot ( DLLSendC2Bot )
Exfiltration
Packages the stolen information for exfiltration over encrypted channels to trusted domains, code-hosting platforms and the Telegram API
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.
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 .
Polygon’s JSON-RPC (HTTP Response Analysis)
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:
Offset ( 0x20 = 32 bytes)
Payload length ( 0x10a = 266 bytes)
Payload (variable values)
Padding (variable length)
Weak Encryption Implementation
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.
The main decryption logic corresponds to the following operations:
PBKDF2HMAC (key stretching): This function uses the SHA256 algorithm to repeatedly hash the password, using the password itself as the salt
**Key derivation: **The kdf.derive(password) performs the key derivation. It takes the encoded password and transforms it into a high-entropy 32-byte (256-bit) cryptographic key.
Advanced Encryption Standard in Galois/Counter Mode (AES-GCM) initialization: The derived key is used to initialize an AES/GCM object
Decryption: The decryption of the ciphertext uses the provided initialization vector (IV) and the payload, resulting in a UTF-8 encoded string
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.
Aeternum Downloader Activity
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:
HTTP Method
POST (submission of the collected information)
Base path and bot token
/bot prefix (required for all Telegram bot API calls)
Concatenated bot API token ( 8305917772:AAHAou… )
API Method (URI path)
/sendDocument (tells Telegram what action the bot should perform. In this case, it is attempting to send a file (e.g., PDF, ZIP) to a chat)
Protocol
HTTP/1.1 (indicates the version of the Hypertext Transfer Protocol being used for the communication)
HTTP Headers
User-agent (set to SystemInfo Bot/2.0 )
Content-Type (set as multipart/form-data with a boundary set as systeminfoboundary )
HTTP Request Body
Form-data, containing the names:
chat_id (The unique identifier for the target chat)
caption (Text to accompany the file)
document (The file to be sent, which in this case is a PNG file named screenshot.png )
The content of the exfiltrated information contains different information from the compromised machine, including:
CPU
RAM
Disk
GPU
Administrator rights check
Windows User Account Control (UAC) status
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 specific encodings like UTF-8 to properly decode.
SHA256 hash: f2a326cff405299e4ebdfaac955c52fc7e496544eaa0921ecad4816cb3ae3a27
Pivoting on characteristics of the first sample, we found several matches using specific patterns based on the smart contract method function ( 0xb68d1809 ). Among these, we identified a 64-bit Windows PE sample that leverages the Aeternum botnet to simultaneously drop an XWorm binary, an XMRig cryptocurrency miner and a data exfiltrator.
The sample is named XBinderOutput_protected.exe and written in C/C++. This PE file is a PyInstaller-packed application containing a Python 3.14 script named XBinderOutput_protected_temp.py .
The embedded script implements multi-layer cryptographic decryption using ChaCha20, AES-CTR and AES-CBC to recover an encrypted payload. The payload is then written to the temporary directory as esewurmgvbqt.exe and executed with a hidden window. The script includes anti-analysis checks for virtual machine environments and debugger presence.
Like the previous sample for Aeternum loader, once executed, this second sample made a JSON-RPC request using HTTP to the Polygon blockchain containing Aeternum’s to and data values. An HTTP 200 OK response was returned as expected, indicating that a command payload was found and its content returned. Figure 10 shows an example of this traffic.
This time, the hexadecimal value response is not encrypted but converts directly to plain text. After translating the hexadecimal values to ASCII, we found a Pastebin URL as noted below in Figure 11.
This URL contains the /raw/ URI path that is designed to return the data as-is, without any further processing by the service. Thus, the malware has less work to do in terms of parsing or processing the retrieved information. This URL returned configuration data for the XMRig cryptocurrency miner.
After the malware retrieved data from the Pastebin URL, it started two binaries it had dropped to the infected host, one for an Xworm client and one for an XMRig cryptocurrency miner.
The Pastebin URL returned the XMRig cryptocurrency miner configuration data as a JSON object containing different fields. These fields included mining-based settings such as:
Algorithm
API-endpoint
Max CPU
Password
Pool
Wallet address
It also included two behavior-based options:
The stealth-target option that enables evasive behavior by blocklisting system monitoring utilities. It triggers a process suspension and its related mining activity upon the execution of diagnostic tools (e.g., Process Hacker) to mask the miner’s footprint and resource consumption.
The kill-targets option that implements process termination as a persistence and resource-optimization strategy. It identifies and kills active processes associated with endpoint security software and distributed computing programs to prevent system remediation and ensure maximum CPU allocation for the miner.
The associated Pastebin URL occasionally returns different data for the XMRig configuration. Despite these changes, the data structure remains identical. Figure 12 displays an example of the XMRig configuration data seen in June 2026.
In addition to the XMRig cryptocurrency miner, the main sample dropped an XWorm client named XWormclient.exe . This filename is the default name used when using the XWorm v7.4 builder, indicating that the author generated and bound it into the malicious package.
We extracted the Xworm sample's configuration using CAPE’s community parser for XWorm. This dump of information contains configuration information as shown below in Figure 13, including:
Version of the builder (XWorm v7.4)
Mutex
C2 server
IP address
Port
Key
Armed with this information, specifically the C2 server key, C2 communication port and XWorm version values, we tricked the sample into connecting to a controlled instance of the matching XWorm panel version. Figure 14 shows a screenshot of the C2 panel after the XWorm sample connected to our controlled instance.
During the final stage of this Aeternum sample's execution, the injected system process starts an information gathering and encryption process.
Figure 15 shows an outbound connection HTTP POST request to a C2 server at 193.221.200[.]219 with a custom user-agent ( cpp-httplib/0.18.3 ) and JSON values containing two keys with Base64-encoded values.
After further analysis and reverse engineering to understand the meaning of those two keys, we discovered that the uqhash value contains an AES-128 encryption key. We also discovered the data value contains the exfiltrated data in an encrypted blob form.
The following section explains the encryption details and the decryption process we followed to reveal the exfiltrated information.
Encryption Routine
The encryption routine takes raw input bytes and pads them with 0x00 until the length is a multiple of 16 bytes. It then derives a fixed 16-byte key by truncating or zero-extending the provided hexadecimal input. The data is processed block-by-block using a 16-byte block cipher in Electronic Code Book (ECB) mode, producing a deterministic ciphertext where each block is independently encrypted. The result is written out without any IV, chaining or authentication, closely matching a typical minimal malware-style encryption wrapper.
The encryption routine has the following characteristics:
Algorithm used: AES-128 (16-byte block cipher) in ECB mode
Key properties: no IV, deterministic output, zero padding (non-standard), identical plaintext blocks → identical ciphertext blocks
Context in this test: binary data from a file is padded and encrypted in-place using a fixed 16-byte key derived from CLI hexadecimal input, mimicking a simple malware/configuration protection routine
Decryption Routine
To decrypt the required information, we developed a script to reverse the encryption process identified during our analysis and reverse engineering. This script takes two parameters:
The encrypted payload file dump
The hexadecimal representation of the Base64-decoded AES-128 key as a single concatenated string
Figure 16 shows the execution of the decryption script, which in this case generated a 580-byte data dump.
By viewing the contents of the output file, the exfiltrated data is revealed as shown below in Figure 17.
Certain behavior (i.e., drop of a .sys file) and network patterns (e.g., URI path, JSON object attributes) match with ZingoStealer reported by Cisco Talos on April 13, 2022. However, we cannot fully attribute this activity to ZingoStealer.
SHA256 hash: ea1b6ff3a0c1a749b9f09d66789973321d63d8896b48f7345193bdad512950a2
Our third sample is a Python script file containing the source code for the Aeternum malware. The key element used to confirm its association with the Aeternum operation is the data value 0xb68d1809 , which functions as the unique function selector used to query the Polygon smart contract.
The code contains a blockchain-based fall-back mechanism to counter infrastructure takedowns. By executing a read-only eth_call to a specific Polygon smart contract, the malware can retrieve and decrypt new C2 domains on the fly. This decentralized dead-drop resolver, combined with the Star Drop space-themed Telegram formatting, highlights an operation designed for resilience and stealth. Figure 18 below shows a section of the Python script illustrating this.
Analysis of the malware’s source code reveals a multi-staged infection chain that begins with a social engineering lure impersonating a DBeaver installer. To ensure it only executes on high-value targets, the c
…(truncated for reading performance)
Discussion
Sign in to join the discussion.
Keep reading
Optional: create a free account to save items, track programs, and sync across web + app. Reading stays free.