When Huntress published its analysis of the FakeAgent campaign in July 2026, one technical detail stood out beyond the Bing malvertising and the fake Claude installer: SectopRAT’s command-and-control infrastructure runs on the Ethereum blockchain. Blocking C2 domains — the standard response to a RAT infection — simply doesn’t work when the malware is reading instructions from a public distributed ledger.

This guide covers what blockchain C2 is, how SectopRAT implements it, and what detection looks like in practice given that you can’t block Ethereum.

How Blockchain C2 Works

Traditional C2 relies on the malware connecting to an attacker-controlled server. You block the domain or IP and the connection breaks. Blockchain C2 flips this. The attacker writes instructions into an Ethereum smart contract or transaction. The malware reads that data by querying any Ethereum node — including public ones — and extracts the payload. There is no dedicated attacker server to block.

SectopRAT’s implementation queries Ethereum contract storage directly for operator configuration — C2 addresses, tasking parameters, and exfiltration endpoints — and rotates those values by having the operator push a new transaction to the contract. From the malware’s perspective, the “server” is a global distributed ledger with no takedown surface.

This technique is sometimes called “dead drop resolver via blockchain” and has appeared across a handful of RAT families over the past two years. SectopRAT is among the more mature implementations, and the FakeAgent campaign is the first time it reached significant enterprise scale.

Why Standard Controls Miss It

Firewall deny lists and proxy category blocks don’t cover Ethereum RPC endpoints. The most commonly queried endpoints — Infura, Alchemy, and public Ethereum JSON-RPC nodes — are cloud services with legitimate use cases. Their traffic looks like HTTPS to a cloud API, which it is.

Sandbox analysis is also limited. SectopRAT uses VMProtect packing and GPU detection to identify virtual environments, causing the blockchain resolution step to either not execute or to resolve to benign content during automated analysis. The C2 behaviour may not appear in sandbox reports.

Detection Approach

Effective detection for blockchain C2 focuses on three signals: process behaviour, DNS patterns, and network connections to known Ethereum RPC infrastructure.

Process anomalies: Legitimate applications that query Ethereum nodes are almost exclusively development tools, Web3 wallets, and specific blockchain clients. If a process that isn’t any of these initiates HTTPS connections to Ethereum RPC endpoints, that’s a high-fidelity signal. SectopRAT in the FakeAgent campaign ran as a child of the malicious ClaudeDesktop.exe installer, which had no legitimate reason to contact any blockchain infrastructure.

Ethereum RPC patterns in DNS: Infura and Alchemy endpoints follow predictable patterns. DNS queries for mainnet.infura.io, eth-mainnet.alchemyapi.io, or cloudflare-eth.com from non-developer endpoints are worth flagging for review. Queries followed by HTTP 200 responses to JSON-RPC methods (eth_call, eth_getStorageAt) are more specific still.

Volume and timing: Blockchain C2 malware typically polls on a schedule rather than maintaining a persistent connection. Periodic outbound HTTPS to Ethereum RPC infrastructure from an endpoint — every 60, 300, or 900 seconds — is more suspicious than a single connection.

Sigma Detection Rule

title: Suspicious Ethereum RPC Connection from Non-Browser Process
id: 7c4b3e91-2f18-4a5c-9d6e-1b8c7f3a2e4d
status: experimental
description: Detects HTTPS connections to known Ethereum JSON-RPC providers from processes that are not known Web3 applications or browsers.
references:
  - https://www.huntress.com/blog/fakeagent-claude-desktop-malvertising-ends-in-dotnet-rat
author: SOC Analyst Hub
date: 2026-07-26
logsource:
  category: network_connection
  product: windows
detection:
  selection:
    DestinationHostname|contains:
      - 'infura.io'
      - 'alchemyapi.io'
      - 'cloudflare-eth.com'
      - 'etherscan.io'
      - 'mainnet.infura.io'
      - 'rpc.ankr.com'
    DestinationPort: 443
    Initiated: 'true'
  filter_browsers:
    Image|endswith:
      - '\chrome.exe'
      - '\firefox.exe'
      - '\msedge.exe'
      - '\brave.exe'
      - '\opera.exe'
  filter_legitimate:
    Image|endswith:
      - '\node.exe'
      - '\hardhat.exe'
      - '\MetaMask.exe'
  condition: selection and not filter_browsers and not filter_legitimate
