{
	"id": "7aa949d1-0809-4aa7-a08a-3cceb4f95cfd",
	"created_at": "2026-04-06T00:12:39.506639Z",
	"updated_at": "2026-04-10T13:11:59.893587Z",
	"deleted_at": null,
	"sha1_hash": "a90ac4e3c02a1ea796f99068f59350546a1537eb",
	"title": "Global Magecart Campaign Puts Banks Under Pressure",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 113414,
	"plain_text": "Global Magecart Campaign Puts Banks Under Pressure\r\nBy raptur3\r\nArchived: 2026-04-05 19:50:17 UTC\r\nA large-scale magecart operation remained active for over 24 months, leveraging an infrastructure of 100+\r\ndomains. While the targeted victims are e-commerce websites, the actual pressure falls on banks and payment\r\nsystems.\r\nAs ANY.RUN’s analysis shows, threat actors applied multi-step checkout hijacking,\r\npayment page mimicry, and WebSocket-based exfiltration of card data. \r\nThis report provides both executive-level insights and technical analysis of the campaign. \r\nKey Takeaways \r\nThe campaign demonstrates long-term persistence (24+ months) supported by highly resilient\r\ninfrastructure. \r\nBanks (not merchants) bear the primary impact, as stolen card data leads to fraud losses and reputational\r\nrisk. \r\nPayment system mimicry (notably Redsys) significantly increases attack success by embedding fraud\r\ninto trusted user flows. \r\nUse of WebSocket exfiltration reduces visibility in traditional security monitoring tools. \r\nMulti-stage, dynamically delivered payloads allow attackers to adapt quickly and evade disruption. \r\nThe campaign is global but regionally tailored, leveraging localized payment ecosystems to enhance\r\ncredibility. \r\nCampaign Overview \r\nA large-scale magecart operation has been identified, active for at least 24 months and supported by over 100\r\ndomains. In observed cases, threat actors deployed a multi-stage checkout hijacking framework, incorporating: \r\nPayment step substitution  \r\nWebSocket-based exfiltration of payment card data \r\nPayment page mimicry, including infrastructure-level impersonation of legitimate providers (notably\r\nRedsys)\r\nDynamic frontend adaptation of payment interfaces matching different storefronts and scenarios\r\nhttps://any.run/cybersecurity-blog/banks-magecart-campaign/\r\nPage 1 of 23\n\nA total of 17 WooCommerce websites were infected between February 2024 and April 2025 and are likely\r\nlinked to this campaign, reflecting its longevity and operational stability. \r\nIndustrial and Regional Context Behind Global Impact \r\nThe geographic scope is of the campaign is global. Among the victims are organizations from at least 12\r\ncountries, including the United Kingdom and Denmark. However, there’s a notable concentration\r\nof such incidents in Spain, France, and United States. \r\nSome cases are confirmed directly via telemetry and network traffic, while others\r\nare identified via infrastructural correlation. \r\nFrom an industry perspective, mostly retail e-commerce companies were targeted, although in some cases, non-commercial organizations have been affected, too. \r\nHowever, the primary pressure here falls on banks, as cardholders faced financial exposure and their trust in\r\npayment systems suffered. \r\nWhy Redsys and Spanish Payment Context Stand Out \r\nDespite the global impact, the ties to Spain and its payment ecosystem in particular are obvious\r\nin this magecart campaign.  \r\nMimicry of RedSys, a payment system used in Spain, lies in the foundation of the attacks. The campaign\r\ninfrastructure features domains and visual artifacts designed to fit Spanish payment context. In some cases, user\r\npayment flows included legitimate Redsys domain sis.redsys.es for added credibility. \r\nThe approach made the malicious activity of the campaign convincing within Spanish payment context. \r\nWhat Makes This Campaign Durable \r\nPayment Mimicry  \r\nA significant portion of the infrastructure is registered via NICENIC INTERNATIONAL GROUP and disguised\r\nas legitimate web services, including analytics platforms, CDN resources, jQuery libraries, andpayment services.\r\nIf you access them directly, they’ll act as technical placeholders or will simulate legitimate redirects. This\r\ncomplicates attribution. \r\nMulti-Stage Delivery Architecture \r\nThe injected JavaScript contains only a minor loader that connects to external infrastructure, receives\r\nconfiguration data, and loads the next stage. The loader uses the fallback mechanism: it iterates through backup\r\ndomains until a valid response is received. This allows the campaign to go on even if some components of the\r\ninfrastructure get blocked. \r\nDynamic Payload Delivery \r\nhttps://any.run/cybersecurity-blog/banks-magecart-campaign/\r\nPage 2 of 23\n\nThe next stage isn’t openly stored inside an infected file. It’s delivered dynamically via a staging response. Thanks\r\nto this, the operators modify delivery domains, payload paths, and control infrastructurewithout infecting the\r\nwebsite again.  \r\nDifferent domains aren’t necessarily serve different campaigns. Instead, they have different roles:\r\nstaging responses, payload delivery, or for WebSocket/C2 and command handlers. \r\nOther Factors \r\nState persistence in localStorage \r\nMasquerading as legitimate external dependencies  \r\nWebSocket usage as a channel for control and exfiltration \r\nAs a result, the compromised website becomes only an initial access point. Subsequent payload delivery and data\r\nexfiltration can be flexibly modified inside the external infrastructure. \r\nTechnical analysis \r\nInitial Loader Delivery and Execution \r\nFollowing the compromise of a website, attackers modify one of the site’s embedded JavaScript files with a small,\r\nobfuscated loader. It doesn’t feature the main card-stealing logic but acts as an initialdelivery tool. It executes\r\nin the victim’s browser and receives parameters for the next stage from external infrastructure. \r\nInjected JavaScipt \r\nNext, the obfuscated part of the loader refers to one of the pre-determined domains from the fallback infrastructure\r\nlist. It returns a JSON configuration featuring the next stage’s address, WebSocket/C2 server address, and an extra\r\nHTTP handler for auxiliary communication. \r\nDomain examples \r\nThese values are delivered as encoded arrays of numeric character codes, which are then decrypted in the victim’s\r\nbrowser. \r\nhttps://any.run/cybersecurity-blog/banks-magecart-campaign/\r\nPage 3 of 23\n\nAn example of JSON configuration. ANY.RUN Interactive Sandbox \r\nIn case no response was received or the JSON was invalid, the loader automatically switches to the next domain\r\nfrom the list. This mechanism ensures continued operation even in the presence of partial infrastructure\r\ndisruption or blocking. \r\nStage 1: Malicious Payload Delivery and Execution \r\nAfter receiving a valid staging response, the loader takes the URL of the next JavaScript and dynamically adds it\r\nto the DOM via a new \u003cscript src=…\u003e element. \r\nCode fragment responsible for the execution of the malicious activity \r\nAt this point, the primary malicious payload is loaded into the page. Notably, this payload may be delivered from\r\ndifferent domains, such as: \r\njquerybootstrap[.]com \r\nnewassetspro[.]com \r\nassetsbundle[.]com \r\nhttps://any.run/cybersecurity-blog/banks-magecart-campaign/\r\nPage 4 of 23\n\nbundlefeedback[.]com \r\nand others. \r\nIn any case, the delivery stage is the same. The operators rotate payload sources to increase the infrastructure’s\r\ndurability. \r\nStage 2: Payment Step Activation \r\nAfter loading, the main payload begins executing within the context of the store’s webpage and waits for the\r\ncheckout/payment DOM to appear. \r\nAt this stage, it: \r\nmonitors the opening of the payment step; \r\ninteracts with checkout elements; \r\nreplaces or overlays the legitimate payment interface; \r\ninjects its own elements, including iframes and custom buttons; \r\nhides the real payment confirmation elements. \r\nOnce checkout is loaded, payment hijacking begins. \r\nObserved Code Patterns Indicative of Payment Hijacking \r\nhttps://any.run/cybersecurity-blog/banks-magecart-campaign/\r\nPage 5 of 23\n\nDelayed activation ensures the user follows through until they reach the required payment step \r\nhttps://any.run/cybersecurity-blog/banks-magecart-campaign/\r\nPage 6 of 23\n\nAttackers conceal the legitimate payment button and replace it with a fake one\r\nhttps://any.run/cybersecurity-blog/banks-magecart-campaign/\r\nPage 7 of 23\n\nThe script not only runs in the background but fully overlays/replaces the interface \r\nhttps://any.run/cybersecurity-blog/banks-magecart-campaign/\r\nPage 8 of 23\n\nThe form isn’t static but controlled and manageable \r\nIn some cases, the mimicry is built around a payment scenario that is visually and logically close to a legitimate\r\nPSP flow. In cases related to Spain Redsys mimicry is especially notable, but payment overall can adapt to\r\nstorefronts, countries, and local PSPs. \r\nScript Deobfuscation \r\nThe core payload waits for the checkout form to appear and is responsible for the reception,\r\nvalidation, and sending payment data from the fake payment form. \r\nNotable Code Features Inside the Script \r\nhttps://any.run/cybersecurity-blog/banks-magecart-campaign/\r\nPage 9 of 23\n\nThe payload adapts to user environments with frontend localization capabilities and supports multiple languages:\r\nEnglish, Spanish, Arabic, French.   \r\nThere’s a state machine with the following states: init, return, confirm, alert, getData, allowing for controlled\r\nprogression through the attack lifecycle. \r\nhttps://any.run/cybersecurity-blog/banks-magecart-campaign/\r\nPage 10 of 23\n\nCode for handling WebSocket connections to the C2 server for the control of the attack flow.  Part 1.\r\nhttps://any.run/cybersecurity-blog/banks-magecart-campaign/\r\nPage 11 of 23\n\nCode for handling WebSocket connections to the C2 server. Part 2\r\nAn example of the final result of the mimicry can be seen below:\r\nBase64-encoded HTML page is responsible for displaying a fake payment interface\r\nhttps://any.run/cybersecurity-blog/banks-magecart-campaign/\r\nPage 12 of 23\n\nPayPlug SAS payment window imitation\r\nThere’s a heavily obfuscated JavaScript inside the HTML page. It uses techniques like that to avoid detection: \r\nAnti-tampering: code integrity is verified via function serialization, as well as bitwise \u0026 arithmetical\r\noperations. \r\nCode fragment confirming anti-tampering \r\nVirtualization: Custom VM’s opcodes, symbolic execution, code strings executed via eval call. \r\nhttps://any.run/cybersecurity-blog/banks-magecart-campaign/\r\nPage 13 of 23\n\nA fragment of the raw load \r\nVM’s opcode description fragment  \r\nThe strings that are stored in an obfuscated form are decrypted using the VM: \r\nRaw obfuscated strings  \r\nhttps://any.run/cybersecurity-blog/banks-magecart-campaign/\r\nPage 14 of 23\n\nDeobfuscated strings  \r\nThe payload is responsible for the formatting and validation of Visa/Mastercard payment data that are entered into\r\nthe fake form, as well as UI state modification, and event or data delivery via postMessagemethod:\r\nhttps://any.run/cybersecurity-blog/banks-magecart-campaign/\r\nPage 15 of 23\n\nPostMessage method for data delivery \r\nStage 3: Connecting to Control Infrastructure \r\nAfter activation, the malicious payload establishes a connection to the control infrastructure, e.g., via WebSocket. \r\nhttps://any.run/cybersecurity-blog/banks-magecart-campaign/\r\nPage 16 of 23\n\nWebSocket exfiltration code \r\nThis channel is used for: \r\ntransmitting service events; \r\nsending BIN (Bank Identification Number) data; \r\ntransmitting full payment card details; \r\nreceiving additional commands to control the replaced payment flow. \r\nIn one of the analyzed cases, WebSocket was used as the primary channel for card data exfiltration, while the C2\r\nserver was disguised as a Redsys domain (redsysgate[.]com). \r\nDuring the skimmer’s operation, it retrieves malicious JavaScripts from URLs that look like so: \r\nhxxps://\u003cc2_domain\u003e/\u003cbase64_text\u003e.js?_=\u003cdigits\u003e \r\nThen, WebSocket connections are used for control and data transmission at: \r\nwss://\u003cc2_domain\u003e/?token=\u003cbase64_data\u003e \r\nhttps://any.run/cybersecurity-blog/banks-magecart-campaign/\r\nPage 17 of 23\n\nWhen the user enters their data, an event is sent containing the exfiltrated information. In response, the server\r\nprovides instructions on what to do next and what content to display, such as the logo of the payment system\r\nassociated with the entered card (Visa/MasterCard). \r\nCard data (random numbers used an example) in a code fragment  \r\nThis is important for the understanding of the campaign: attackers are not simply stealing card data, they embed\r\nexfiltration into a seemingly legitimate payment context. \r\nStage 4: Interception and Transmission of Payment Data \r\nWhen a user enters their card details into the spoofed payment interface, the payload takes them to the attackers’\r\nexternal infrastructure. \r\nThe following data was being transmitted in network traffic: \r\nBIN \r\nfull card number \r\nexpiration date \r\nCVV \r\nThe transmission does not occur via a standard form POST request, but instead through a separate WebSocket\r\nchannel, making detection via conventional HTTP logs more difficult. \r\nImportantly, within the same cluster, the visual scenario of the attack may vary. In some cases, Redsys-themed\r\nmimicry is observed; in others, PayPlug-like or generic card form scenarios are used. \r\nThis does not necessarily indicate different campaigns: within a single malware family, the same loader, staging\r\ninfrastructure, and exfiltration mechanism may be reused while applying different front-end disguises. \r\nAdditional Vector: Distribution of Android APK via the Same Inject \r\nIn addition to manipulating the payment step and stealing card data, the same malicious payload was also used as\r\na platform to push the installation of an Android application in APK format. \r\nThe script checked the user’s environment and, if certain conditions were met, displayed a separate mobile\r\nscenario offering the user to download an app. This included promises of discounts or bonuses, along with\r\ninstructions on how to enable installation from “Unknown Sources.” \r\nBased on the contents of the payloads, this scenario was localized into at least several languages, including\r\nEnglish, Spanish, Arabic, and French. This indicates that the campaign was targeting a broad international\r\nhttps://any.run/cybersecurity-blog/banks-magecart-campaign/\r\nPage 18 of 23\n\naudience and relied on a prepared, rather than ad hoc, infrastructure. \r\nCode fragment for Android-specific flow \r\nThis scenario had several localization options, including English, Spanish, Arabian, and French, indicating the\r\ncampaign’s global focus targeting particular, not random infrastructures. \r\nConclusion \r\nThis magecart campaign reflects a shift from opportunistic skimming toward structured, infrastructure-driven\r\npayment attacks. By combining checkout hijacking, high-fidelity payment mimicry, and real-time exfiltration,\r\nattackers embed malicious activity directly into legitimate transaction flows. This not only increases effectiveness\r\nbut also complicates detection and response. \r\nDeep visibility into active attacks and continuous threat monitoring are required for efficient detection and\r\nprevention of such breachers.\r\nAbout ANY.RUN \r\nhttps://any.run/cybersecurity-blog/banks-magecart-campaign/\r\nPage 19 of 23\n\nANY.RUN delivers interactive malware analysis and actionable threat intelligence, enabling security teams to\r\ninvestigate threats more efficiently, gain clearer visibility into attacker behavior, and respond with greater\r\nconfidence. \r\nWe focus on: \r\nMaintaining SOC 2 Type II certification and a strong commitment to safeguarding customer data \r\nContinuously enhancing our Interactive Sandbox, Threat Intelligence Lookup, and Threat\r\nIntelligence Feeds to support monitoring, triage, and incident response workflows \r\nEnabling SOC and MSSP teams to accelerate analysis, improve investigative context, and detect emerging\r\nthreats at early stages \r\nAnalysis and Investigation Data \r\nLink to TI Lookup query \r\nBrowse TI Lookup for related threats \r\nLinks to sandbox analyses \r\nCase 1: Confirmed checkout hijacking and WebSocket exfiltration of BIN, PAN, expiry date, and CVV. \r\nView analysis \r\nCase 2: The same loader cluster and staging infrastructure but without confirmed card exfiltration (possibly due\r\nto redirection to a legitimate external payment flow) \r\nView analysis \r\nCase 3: Confirmed use of the same loader cluster and staging infrastructure. \r\nView analysis \r\nIndicators of Compromise (IOCs)\r\nhttps://any.run/cybersecurity-blog/banks-magecart-campaign/\r\nPage 20 of 23\n\nPayload URL: hxxps[:]//\u003cc2_domain\u003e/\u003cbase64_text\u003e.js?_=\u003cdigits\u003e  \r\nC2 WebSocket URL: wss[:]//\u003cc2_domain\u003e/?token=\u003cbase64_data\u003e  \r\nbundle-feedback[.]com  \r\ndoubleclickcache[.]com  \r\nanalyticsgctm[.]com  \r\nhttps://any.run/cybersecurity-blog/banks-magecart-campaign/\r\nPage 21 of 23\n\nhotjarcdn[.]com  \r\nfirefoxcaptcha[.]com  \r\nsolutionjquery[.]com  \r\njquerybootstrap[.]com \r\nassetsbundle[.]com \r\nbundle-referrer[.]com \r\ncategorywishlist[.]com \r\ncachesecure[.]com  \r\nsecuredata-ns[.]com  \r\nanalysiscache[.]com  \r\nnewassetspro[.]com  \r\nexplorerpros[.]com  \r\nredsysgate[.]com \r\nANY.RUN malware analyst\r\nkhr0x\r\nI'm 21 years old and I work as a malware analyst for more than a year. I like finding out what kind of malware got\r\non my computer. In my spare time I do sports and play video games.\r\nrapture3\r\nraptur3\r\nNetwork Analyst at ANY.RUN | + posts\r\nNetwork Analyst at ANY.RUN. Keen to become a 'cybersec Swiss Army knife' man. Enjoys reading and writing\r\ndeep-dive tech research.\r\nI'm 21 years old and I work as a malware analyst for more than a year. I like finding out what kind of malware got\r\non my computer. In my spare time I do sports and play video games.\r\nraptur3\r\nraptur3\r\nNetwork Analyst\r\nhttps://any.run/cybersecurity-blog/banks-magecart-campaign/\r\nPage 22 of 23\n\nNetwork Analyst at ANY.RUN. Keen to become a 'cybersec Swiss Army knife' man. Enjoys reading and writing\r\ndeep-dive tech research.\r\nSource: https://any.run/cybersecurity-blog/banks-magecart-campaign/\r\nhttps://any.run/cybersecurity-blog/banks-magecart-campaign/\r\nPage 23 of 23",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://any.run/cybersecurity-blog/banks-magecart-campaign/"
	],
	"report_names": [
		"banks-magecart-campaign"
	],
	"threat_actors": [
		{
			"id": "5a0483f5-09b3-4673-bb5a-56d41eaf91ed",
			"created_at": "2023-01-06T13:46:38.814104Z",
			"updated_at": "2026-04-10T02:00:03.110104Z",
			"deleted_at": null,
			"main_name": "MageCart",
			"aliases": [],
			"source_name": "MISPGALAXY:MageCart",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775434359,
	"ts_updated_at": 1775826719,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/a90ac4e3c02a1ea796f99068f59350546a1537eb.pdf",
		"text": "https://archive.orkl.eu/a90ac4e3c02a1ea796f99068f59350546a1537eb.txt",
		"img": "https://archive.orkl.eu/a90ac4e3c02a1ea796f99068f59350546a1537eb.jpg"
	}
}