For several years, the primary vector for capturing stolen credit card information—collectively known in underground financial marketplaces as “Fullz”—depended heavily on standalone phishing networks. Threat actors routinely deployed fraudulent loan portals, deceptive parcel-redelivery traps, lookalike banking interfaces, and rewards-claim lures designed to trick unsuspecting users into entering sensitive credit card credentials. However, recent human intelligence (HUMINT) engagements with prominent operators across major dark web carding networks (including Savastan0, Cvvhub, Jerrys, Zillion, Proton, VClub, Pepe, and elite invite-only forums) reveal an architectural paradigm shift in cybercriminal tradecraft.

The more technically advanced threat actors have largely migrated away from the operational friction of high-maintenance phishing infrastructure. Instead, they are directly compromising legitimate e-commerce ecosystems through server-side exploits, deploying persistent web shells, and injecting highly sophisticated client-side payment skimmers directly into the checkout pipeline. This analysis breaks down a newly discovered client-side skimmer artifact targeting the WooCommerce platform. By executing silently within authentic transaction sessions, this malware harvests financial metadata in real-time while allowing legitimate purchases to complete seamlessly, completely bypassing traditional perimeter detection models.

Profiling the Malicious Payload: An Architectural Overview of sender.js

The foundational component of this digital skimming operation centers around an obfuscated client-side JavaScript file identified as sender.js. Operating primarily as the “sender” or exfiltration mechanism, the script is engineered to selectively activate when a user navigates to an e-commerce checkout page running WooCommerce coupled with the WooCommerce Payments (Stripe Elements) framework.

Attribute	Technical Detail
File Role	Client-side skimmer and multi-layered data exfiltration (“sender”) engine
Language	Highly obfuscated JavaScript
Target Platform	WordPress ecosystems utilizing WooCommerce + WooCommerce Payments (Stripe Elements)
Obfuscation Blueprint	String-array rotation (similar to obfuscator.io) combined with custom Base64 encoding, URL escape routing, and character reversal arrays
Target Data Vectors	Primary Account Number (PAN), Expiration Date, CVV/CVC, and Customer Email
Anti-Analysis Vectors	Google Analytics telemetry subversion, marketing pixel impersonation, and client-side victim deduplication flags
Injection Mechanism	First-party Document Object Model (DOM) injection and look-alike overlay manipulation

Technical Deconstruction: Behavioral and Structural Mechanics

1. Multi-Stage Obfuscation and String Obfuscation Wrappers

Upon initial execution, the sender.js payload avoids direct heuristic detection by routing all critical strings through an obfuscated lookup pipeline. The code initializes with a substantial array of fragmented strings that undergoes programmatic rotation at runtime. A dedicated lookup function is subsequently employed to resolve numeric indices back into operational strings during execution. Consequently, human-readable element identifiers, specific Document Object Model (DOM) selectors, browser event names, error strings, and target server endpoints never appear as plaintext within the static script file. This effectively neutralizes naive string-matching detection systems and basic signature-based scanning tools.

Beyond standard array rotation, the malware integrates a custom decoding tier constructed from standard Base64 encoding, URL encoding/decoding sequences, and an iterative per-character string reversal routine. Embedded directly within the primary string matrix are two large, heavily encoded data blobs. When evaluated dynamically by the script, these blobs decode into the raw HTML structure and inline CSS variables required to construct a deceptive, look-alike checkout element. For security teams and website administrators, the presence of multi-tiered, non-standard decoding logic within a critical transactional file should instantly serve as a critical-severity indicator of compromise.

2. Context-Aware Platform Targeting

The execution logic within the skimmer is highly targeted, intentionally designed to minimize noise and preserve defensive stealth. Instead of randomly running across every page of the compromised WordPress site, the payload actively monitors the DOM structure specifically for indicators of WooCommerce Payments. The malware scans the DOM tree looking for specific architectural identifiers, such as the wcpay-payment-element node or the native StripeElement container. If these specific structural elements are absent, the script remains dormant, avoiding the transmission of unnecessary network beacons and preventing visual layout errors that could trigger administrative scrutiny.

3. The DOM Overlay Injection Technique

Because modern e-commerce architectures leverage cross-origin isolation—rendering the authentic Stripe iframe inaccessible to external client-side scripts due to Same-Origin Policy (SOP) boundaries—the threat actors bypass this sandbox constraint entirely by creating a parallel visual environment. The skimmer injects a first-party HTML overlay directly into the page layer, positioning its own input fields perfectly over or in line with the genuine payment fields.

Using the HTML layout decoded from its embedded blobs, the script renders a high-fidelity clone of Stripe’s payment form, matching its font faces, border radii, placeholder states, and responsive focus behaviors. These fake fields are identifiable under deep structural inspection by their unique naming convention: all malicious input element IDs are suffixed with a consistent string identifier, specifically _sb (e.g., numberInput_sb, expiryInput_sb, and codeInput_sb). Because these fields exist natively on the merchant’s top-level domain rather than inside a protected cross-origin iframe, the attacker’s JavaScript maintains unrestricted read access to every keystroke entered by the customer.

