A GLOBAL SKIMMING CAMPAIGN, CUSTOMIZED SITE BY SITE

Attackers launched a global digital skimming campaign that hit dozens of e-commerce websites worldwide, turning legitimate checkout pages into convincing payment traps. The scale alone makes this campaign stand out, but its sophistication is just as notable: the operation used at least 22 distinct malicious script variants spread across 9 different domains, showing a well-organized infrastructure built to adapt and persist. 

Rather than relying on one generic skimmer, the attackers tailored fake payment experiences to individual victims, often blending into popular WooCommerce-based payment flows so the malicious checkout looked native to the site, the region, and the shopper’s expectations. That combination of global reach, trusted payment context, and highly customized execution made the campaign both harder to detect and more likely to succeed.

Attack details

This campaign operated like a skimmer factory. The attackers maintained a broad infrastructure with many script variants and exfiltration domains, then generated victim-specific packages through what appears to be a central builder workflow. 

Those packages were often delivered through harmless-looking JavaScript filenames and configured with selectors, language packs, payment-field formats, and collection routes that matched a specific merchant. 

On the page, the attacker used a hybrid model. Its preferred path was a silent skimming attack. A page observer watched for activity, scanned the DOM for common payment and identity fields, and captured values as users typed into legitimate forms in the background. 

If a silent skimming attack could not be triggered,a double-entry attack was used instead, where the script injected a fake credit card form directly into the checkout flow, complete with familiar card-brand graphics and payment-provider styling so the shopper would type data into an attacker-controlled interface first.

 The campaign was also engineered to hijack or replace popular WooCommerce-based PSP integrations, with configurations tailored to payment flows associated with PayPal Complete Payments for WooCommerce, Stripe for WooCommerce, Mercado Pago, and Kasikorn Bank. That allowed the fake form to blend into the site’s legitimate checkout structure rather than look bolted on. 

In some cases, the attackers exploited what could be called a support gap: even on websites that did not actually support online credit card payments, the script injected a convincing card form anyway. A shopper could enter payment details, have the data skimmed, and then see a fake error directing them to cash on delivery, or be allowed to complete the order as COD, delaying discovery until fraudulent charges appeared later. 

The exfiltration logic was equally resilient, using a prioritized set of delivery channels so theft could continue even if one route failed: standard fetch requests as the primary method, Beacon as fallback, image-based requests as a last-resort transport, and in some variants WebSockets to evade narrowly scoped browser policies. 

Some samples also used a proxy-style content security policy bypass by tunneling stolen data through a trusted endpoint on the merchant’s own domain before forwarding it to attacker infrastructure, making the traffic appear first-party. 

To reduce discovery, the malware included anti-analysis and anti-forensics features such as developer-tools detection through timing checks and debugger logic, the ability to disable observers or clear storage during inspection, and checks for administrative cookies, WordPress admin indicators, or Magento backend markers so the attack would stay hidden from site operators most likely to catch it.

How Source Defense protects you
Source Defense is designed for exactly this kind of browser-side attack because it secures the point where payment and personal data are entered, before that data ever reaches the web server. In this campaign, Source Defense would block the malicious script from executing because it is loaded from a blacklisted domain, preventing it from injecting fake checkout overlays, imitating trusted payment flows, or accessing sensitive payment fields in the browser. By stopping the skimmer before it can run, Source Defense helps organizations maintain control over payment-page code, detect unauthorized changes, and reduce the risk of client-side fraud. This approach also supports PCI DSS 4.0.1 requirements 6.4.3 and 11.6.1.

How Source Defense alerts you
Even when attackers try to hide behind trusted page elements, localized branding, or first-party relay traffic, Source Defense generates actionable alerts so teams can quickly understand what the script attempted to do and where the risk appeared. 

Alerts surface in the bell notification center, dashboard summaries, the “Found in blacklists” widget for known malicious infrastructure, and the “Script behaviors” widget when suspicious runtime activity is observed. 

Notifications can also be sent through email and webhooks into existing workflows based on configuration.

  • Sending data to a blacklisted domain
  • Loaded from a blacklisted domain
  • Accessing PCI data
  • Accessing PII data
  • Accessing data
  • Transferring data

Key takeaways
This campaign shows how far Magecart has evolved from generic card skimmers into highly customized, region-aware attacks that imitate trusted checkout experiences and adapt to the payment stack of each victim. That is why client-side security is essential: the theft happens in the browser, at the moment of input, where traditional tools such as WAFs, server-side logging, and static controls like CSP or SRI may have limited visibility or can be bypassed by first-party relays, dynamic content, and rapidly changing script variants. Organizations that rely on checkout pages, embedded PSPs, or third-party JavaScript need controls that can continuously monitor behavior, detect unauthorized changes, and stop exfiltration in real time. This is the difference between discovering fraud after cards are stolen and preventing the theft while the shopper is still on the page

PCI DSS 4.0 makes client-side security a priority.

Source Defense delivers a solution for 6.4.3 and 11.6.1 without adding a burden to your security teams.

Scroll
Source Defense
Privacy Overview

This website uses cookies so that we can provide you with the best user experience possible. Cookie information is stored in your browser and performs functions such as recognising you when you return to our website and helping our team to understand which sections of the website you find most interesting and useful.