Skip to content

Security1 publisher3 min readPublished

Aeternum puts botnet C2 on Polygon, and leaves defenders no domain to seize

Unit 42 says the C++ loader reads encrypted commands from immutable smart contracts over public RPC endpoints, which turns takedown work into traffic monitoring.

The Watch · Security desk

Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction

Illustration accompanying Aeternum puts botnet C2 on Polygon, and leaves defenders no domain to seize
Generated illustration

What happened

  • Aeternum is a recently discovered C++ botnet loader that shifts its command-and-control 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 the on-chain commands.
  • The Aeternum botnet uses decentralized networks and evasion techniques such as virtual machine detection and antivirus scanning.

Compiled by The WatchSomething wrong?How this is made

Why it matters

Palo Alto Networks' Unit 42 has published an analysis of Aeternum, a C++ botnet loader that moves its command-and-control infrastructure entirely onto the public Polygon blockchain, with operators writing encrypted and plaintext instructions directly into smart contracts instead of relying on centralized servers or domains [1][2]. Infected devices then continuously query public remote procedure call (RPC) endpoints to retrieve and execute those on-chain commands [4], which means the first two moves in most response playbooks, seize the server and block the name, have nothing to act on.

The loader itself is unremarkable. The sample Unit 42 examined, named Build.exe, is a UPX-packed 32-bit Windows PE compiled in C++ [10]. It creates a folder under the user's AppData\Local directory, copies itself there, and drops a Startup shortcut following the pattern Wmi_Framework_APIKEY_wmsnet_<random_value>.lnk to survive reboot [12], then executes supporting binaries named wmiframework.exe, ZrvEsJQzWQ.exe and STAAAAAS.exe [13]. It deobfuscates configuration data to build endpoint strings and sends JSON-RPC requests to Polygon RPC endpoints [14].

The part that breaks the playbook is the retrieval step: the loader queries immutable smart contract addresses using the contract method 0xb68d1809 to pull encrypted commands [15]. A smart contract is a self-executing program stored on a blockchain that runs when set conditions are met [3]. Immutable addresses cannot be repointed or edited away, there is no registrar to serve, and reads travel over third-party RPC providers rather than attacker-owned hosts [23]. Unit 42's assessment is that the combination of decentralized C2 and host evasion, including virtual machine detection and antivirus scanning, produces a highly resilient, low-cost threat that complicates existing law enforcement takedown methods [5][6].

Not every leg is beyond reach. The loader downloads files as instructed, including a clean putty.exe and a malicious DotNetZip.dll, from GitHub repositories [17], and that DLL uses hard-coded credentials to reach a Telegram C2 bot [18]. Exfiltration runs over encrypted channels to trusted domains, code-hosting platforms and the Telegram API [19]. Payload delivery and data theft still depend on commercial platforms that answer abuse reports, even though the instruction channel does not [24].

There are also cheap wins for hunters. Unit 42 describes a fixed obfuscation pattern of three null bytes, encrypted payload bytes, a null byte, key bytes, then three null bytes, which lets a script locate every occurrence and its offset and recover the plaintext [20]. Those strings include the JSON objects used for the loader's HTTP-based C2 traffic [22], which is how you get the contract addresses to watch for. The payload decryption itself uses what Unit 42 calls a weak PBKDF2HMAC/AES-GCM routine [16]. Palo Alto Networks says its own products, including Advanced WildFire, Advanced DNS Security and Cortex XDR, cover the threats described [21], which is a vendor claim on a vendor blog.

Watch whether your egress policy has an opinion about JSON-RPC calls to public blockchain endpoints from workstations that have no reason to make them, because that beacon is now the detection surface. Watch for reuse of the same design by other families; the research builds on earlier Ctrl-Alt-Intel work that focused on host-based activity [8], and Unit 42's write-up already links Aeternum activity to Python malware using the Telegram API and to a blended XWorm, XMRig and exfiltration case [7].

Loading claim ledger
Loading source directory links
Loading share composer
Loading topic controls
Loading related stories