4. Interactive Real-Time Validation and Psychological Cloaking

To guarantee the accuracy of the harvested information and prevent operational disruption, the skimmer implements complex client-side validation processes that mirror a genuine banking gateway. The malware does not merely record raw text strings; it actively parses input values in real-time as the user types:

• BIN and Card Brand Classification: The script parses the leading digits of the PAN to classify the payment card provider (e.g., parsing Visa 4-series, Mastercard 5-series, American Express 34/37, Discover 6011/65, and modern 2-series ranges). It dynamically shifts field constraints based on this classification, adjusting the expected PAN character limits and alternating between 3-digit and 4-digit CVV demands accordingly.
• Luhn Mod-10 Checksum Evaluation: To filter out analytical noise and accidental typos, the payload subjects the input string to the mathematical mod-10 Luhn algorithm. If a user mistypes a digit, the script echoes localized validation errors (e.g., “card number is invalid”) that mimic real Stripe responses.
• Expiration Threshold Auditing: The script evaluates the monthly range bounds and tests the entry against the host machine’s current clock time to block expired or impossible transactional data.

By implementing this comprehensive client-side feedback loop, the victim experiences a highly polished, interactive, and completely un-suspicious checkout sequence, eliminating any psychological indicators that something is wrong.

5. Advanced Defense Evasion and Anti-Telemetry Protocols

The developers of this malware spent considerable energy ensuring the script remains hidden during casual browser forensic reviews:

• Storage Artifact Impersonation: The skimmer maintains state and records progress markers inside the browser’s localStorage engine. To ensure these entries blend into normal operations, they use keys designed to mimic third-party marketing and advertising tooling, specifically adopting prefixes like fbpixel_.
• Telemetry Suppression: The script explicitly sets a global Google Analytics opt-out configuration flag (ga-disable-G-3SDSS99J4N). This prevents the site’s legitimate analytics properties from collecting telemetry during compromised sessions, minimizing anomalous user tracking patterns or event drops that might catch the attention of digital marketing teams.
• Victim Deduplication Control: A persistent cryptographic marker is set inside the client’s local cache once a successful data transmission occurs. This guarantees that a returning user isn’t targeted repeatedly, drastically lowering outbound network traffic and preventing pattern-matching Data Loss Prevention (DLP) filters from triggering alerts.

6. Data Compilation and Exfiltration Pipeline

Once the real-time client-side validation loops are satisfied and the user attempts to submit their order, the script extracts the customer’s billing email from the core WooCommerce checkout block. It aggregates this identity information with the unmasked PAN, expiration month/year, and CVC code. The complete dataset is then passed through the reverse multi-layer encoding stack (Base64 conversion, URL character transformation, and string character reversing). The final obfuscated payload is packaged as a standard web beacon or URL query string and transmitted directly to an external, attacker-controlled collection endpoint, blending seamlessly into routine outbound web traffic.

Reconstructed End-to-End Attack Chain

[Initial Access] 
       │ (Vulnerable plugin/theme exploit, credential stuffing, or CMS vulnerability)
       ▼
[Web Shell Deployment] 
       │ (Persistent administrative control over server-side directory)
       ▼
[Backdoor Integration] 
       │ (Malicious inclusion within core themes, plugins, or database hooks)
       ▼
[Skimmer Delivery (sender.js)] 
       │ (Serves obfuscated payload; remains dormant until wcpay nodes are detected)
       ▼
[Credential Harvesting & Overlay] 
       │ (Injects look-alike DOM elements; conducts real-time Luhn/BIN verification)
       ▼
[Exfiltration & Sale] 
       └── (Encodes and beacons Fullz data to C2 endpoint -> monetized on carding marketplaces)

1. Initial Footprint Acquisition: Threat actors compromise the server-side architecture of the target WordPress site, often leveraging outdated plugins, unpatched theme vulnerabilities, or brute-forced administrative access credentials.
2. Web Shell Execution & Persistence: Attackers plant a server-side backdoor or web shell within the environment, establishing persistent file-system control.
3. Checkout Script Tampering: The threat actor modifies specific core templates, active theme headers, or database rows to force the inclusion of sender.js during the rendering phase of the checkout interface.
4. Target Verification: The client-side payload executes in the customer’s browser, searching for active payment nodes.
5. Parallel Harvesting: The fake DOM elements process payment credentials in parallel with legitimate order execution. The customer’s transaction still completes successfully through the real payment processor, leaving the business owner and buyer completely unaware of the breach.
6. Dark Web Monetization: The validated financial credentials are automatically exfiltrated and uploaded to underground carding forums for immediate financial exploitation.

