SharkStealer Adopts EtherHiding Technique for C2 Communication Evasion
SharkStealer, an information stealer written in Golang, has been identified using the Binance Smart Chain (BSC) Testnet for covert command-and-control (C2) communications. This malware employs an "EtherHiding" technique, allowing it to retrieve encrypted…
SharkStealer, an information stealer written in Golang, has been identified using the Binance Smart Chain (BSC) Testnet for covert command-and-control (C2) communications. This malware employs an "EtherHiding" technique, allowing it to retrieve encrypted C2 details from smart contracts through Ethereum RPC calls, decrypt the payload in memory, and initiate contact, while blending with legitimate blockchain traffic.
Unlike traditional C2 channels that utilize dedicated domains or IP addresses, which can be blocked once identified, SharkStealer issues eth_call requests to BSC Testnet nodes, querying a smart contract as a resilient repository.
Upon each call, the contract returns a tuple containing a cryptographic initialization vector (IV) and an AES-CFB encrypted blob encoding the actual C2 endpoint. Because this data resides on a public blockchain, it is challenging to distinguish malicious retrievals from benign user activity.
This method highlights the increasing misuse of public ledger infrastructures. Blockchains provide censorship-resistant storage and global availability, transforming smart contracts into universally accessible dead-drops. Without monitoring eth_call patterns targeting malicious contract addresses, these calls are indistinguishable from legitimate decentralized application (dApp) interactions.
SharkStealer’s implementation of EtherHiding involves the following workflow:
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. Data Retrieval : The smart contract function returns a tuple: a 16-byte IV and the AES-CFB encrypted C2 payload. In-Memory Decryption : SharkStealer uses a hardcoded AES key combined with the retrieved IV to perform AES-CFB decryption, extracting plaintext containing the C2 domain or IP address. C2 Connection : Once decrypted, SharkStealer establishes network connections to the recovered endpoint, ready to exfiltrate data from the compromised host.
By using blockchain for critical communication data storage, operators reduce reliance on disposable web infrastructure. This technique complicates takedown operations: disrupting C2 requires intercepting blockchain transactions or invalidating smart contracts, which demands coordination with blockchain operators and node providers.
Because this data resides on a public blockchain, it is challenging to distinguish malicious retrievals from benign user activity.
Security teams should monitor the following indicators of compromise 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
Monitoring network logs for unusual eth_call requests, especially repeated calls to a single contract address, should trigger alerts. Host-based detection can use YARA rules to identify the hardcoded AES key or the corresponding decryption routine within the SharkStealer binary.
Based on reporting by GBHackers.