A large-scale magecart operation remained active for over 24 months, leveraging an infrastructure of 100+ domains. While the targeted victims are e-commerce websites, the actual pressure falls on banks and payment systems.
As ANY.RUN’s analysis shows, threat actors applied multi-step checkout hijacking, payment page mimicry, and WebSocket-based exfiltration of card data.
This report provides both executive-level insights and technical analysis of the campaign.
Key Takeaways
- The campaign demonstrates long-term persistence (24+ months) supported by highly resilient infrastructure.
- Banks (not merchants) bear the primary impact, as stolen card data leads to fraud losses and reputational risk.
- Payment system mimicry (notably Redsys) significantly increases attack success by embedding fraud into trusted user flows.
- Use of WebSocket exfiltration reduces visibility in traditional security monitoring tools.
- Multi-stage, dynamically delivered payloads allow attackers to adapt quickly and evade disruption.
- The campaign is global but regionally tailored, leveraging localized payment ecosystems to enhance credibility.
Campaign Overview
A large-scale magecart operation has been identified, active for at least 24 months and supported by over 100 domains. In observed cases, threat actors deployed a multi-stage checkout hijacking framework, incorporating:
- Payment step substitution
- WebSocket-based exfiltration of payment card data
- Payment page mimicry, including infrastructure-level impersonation of legitimate providers (notably Redsys)
- Dynamic frontend adaptation of payment interfaces matching different storefronts and scenarios
A total of 17 WooCommerce websites were infected between February 2024 and April 2025 and are likely linked to this campaign, reflecting its longevity and operational stability.
Industrial and Regional Context Behind Global Impact
The geographic scope is of the campaign is global. Among the victims are organizations from at least 12 countries, including the United Kingdom and Denmark. However, there’s a notable concentration of such incidents in Spain, France, and United States.
Some cases are confirmed directly via telemetry and network traffic, while others are identified via infrastructural correlation.
From an industry perspective, mostly retail e-commerce companies were targeted, although in some cases, non-commercial organizations have been affected, too.
However, the primary pressure here falls on banks, as cardholders faced financial exposure and their trust in payment systems suffered.
Why Redsys and Spanish Payment Context Stand Out
Despite the global impact, the ties to Spain and its payment ecosystem in particular are obvious in this magecart campaign.
Mimicry of RedSys, a payment system used in Spain, lies in the foundation of the attacks. The campaign infrastructure features domains and visual artifacts designed to fit Spanish payment context. In some cases, user payment flows included legitimate Redsys domain sis.redsys.es for added credibility.
The approach made the malicious activity of the campaign convincing within Spanish payment context.
What Makes This Campaign Durable
Payment Mimicry
A significant portion of the infrastructure is registered via NICENIC INTERNATIONAL GROUP and disguised as legitimate web services, including analytics platforms, CDN resources, jQuery libraries, andpayment services. If you access them directly, they’ll act as technical placeholders or will simulate legitimate redirects. This complicates attribution.
Multi-Stage Delivery Architecture
The injected JavaScript contains only a minor loader that connects to external infrastructure, receives configuration data, and loads the next stage. The loader uses the fallback mechanism: it iterates through backup domains until a valid response is received. This allows the campaign to go on even if some components of the infrastructure get blocked.
Dynamic Payload Delivery
The next stage isn’t openly stored inside an infected file. It’s delivered dynamically via a staging response. Thanks to this, the operators modify delivery domains, payload paths, and control infrastructurewithout infecting the website again.
Different domains aren’t necessarily serve different campaigns. Instead, they have different roles: staging responses, payload delivery, or for WebSocket/C2 and command handlers.
Other Factors
- State persistence in localStorage
- Masquerading as legitimate external dependencies
- WebSocket usage as a channel for control and exfiltration
As a result, the compromised website becomes only an initial access point. Subsequent payload delivery and data exfiltration can be flexibly modified inside the external infrastructure.
Technical analysis
Initial Loader Delivery and Execution
Following the compromise of a website, attackers modify one of the site’s embedded JavaScript files with a small, obfuscated loader. It doesn’t feature the main card-stealing logic but acts as an initialdelivery tool. It executes in the victim’s browser and receives parameters for the next stage from external infrastructure.
Next, the obfuscated part of the loader refers to one of the pre-determined domains from the fallback infrastructure list. It returns a JSON configuration featuring the next stage’s address, WebSocket/C2 server address, and an extra HTTP handler for auxiliary communication.
These values are delivered as encoded arrays of numeric character codes, which are then decrypted in the victim’s browser.
In case no response was received or the JSON was invalid, the loader automatically switches to the next domain from the list. This mechanism ensures continued operation even in the presence of partial infrastructure disruption or blocking.
Stage 1: Malicious Payload Delivery and Execution
After receiving a valid staging response, the loader takes the URL of the next JavaScript and dynamically adds it to the DOM via a new