No One Was Watching: Simple Web Skimming Campaign That Actually Worked

This wasn’t a new kind of attack

A large-scale web skimming campaign emerged at the tail end of December 2025. It used dozens of malicious JavaScript skimmers across multiple e-commerce environments, and their job was to silently capture payment and credential data directly in users’ browsers. This isn’t remarkable as we’ve seen this kind of approach before. What makes this attack stand out is its lack of stealth and the fact that despite this, it still worked.

The attackers weren’t careless — they were confident

We don’t think the attackers were being lazy. They took plenty of care in crafting a campaign that used modular payloads tailored towards various major payment processors such as Mollie, One Pay, PagSeguro, PayPal, and Stripe, among others. They used fake overlays that adapted to the languages of users in different territories and tricked them into handing over their personal details.

They blended in just enough

They also set up a network of carefully crafted domains for control and distribution of these assets, including googlemanageranalytic.com, gtm-analyticsdn.com, and jquery-stupify.com. They chose these names to resemble genuine libraries and analytics services, so the malicious scripts (often disguised as images) were loaded and executed by sites with less vigilant security.

They didn’t bother hiding because they didn’t have to

Where they didn’t seem to care so much was in covering their tracks. Most attackers use obfuscation to disguise their malicious scripts. Reflectiz can reverse-engineer scripts to make their behavior human-readable again, but the point here is that the attackers thought nobody was looking, so they didn’t bother. In this case, they appear to be so confident that they didn’t see the need for obfuscation, and to add insult to injury, they even laced some of the comments with F-bombs.

And it still worked

As we mentioned earlier, the surprising thing is that despite its lack of stealth (and bad manners), this Magecart-style campaign still worked. By now, security teams should be well aware that traditional controls are often blind to what happens inside the browser and that they should be using dedicated tools to keep visitors’ PII and financial information safe. This campaign suggests that some site owners still don’t prioritize client-side defense, and the attackers know it.

The Objective

This attack used silent skimming techniques to steal user inputs while using measures to slow investigators. It wasn’t just looking for payment card details, though. It was also picking up user credentials, personally identifiable information, and email addresses to take over users’ accounts and maintain persistent access for broader-scale identity theft. 

What we know about the attack so far

Based on publicly available analysis, the campaign exhibits several consistent traits:

Client-side execution

The malicious logic runs entirely in the browser, interacting with DOM elements such as login and payment forms before data is submitted.

Multiple modular scripts

Researchers observed more than 50 distinct JavaScript payloads, suggesting an organized operation rather than a one-off compromise that likely isn’t over yet.

Supply chain or third-party entry points

As with many Magecart-style attacks, scripts were introduced via external resources, not by visibly defacing sites or altering backend code.

Minimal attempt at stealth

Unlike classic skimmers that rely on heavy obfuscation, this campaign used readable code, implying that the attackers were confident it would not be inspected or monitored.

Crucially, nothing in this attack required breaching the origin server directly. That distinction matters.

Why traditional defenses struggle with attacks like this

Many organizations still rely primarily on server-side and perimeter defenses to protect customer data, things like:

• Web Application Firewalls
• Secure coding practices
• Vulnerability scanning
• Vendor assessments

These controls are still essential, but they don’t observe JavaScript behavior at runtime inside end-users’ browsers. In this campaign:

• The malicious code executed after the page loaded successfully
• The exfiltration occurred before forms were submitted
• The damage happened without triggering server-side alerts

From the server’s point of view, everything looked normal.

The case for client-side visibility

This is the kind of threat that has been driving increased focus on client-side security and browser-level monitoring. It’s why regulatory frameworks like PCI DSS have evolved, and why version 4.0.1 now explicitly states the need to:

• Maintain an inventory of client-side scripts
• Monitor script behavior
• Detect unauthorized access to sensitive data fields

These requirements exist because browser-based attacks are no longer edge cases; they are a main vector for data theft.

Where Reflectiz fits in the defensive stack

Reflectiz is designed to address exactly this blind spot: what third-party and first-party scripts actually do once they run in the browser. In this kind of case, Reflectiz would’ve been ideally suited to detecting abnormal script behaviors:

Runtime behavioral analysis

Rather than relying on signatures or known indicators of compromise, Reflectiz analyzes:

• Which scripts access sensitive fields
• How they interact with the DOM
• Where data is transmitted 

