A sophisticated and long-running Magecart campaign has been quietly operating for over 24 months, infecting e-commerce websites across at least 12 countries using more than 100 malicious domains to steal payment card data in real time and banks, not merchants, are bearing the heaviest financial blow.

Security researchers at ANY.RUN has uncovered a large-scale Magecart operation that has remained operational since at least early 2024, infecting 17 confirmed WooCommerce websites between February 2024 and April 2025.

The campaign’s infrastructure spans over 100 domains, reflecting a level of investment and planning more consistent with organized cybercrime than opportunistic skimming.

Victims have been identified across the United Kingdom, Denmark, France, Spain, and the United States, with a notable concentration in Spain tied directly to the campaign’s abuse of the Redsys payment ecosystem.

While e-commerce merchants are the initial access targets, the primary financial damage falls on banks and cardholders. Stolen card data fuels downstream fraud losses and erodes consumer trust in digital payment systems pressures that financial institutions absorb long after the skimmer is removed.

Protect your company with early visibility. To reduce dwell time, pressure, and losses. Integrate ANY.RUN in your SOC

How the Attack Unfolds

The operation employs a layered, multi-stage infection chain designed to frustrate detection and removal. After compromising a WooCommerce site, attackers inject a small obfuscated JavaScript loader into one of the site’s existing script files.

*Delayed activation ensures the user follows through until they reach the required payment step*

This loader contains no card-stealing logic on its own it silently reaches out to external infrastructure, retrieves a JSON configuration payload (encoded as numeric character arrays), and fetches the next malicious stage dynamically.

The loader also features a fallback mechanism: if one staging domain is unreachable or blocked, it automatically cycles through a list of backup domains until it receives a valid response.

*Attackers conceal the legitimate payment button and replace it with a fake one*

This design ensures the campaign continues operating even when individual components are taken down, a key reason the operation remained undetected for over two years.

The second-stage payload is delivered from domains crafted to resemble legitimate web services — including fake jQuery libraries, CDN resources, and analytics platforms such as jquerybootstrap[.]com, newassetspro[.]com, and assetsbundle[.]com.

Once loaded, the malicious script waits for the checkout page to appear, then hijacks the payment interface, entirely replacing or overlaying the legitimate payment form with a convincing fake.

The campaign’s most effective technique is its high-fidelity impersonation of trusted payment service providers. The most documented variant closely mimics Redsys, a widely used payment processor in Spain, incorporating the legitimate Redsys domain sis.redsys.es into the attack flow to add credibility.

*The script not only runs in the background but fully overlays/replaces the interface*

PayPlug SAS interfaces have also been replicated. The fake payment UI supports multiple languages English, Spanish, Arabic, and French — indicating a deliberate, globally oriented targeting strategy rather than an opportunistic one.

Once a victim enters their card details into the spoofed form, the payload transmits the data, including BIN, full card number, expiration date, and CVV — not via a standard HTTP POST request, but through an encrypted WebSocket channel. View analysis

The command-and-control server in one documented case was disguised as a Redsys domain (redsysgate[.]com). This exfiltration method is deliberately chosen: WebSocket traffic is often overlooked by conventional HTTP-based security monitoring tools, reducing the chance of real-time detection.

*The form isn’t static but controlled and manageable*

In a notable expansion of the attack surface, the same malicious payload also served as a delivery mechanism for Android APK files. When users accessed infected stores on mobile devices, the script displayed a prompt offering discounts or bonuses in exchange for downloading an app, complete with instructions to enable installation from “Unknown Sources.”

This mobile vector was localized in at least four languages, reinforcing that the campaign’s infrastructure was purpose-built, not improvised.

This campaign signals a maturation of Magecart-style attacks moving away from quick, opportunistic injections toward persistent, infrastructure-driven operations with real-time command-and-control.

For security teams, the key defensive priorities include monitoring outbound WebSocket connections from checkout pages, enforcing strict Content Security Policies (CSP), implementing JavaScript file integrity monitoring, and conducting regular third-party script audits.

For financial institutions, proactive threat intelligence sharing and enhanced fraud detection for card-not-present transactions remain critical countermeasures against this class of persistent, adaptive payment threat.

Free malware research with ANY.RUN. Start Now!

The post Magecart Hackers Uses 100+ Domains to Hijack eStores Checkouts and Steal Card Data appeared first on Cyber Security News.