Indicators of Compromise (IoCs)

Defenders should continuously audit their environments for the following behavioral, structural, and system-level signatures:

1. Rogue Injected DOM Elements

• Presence of input elements containing an _sb suffix within checkout source codes (e.g., #numberInput_sb, #expiryInput_sb, #codeInput_sb).
• Unexpected multi-layered or duplicated structural forms operating next to the standard #wcpay-payment-element or .StripeElement containers.

2. Forensic Browser Cache Fingerprints

• Unfamiliar localStorage strings utilizing fbpixel_ nomenclatures that lack corresponding tracking scripts in the platform configuration.
• Arbitrary victim-deduplication hash values residing within client-side browser caches.

3. Unauthorized Telemetry Disabling

• Detection of automated telemetry opt-out variables, specifically configurations executing ga-disable-G-3SDSS99J4N or related tracking blocks on checkout views.

4. Technical YARA Detection Signature

For automated server file scanning and memory forensics, deployment of the following heuristic ruleset is highly recommended:

rule ecommerce_skimmer_wcpay_sb_overlay
{
    meta:
        description = "Heuristic rule for WooCommerce/Stripe overlay payment skimmer (sender component)"
        author = "CloudSEK Threat Intelligence adapted for Enterprise Defense"
        severity = "Critical"
    
    strings:
        $field1 = "numberInput_sb" ascii wide
        $field2 = "expiryInput_sb" ascii wide
        $field3 = "codeInput_sb" ascii wide
        $target = "wcpay-payment-element" ascii wide
        $ga = /ga-disable-G-[A-Z0-9]{6,}/ ascii wide
        $rotator = /\(function\([a-z],[a-z]\)\{[^}]{0,40}while\(--[a-z]\)/ ascii wide
        $b64helpers = /\['(atob|btoa)'\]/ ascii wide

    condition:
        $target and any of ($field*) and 2 of ($ga, $rotator, $b64helpers)
}

Beyond Stripe: Architectural Adaptability Across Global Gateways

This threat is not isolated to WooCommerce Payments or Stripe. The initial vectors of the compromise—the server vulnerabilities and web shells—are completely gateway-agnostic. Once an actor achieves code execution on the checkout page, they simply adjust their frontend exploitation technique based on how the target merchant integrates their payment processor:

Architectural Capture Strategies by Gateway Integration Model

Gateway Platform	Integration Model	Authorized Data Isolation Zone	Primary Forensic Detection Cue
Stripe Elements / WCPay	Hosted iframe architecture	Isolated within js.stripe.com cross-origin frames	Rogue first-party inputs (suffixed with _sb) adjacent to the Stripe container; network telemetry resolving to non-Stripe nodes.
Braintree Hosted Fields	Sandboxed iframe elements	Native Braintree sandbox frames	Look-alike DOM overlays blocking the container wrapper; JavaScript hooks attempting to intercept the tokenize() callback function.
Adyen Web Components / Drop-in	Secured structural fields	Adyen isolated structural assets	Malicious input overlays; injection of custom listener hooks monitoring component state variations during onChange or onSubmit events.
Square Web Payments SDK	Tokenized field architecture	Secure Square rendering scopes	Rogue un-sandboxed forms; intercept scripts capturing intermediate tokenization payloads immediately prior to form submission.
Authorize.Net Accept.js	Client-side tokenized data capture	Native client application space	Scripts attempting to read opaque nonces or secure data arrays before form submission; unrecognized remote API connections.
PayPal Smart Buttons	Sandboxed UI elements / external redirection portals	PayPal-controlled workflows	Visual payment cards prompting users prior to redirection events; modified return URL values or altered checkout click handlers.

Our Opinion: The Future of E-Commerce Client-Side Security

The discovery of this WooCommerce payment skimmer highlights a critical reality in modern cyber security: traditional network-perimeter controls and server-side scanning are no longer enough to protect e-commerce ecosystems. For years, the security industry pointed to iframe isolation (such as Stripe Elements or Braintree Hosted Fields) as the ultimate fix for e-commerce risk. The assumption was that if the merchant server never handled raw card data, the data was safe. This threat actor’s shift to look-alike DOM overlays completely breaks that assumption.

By manipulating the surrounding Document Object Model (DOM), attackers exploit the psychological trust users place in a legitimate brand’s checkout URL. In our opinion, e-commerce security must evolve from focusing purely on data isolation to enforcing strict client-side integrity. Organizations must proactively implement strict Content Security Policies (CSP) to block unauthorized outbound network connections, enforce Subresource Integrity (SRI) to prevent runtime script tampering, and use real-time web page integrity monitoring. Until client-side security controls are treated with the same priority as server-side patches, highly evasive techniques like sender.js will continue to thrive by weaponizing the very trust merchants spend years building with their customers.