falsepositives:
  - Web3 development tools
  - Blockchain analytics applications
  - Legitimate DeFi desktop applications
level: medium
tags:
  - attack.command_and_control
  - attack.t1102
  - attack.t1102.002

Tune the filter lists based on what Web3 tooling is legitimately used in your environment. In most enterprise environments, the legitimate list is empty.

Microsoft Sentinel KQL Query

// Detect connections to Ethereum RPC infrastructure from non-browser, non-developer processes
let ethereum_rpc_hosts = dynamic([
    "infura.io", "alchemyapi.io", "cloudflare-eth.com",
    "rpc.ankr.com", "eth.llamarpc.com", "mainnet.infura.io"
]);
let known_web3_processes = dynamic([
    "node.exe", "chrome.exe", "msedge.exe", "firefox.exe",
    "brave.exe", "MetaMask.exe"
]);
DeviceNetworkEvents
| where TimeGenerated > ago(7d)
| where RemotePort == 443
| where RemoteUrl has_any (ethereum_rpc_hosts)
| where InitiatingProcessFileName !in~ (known_web3_processes)
| project
    TimeGenerated,
    DeviceName,
    InitiatingProcessFileName,
    InitiatingProcessFolderPath,
    InitiatingProcessCommandLine,
    RemoteUrl,
    RemoteIP,
    RemotePort
| summarize
    ConnectionCount = count(),
    FirstSeen = min(TimeGenerated),
    LastSeen = max(TimeGenerated),
    URLs = make_set(RemoteUrl)
    by DeviceName, InitiatingProcessFileName, InitiatingProcessFolderPath
| where ConnectionCount > 1
| order by ConnectionCount desc

The ConnectionCount > 1 filter reduces noise from one-off connections. Repeated polling to Ethereum RPC from an unexpected process is the pattern you’re looking for.

Hunting for SectopRAT Specifically

Beyond generic blockchain C2 detection, SectopRAT leaves specific artifacts. The FakeAgent campaign indicators from Huntress include file hashes for ClaudeDesktop.exe variants and associated DLLs, but if you’re hunting without known hashes, focus on:

  • Processes spawning from %TEMP% or %APPDATA% directories with names mimicking common applications
  • Child processes of browser or application installer processes that don’t correspond to expected installation paths
  • VMProtect-packed binaries, identifiable by process memory region characteristics or file header analysis
  • GPU enumeration calls from unexpected processes (SectopRAT queries GPU availability via WMI as a sandbox check)
// Hunt for GPU enumeration from processes in temp directories
DeviceEvents
| where TimeGenerated > ago(7d)
| where ActionType == "ProcessCreated"
| where InitiatingProcessFolderPath has_any ("%temp%", "appdata\\roaming", "appdata\\local\\temp")
| where FileName in~ ("wbemtest.exe", "wmic.exe", "powershell.exe")
| where ProcessCommandLine contains "Win32_VideoController"
| project TimeGenerated, DeviceName, InitiatingProcessFileName,
          InitiatingProcessFolderPath, FileName, ProcessCommandLine

Compensating Controls

If you can’t achieve comprehensive network visibility, compensating controls help. Restricting HTTPS connections to Ethereum RPC endpoints via proxy policy for endpoints outside your development environment blocks the blockchain resolution step, which breaks C2 even if the malware itself isn’t caught. Infura, Alchemy, and the other major providers are the bottleneck — block them at the proxy and the malware has nowhere to resolve operator instructions from.

For environments that run SectopRAT indicators from the FakeAgent campaign specifically: if you find ClaudeDesktop.exe installation events from July 21-22, treat the endpoint as fully compromised and rotate credentials before investigating further. The initial blockchain C2 resolution is just the configuration step — interactive sessions and credential harvesting happen over conventional infrastructure once the RAT is established.

References