Aeternum C2 Abuses Polygon Blockchain to Evade Takedowns and Detection

The landscape of Command-and-Control (C2) infrastructure is undergoing a paradigm shift. For years, defenders have relied on seizing domains and sinking IP addresses to disrupt botnets. However, threat actors are increasingly migrating to decentralized infrastructure to make their operations resilient to traditional takedown methods.

Recently, cybersecurity researchers at Qrator Labs disclosed details regarding a sophisticated botnet loader known as Aeternum. This malware represents a significant evolution in operational security (OpSec) for threat actors. Instead of relying on standard HTTP(S) callbacks to a hardened server, Aeternum stores its encrypted payloads and instructions directly on the Polygon blockchain.

This abuse of blockchain technology presents a unique challenge: you cannot shut down a public blockchain. By anchoring their C2 mechanism to a decentralized ledger, the authors of Aeternum have created a "bulletproof" communication channel that is virtually impossible to disrupt through conventional means.

The Mechanics of Blockchain-Based C2

At its core, Aeternum functions as a loader—a type of malware designed to download and execute additional payloads, such as ransomware or information stealers. The novelty lies in how it retrieves these payloads.

Traditional botnets maintain a list of hardcoded domain names or IP addresses. If security researchers or law enforcement seize these servers, the botnet goes dark. Aeternum bypasses this by treating the public Polygon ledger as a dead drop. The infected host does not connect to a malicious server directly; instead, it connects to a public Polygon RPC (Remote Procedure Call) node—often the same infrastructure used by legitimate cryptocurrency wallets—to read data from the blockchain.

The malware likely monitors a specific wallet address or smart contract for incoming transactions. The input data fields of these transactions contain the encrypted commands or URLs for the next stage payload. Because the blockchain is immutable and public, the data is always available, and the infrastructure (the Polygon network) cannot be taken down by a single authority.

Technical Analysis and TTPs

Understanding the Tactics, Techniques, and Procedures (TTPs) of Aeternum is critical for detection. The malware must interact with the blockchain network, which generates specific network artifacts.

Network Behavior: Endpoints infected with Aeternum will initiate outbound connections to public RPC nodes. While traffic over port 443 may look like HTTPS, and traffic over port 8545 or 80 is standard for Web3, the payload structure differs significantly from standard web browsing. The malware performs JSON-RPC requests to query blockchain state.

Encryption and Obfuscation: To avoid signature-based detection on the blockchain, commands are likely encrypted. However, the act of a corporate workstation suddenly querying Polygon Mainnet data is anomalous in most environments. Organizations that do not engage in cryptocurrency development or trading should see zero traffic to these endpoints.

Threat Hunting and Detection

Detecting blockchain-based C2 requires shifting focus from domain blacklists to behavioral analysis and identifying unauthorized Web3 traffic.

KQL Queries (Microsoft Sentinel / Defender)

The following KQL query hunts for endpoints connecting to known Polygon RPC endpoints or exhibiting signs of blockchain interaction.

DeviceNetworkEvents
| where Timestamp > ago(7d)
// Common Polygon RPC public endpoints and patterns
| where RemoteUrl has "polygon-rpc.com" or 
   RemoteUrl has "polygon.ankr.com" or 
   RemoteUrl has "polygon-mainnet.public.blastapi.io" or 
   RemoteUrl has "rpc.ankr.com" or
   RemoteUrl has "0x" // Hex strings often used in blockchain data paths
| extend ParsedUrl = parse_url(RemoteUrl)
| where isnotempty(ParsedUrl.Path)
| summarize Count = count(), RemoteIPs = make_set(RemoteIP) by DeviceName, InitiatingProcessFileName, RemoteUrl
| order by Count desc

PowerShell Script for Endpoint Audit

You can use this PowerShell snippet to audit processes that have established connections to ports commonly used by Ethereum-compatible RPC clients (8545) or check for the presence of suspicious network connections associated with Web3 activity.

Get-NetTCPConnection -State Established -ErrorAction SilentlyContinue | 
    Where-Object { $_.RemotePort -eq 8545 -or $_.RemotePort -eq 443 } | 
    ForEach-Object {
        $process = Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue
        $remoteAddress = $_.RemoteAddress
        
        # Perform a reverse lookup check (optional) or analyze against known RPC ranges
        $remoteHost = Resolve-DnsName -Name $remoteAddress -ErrorAction SilentlyContinue | Select-Object -ExpandProperty NameHost

        if ($remoteHost -match "rpc|polygon|ethereum|web3|ankr|blast") {
            [PSCustomObject]@{
                ProcessName = $process.ProcessName
                PID         = $process.Id
                RemoteIP    = $remoteAddress
                RemoteHost  = $remoteHost
                Status      = "Suspicious Blockchain Connection Detected"
            }
        }
    }

Python Script for Blockchain Traffic Simulation

Threat hunters can simulate the method of data retrieval to understand what to look for in logs. This Python script demonstrates how a botnet might query a specific transaction on the Polygon network.

from web3 import Web3

# Connecting to a public Polygon RPC node
rpc_url = "https://polygon-rpc.com"
w3 = Web3(Web3.HTTPProvider(rpc_url))

def check_transaction(tx_hash):
    try:
        # Get the transaction details
        tx = w3.eth.get_transaction(tx_hash)
        print(f"[+] Transaction found: {tx_hash}")
        print(f"[+] From: {tx['from']}")
        print(f"[+] Input Data (Potential Payload): {tx['input']}")
    except Exception as e:
        print(f"[-] Error fetching transaction: {e}")

# Example transaction hash (replace with actual intel)
target_tx = "0x1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef"
check_transaction(target_tx)

Mitigation Strategies

Blocking blockchain-based C2 is difficult because blocking the entire Polygon network is not feasible for organizations with legitimate Web3 interests. However, most enterprises do not need their HR or Sales computers talking to the blockchain.

1. Network Segmentation and Egress Filtering: Strictly control which devices are allowed to access public RPC nodes. Implement firewall rules to block access to known public RPC endpoints (e.g., *.rpc.ankr.com, *.blastapi.io, *.polygon-rpc.com) for general user segments.

2. DNS Monitoring: Sinkhole or alert on DNS resolutions to domains associated with public RPC providers.

3. Endpoint Behavior Analysis: Monitor for processes (like powershell.exe or obscure binaries) initiating network connections to non-standard ports or high-entropy destinations associated with crypto infrastructure.

4. Zero Trust Architecture: Assume that a user's credentials may be compromised and rely on device posture checks. A device attempting to access the blockchain should be flagged for immediate investigation if it violates policy.

Conclusion

The emergence of Aeternum signals a new era where malware leverages the very infrastructure designed for decentralization and resilience. Security teams must adapt by hunting for the behavior of blockchain interaction rather than relying solely on indicators of compromise (IOCs) related to static domains. By monitoring for unauthorized RPC traffic, organizations can catch this new breed of resilient botnet before it delivers its final payload.

Related Resources

Security Arsenal Healthcare Cybersecurity AlertMonitor Platform Book a SOC Assessment healthcare Intel Hub