It doesn’t matter whether attackers use obfuscated code or not, because Reflectiz monitors their behavior and flags anything suspicious.

Third-party script governance

Magecart-style campaigns frequently enter environments through compromised vendors, tag managers, and marketing or analytics scripts, and this one follows this pattern. In response, Reflectiz continuously inventories and monitors third-party scripts, flagging:

• Newly introduced resources
• Behavioral changes in existing scripts
• Unauthorized access to payment or identity fields

Early detection of “quiet” compromises

One of the most damaging aspects of web skimming is dwell time. These attacks can persist for weeks or months without anything looking wrong. But by observing browser-side behavior continuously, Reflectiz helps reduce that dwell time, surfacing issues that would otherwise remain invisible.

An important distinction: defense in depth

It’s worth underlining the fact that Reflectiz is not a replacement for secure development, WAFs, or vendor risk management, but this campaign demonstrates why those controls alone are not enough to protect private user information. 

The attackers did not need SQL injection or RCE. They didn’t need to use credential theft or compromise the web infrastructure. All they needed was a single execution path into the browser, and once there, traditional defenses had little visibility.

Client-side security is not about replacing existing controls. It’s about closing a gap that attackers are already exploiting at scale.

A warning sign, not an anomaly

The most concerning aspect of this campaign may be its tone. Running large-scale, readable skimming code suggests the attackers assumed, correctly, in many cases, that no one was watching the browser layer. As organizations adapt to PCI DSS 4.0.1 and growing supply chain threats, attacks like this show that visibility is now indispensable.

Why this campaign matters

This campaign isn’t remarkable because it’s especially clever. It’s remarkable because it worked, and because it exploited a security blind spot many organizations still haven’t fixed. Tools like Reflectiz exist to illuminate that blind spot, providing a practical defensive layer against a class of attacks that traditional security controls were never designed to see. Attackers will keep trying this approach until it no longer works for them, and with Reflectiz, organizations can already make that happen.

FAQs

What made the December 2025 web skimming campaign unusual?

Unlike typical Magecart attacks that use heavily obfuscated code to hide malicious behavior, this campaign used readable, unobfuscated JavaScript with minimal stealth measures. The attackers appeared confident that no one was monitoring client-side script behavior, so they didn’t bother disguising their code. Despite this lack of sophistication, the campaign successfully stole payment data, credentials, and PII across multiple e-commerce sites, demonstrating a critical gap in many organizations’ security monitoring.

How did the attackers bypass traditional security controls?

The attack executed entirely in the browser without breaching origin servers, so traditional defenses like WAFs, vulnerability scanners, and secure coding practices couldn’t detect it. The malicious scripts ran after pages loaded successfully and exfiltrated data before forms were submitted to servers. From the server’s perspective, everything appeared normal. The attackers entered through third-party scripts and compromised vendors rather than direct infrastructure compromise.

What specific techniques did the campaign use to steal data?

The attackers deployed over 50 modular JavaScript payloads tailored to major payment processors including Stripe, PayPal, Mollie, OnePay, and PagSeguro. They used fake overlays that adapted to different languages and territories, set up domains mimicking legitimate services (like googlemanageranalytic.com and gtm-analyticsdn.com), and disguised malicious scripts as images. The campaign targeted not just payment forms but also account creation and login pages to harvest credentials for account takeover.

Why does PCI DSS 4.0.1 now require client-side script monitoring?

PCI DSS 4.0.1 explicitly requires organizations to maintain inventories of client-side scripts, monitor script behavior, and detect unauthorized access to sensitive data fields because browser-based attacks have become a primary vector for payment data theft. Traditional server-side controls cannot observe JavaScript behavior at runtime in end-users’ browsers, creating a blind spot that attackers like those in this campaign actively exploit. The regulation acknowledges that client-side security is now essential, not optional.

How would Reflectiz have detected this specific campaign?

Reflectiz performs runtime behavioral analysis that monitors which scripts access sensitive fields, how they interact with the DOM, and where data is transmitted – regardless of whether code is obfuscated. It would have flagged: newly introduced malicious domains (googlemanageranalytic.com, etc.), unauthorized access to payment and credential fields, behavioral changes in third-party scripts, and data exfiltration to suspicious endpoints. Unlike signature-based detection, Reflectiz’s behavioral approach detects “quiet” compromises that persist for weeks or months without triggering traditional alerts.