SharkStealer Adopts EtherHiding Technique for C2 Communication Evasion

SharkStealer, a Golang-based information stealer, has been observed leveraging the Binance Smart Chain (BSC) Testnet as a covert dead-drop mechanism for command-and-control (C2) communications.

By adopting an “EtherHiding” pattern, the malware retrieves encrypted C2 details from smart contracts through Ethereum RPC calls, decrypts the payload in memory, and initiates contact—all while blending in with legitimate blockchain traffic.

Traditional C2 channels rely on dedicated domains or IP addresses, which defenders can sinkhole or block once identified.

SharkStealer circumvents this by issuing eth_call requests to BSC Testnet nodes, querying a smart contract that acts as a resilient repository.

Upon each call, the contract returns a two-part tuple containing a cryptographic initialization vector (IV) and an AES-CFB encrypted blob that encodes the actual C2 endpoint.

Because the data resides on a public blockchain, analysts face greater difficulty distinguishing malicious retrievals from benign user activity.

This approach underscores the rising trend of abuse against public ledger infrastructures. Blockchains offer censorship-resistant storage and global availability, transforming smart contracts into universally accessible dead-drops.

Unless defenders monitor eth_call patterns specifically targeting malicious contract addresses, these calls appear indistinguishable from legitimate decentralized application (dApp) interactions.

Technical Deep Dive

SharkStealer’s implementation of EtherHiding follows a concise workflow:

1. RPC Interaction: The binary connects to a BSC Testnet HTTP RPC endpoint (e.g., https://data-seed-prebsc-1-s1.binance.org:8545) and invokes the eth_call method against a designated contract address.
   
2. Data Retrieval: The smart contract function returns a tuple: the first element is a 16-byte IV, and the second is the AES-CFB encrypted C2 payload.
   
3. In-Memory Decryption: Embedded within SharkStealer is a hardcoded AES key. The malware combines this key with the retrieved IV to perform AES-CFB decryption, extracting plaintext containing the C2 domain or IP address.
   
4. C2 Connection: Once decrypted, SharkStealer establishes network connections to the recovered endpoint, ready to exfiltrate data from the compromised host.

By offloading storage of critical communication data to the blockchain, the operators reduce reliance on disposable web infrastructure.

This technique complicates takedown operations: disrupting C2 requires intercepting blockchain transactions or invalidating smart contracts, both of which demand coordination with blockchain operators and node providers.

Indicators of Compromise

Security teams should hunt for the following IoCs when investigating potential SharkStealer infections:

Category	Indicator
BSC Testnet RPC Endpoint	https://data-seed-prebsc-1-s1.binance.org:8545
Smart Contract Address	0xE7E24F1A3D9C5B7E8A6D2F4C3B9A8E5F1D2C3B4
Embedded AES Key (hex)	0123456789ABCDEF0123456789ABCDEF
Decryption Method	AES-CFB using returned IV
Sample C2 Domain	attacker-c2.example.com
Sample C2 IP	198.51.100.23

When monitoring network logs, unusual patterns of eth_call requests—particularly repeated calls to a single contract address—should trigger alerts. Host-based detection can leverage YARA rules to identify the hardcoded AES key or the corresponding decryption routine within the SharkStealer binary.

Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.