When Legitimate Websites Turn Against Their Users
Imagine completing a purchase on a well-known e-commerce site. The page loads normally, the connection is encrypted, and nothing appears out of place, yet your payment details are silently stolen in the background when you press the “Check Out” button.
This is the reality of modern payment-skimming attacks, and they are becoming significantly harder to detect. They hide silently within JavaScript code of legitimate websites, waiting until victims complete their purchases to steal payment information. The actors behind these operations take advantage of exploits against websites and hosting providers to plant their malicious code, and they add layers of obfuscation to hide their campaigns from defenders.
Over the past year, Trinity Cyber has observed a sharp increase in the “EtherHiding” technique to deliver payment skimmers. These campaigns deliver malicious JavaScript through blockchain-based infrastructure, which gives two main benefits to actors who run them: flexibility in rotating malicious payloads, and greater resistance to takedowns of their campaigns.
Why This Matters
Traditional web skimmers rely on attacker-controlled servers to host malicious scripts. Those servers can be detected, blocked, or taken down rapidly – leaving attackers with no choice but to re-design their campaigns and try again.
Blockchain changes the equation.
By EtherHiding malicious code inside smart contracts, attackers gain:
- High availability
- Easier payload rotation
- Infrastructure that’s difficult to remove
- Layered traffic that blends in and often can’t be inspected
- Evasion of traditional signature-based detection
For defenders, this means fewer obvious indicators and less time to react.
A New Kind of Skimmer: High-Level Overview
The campaign analyzed here unfolds in three stages, each designed to evade detection and frustrate researchers:
- A tiny JavaScript loader injected into a legitimate website
- A second-stage loader retrieved from the blockchain that performs environment checks
- A full Magecart-style payment skimmer delivered over WebSockets to steal payment data
Each layer is lightweight, obfuscated, and short-lived, making static detection unreliable.
Attack Chain Breakdown: How This Campaign Operates in Practice
What makes this campaign particularly effective is not a single technique, but the layered delivery model - designed to evade detection at every step. The attack unfolds in three distinct stages, each working together, which are highly effective when combined.
Stage 1: Smart Contract JavaScript Loader
The attack begins with a small, heavily obfuscated JavaScript loader injected into legitimate e-commerce websites. These injections typically occur through exploited web framework vulnerabilities or compromised credentials at hosting providers.
Figure 1. JavaScript Loader for Smart Contract
Rather than loading malicious code from an attacker-controlled domain, the loader contains a hard-coded Ethereum address. This address is used to retrieve a smart contract hosted on the Binance Smart Chain (BSC), which hides the next stage.
This design choice is critical: Blockchain infrastructure is trusted, highly available, and difficult to take down, allowing attackers to blend seamlessly into normal traffic.
The smart contract itself contains malicious JavaScript, which has been deliberately hidden through multiple layers of encoding (Base64 followed by hexadecimal encoding). Once retrieved, the loader decodes the payload in the browser and executes it dynamically.
The loader cycles through a set of hard-coded BSC API endpoints, sending JSON-RPC requests using the “eth_call” method to invoke a specific function inside the smart contract.
Figure 2. BSC Endpoints for JSON-RPC calls
Figure 3. POST request to BSC endpoint
Figure 4. 200 OK Response with hex-encoded JavaScript returned
At this stage, no traditional malicious domain is contacted — and nothing obvious is written to disk — making static detection and blocklists largely ineffective.
Stage 2: Anti-Analysis Loader and Command Channel Setup
The JavaScript retrieved from the blockchain acts as a second-stage loader. Its primary function is to determine whether it is executing inside a real user’s browser or inside a sandbox, debugger, or automated analysis environment.
Before proceeding, the loader performs a series of anti-analysis checks, including:
- Detection of debugging tools such as Firebug and Developer Tools
- Abnormal browser window sizes and screen resolution within sandboxes
If any of these checks fail, execution stops immediately.
If the environment appears legitimate, the loader initializes its configuration:
- A command-and-control (C2) WebSocket endpoint
- A unique victim identifier stored in local storage
- A heartbeat interval to maintain communication with attacker infrastructure
The loader then initiates a WebSocket upgrade request, which allows the attacker to stream the final payload into the browser dynamically. This is the Magecart-style payment skimmer.
Figure 5. Second stage loader.
Figure 6. WebSocket and config initialization for skimmer.
Figure 7. Anti-analysis checks.
Once the final skimmer is delivered, the loader removes itself from the DOM, leaving minimal forensic artifacts behind.
Stage 3: Magecart-style Payment Skimmer
The final stage is a fully featured payment skimmer, consisting of roughly 3,800 lines of heavily obfuscated JavaScript. The code is protected using multiple techniques designed to frustrate analysis, including:
- String encryption
- Variable name reuse
- Debugger detection
- Control Flow Flattening (CFF)
The skimmer establishes a persistent WebSocket connection to attacker-controlled infrastructure. Notably, it captures the referrer URL to determine whether the victim is interacting with high-value pages such as checkout or login forms.
Once active, the skimmer dynamically injects a fake Stripe payment form into the page and attaches event listeners to capture sensitive user input — a technique known as Formjacking.
Captured data includes:
- Credit card numbers
- Expiration dates
- CVV values
- Login credentials
This information is stored locally and then exfiltrated over WebSockets as Base64-encoded JSON. If transmission fails, the data is queued and retried automatically — ensuring data theft is reliable even under unstable network conditions.
Figure 9. Magecart-style skimmer WebSocket configuration
Figure 10. Skimmer code and targeted fields.
Figure 11. Fake credit card payment form to steal payment information.
Figure 12. Formjacking code for additional card skimming functionality.
By the time fraudulent activity is detected, the skimmer has often already completed its job.
Our technical brief provides a comprehensive analysis of this attack technique and details regarding how Trinity Cyber provides coverage across every stage of the attack chain.
Why This Attack Chain Is So Effective
Each stage of this campaign is deliberately engineered to:
- Leverage trusted infrastructure
- Minimize static indicators
- Avoid disk-based artifacts
- Operate entirely within the browser
- Evade signature-based and alert-driven tools
This is exactly the type of attack where post-compromise detection arrives too late.
How Trinity Cyber Stops It
Trinity Cyber’s Full Content Inspection (FCI) breaks this chain at every stage by inspecting live network sessions in real time. Regardless of obfuscation, blockchain delivery, or WebSocket streaming, malicious JavaScript is identified by behavior and removed inline before execution.
The result:
- No alerts
- No user disruption
- No stolen payment information
- No opportunity for attackers to establish presence
See It in Action
Want to see how Full Content Inspection defeats attacks like this before they reach your users?
