// 4 ZERO-DAY · 7 CVE · 4 EXPLOIT IN THE LAST 24H
Unit 42 analyzes Aeternum, a C++ botnet loader that moves command-and-control entirely onto the public Polygon blockchain. On August 10, 2026, the paradox emerges: the public visibility of the chain protects the operator more than the victim.

On August 10, 2026, Palo Alto Networks Unit 42 published its analysis of Aeternum, a C++ botnet loader that uses smart contracts on the public Polygon blockchain as its sole command-and-control infrastructure. Infected devices query public RPC endpoints to read encrypted and plaintext instructions written on-chain. This analysis rests on a single Unit 42 technical report, without independent confirmation.

Key Takeaways
  • Aeternum is a C++ botnet loader that uses smart contracts on the public Polygon blockchain for C2 infrastructure.
  • The analyzed sample used 22 different smart contract addresses, discovered only through network analysis, not deobfuscation.
  • PBKDF2HMAC encryption with self-salting (password used as salt) violates NIST SP 800-132 and enables deobfuscation with two known variables.
  • A secondary DLL (DotNetZip.dll) connects to a Telegram bot with hard-coded credentials for additional C2.

The Mechanism: On-Chain Commands, No Server to Take Down

Threat actors "operate Aeternum by writing encrypted and plaintext instructions directly using smart contracts," according to Unit 42. Infected devices send JSON-RPC HTTP POST requests to public Polygon endpoints, with a 'to' field for the contract address and a 'data' field containing method 0xb68d1809 (getDomain()). The HTTP 200 response contains the payload.

The sample used 22 different smart contract addresses. As the researchers themselves note: "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." The addresses are not hard-coded in the binary.

"Aeternum is a recently discovered C++ botnet loader that shifts its command-and-control (C2) infrastructure entirely to the public Polygon blockchain" — Palo Alto Networks Unit 42

The Sample and Its Structure

The analyzed sample has SHA256 hash 5bfb25b8255b61e5ffdf6804451534bcfa9f1dfd225e6c8cdcefb5f50d846898 and filename Build.exe. It is a 32-bit Windows PE, UPX-packed. Persistence uses a shortcut in the Startup directory following the pattern Wmi_Framework_APIKEY_wmsnet_<random_value>.lnk.

Build.exe launches three binaries: wmiframework.exe, ZrvEsJQzWQ.exe, and STAAAAAS.exe. The malware downloads putty.exe (verified as legitimate PuTTY 0.83) and DotNetZip.dll (malicious) from GitHub. The GitHub commit for the DLL dates to October 2025.

The Cryptographic Flaw and Deobfuscation

Encryption uses PBKDF2HMAC with SHA256, but with self-salting: the password itself serves as the salt. This violates NIST SP 800-132. The derived key is 32 bytes (256-bit) for AES-GCM.

As Unit 42 states: "this oversight allows the decryption of the malicious payload by using two known variables: the smart contract address and the payload." The recognizable pattern is \x00\x00\x00[ENC bytes]\x00[KEY bytes]\x00\x00\x00.

Telegram as Secondary C2

DotNetZip.dll contains hard-coded credentials to connect to a Telegram bot (DLLSendC2Bot). Traffic to api.telegram[.]org is confirmed in network analysis. Unit 42 analyzed three linked samples: the Aeternum loader, Python malware with Telegram API, and a hybrid XWorm RAT/XMRig threat.

On a hybrid sample, Unit 42 notes methodological caution: "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." This indicates variability across samples, not necessarily a single homogeneous campaign.

Why It Matters

Documented Facts. The primary source does not specify whether the campaign is actively ongoing or historical. It does not quantify victims or impacts. It does not clarify the exact temporal relationship among the three analyzed samples.

DeafNews Interpretation. The Aeternum case presents a structural paradox: Polygon is designed for public visibility and immutability, qualities that here protect the actor more than the victim. Investigators can read commands on-chain, but without automated deobfuscation — which the source developed ad hoc — the volume of 22 contracts makes manual monitoring impractical. The blockchain, sold as trustless, becomes a tool of trust for criminals: the immutability that guarantees legitimate users also guarantees the persistence of malicious commands.

The tension between the chain's public visibility and the actor's opacity is the core of the problem. RPC endpoints are public and cannot be blocked individually; smart contracts are not hard-coded in the malware, so static analysis does not reveal the addresses. Traditional detection based on static indicators — domains, IPs, hashes — hits a limit: addresses change, nodes are multiple, the chain is open.

According to DeafNews interpretation, this does not mean static indicators are useless in absolute terms, but that the source documents a shift: addresses are not in the binary, so static analysis alone does not reveal them. Investigation requires network analysis, which is more expensive and less scalable.

What Changes

For the threat intelligence sector, Aeternum forces a verification: public blockchain platforms have been used before for payload hosting, but here they serve as primary C2. The difference is functional, not merely technical. C2 requires low latency and reliability; the blockchain, with its confirmation times, seems counter-intuitive. Yet the sample uses it, with 22 addresses suggesting adaptation to rate or availability limits.

The source does not specify whether this model is replicable or represents an exception. It does not provide deployment costs or evaluate the "inherent resilience" of the blockchain as an objective fact. Unit 42 does not recommend specific operational mitigations; the analysis is descriptive, not prescriptive.

For analysts, the case documents that deobfuscation is possible — the encryption is substandard — but requires custom development. The self-salting is an error that simplifies defensive work, but only for those with resources for network analysis and dedicated tool development.

The analysis is based on a single technical report from Palo Alto Networks Unit 42, published August 10, 2026, without independent confirmation. Some statements by the authors themselves are marked as "suspect"; the analyzed sample may differ from other variants. The source does not specify whether the campaign is actively ongoing.

Information is based on the cited source and current as of publication.

Sources


Sources and references
  1. unit42.paloaltonetworks.com