Another Attack, Same Lesson: Redirecting Payment Doesn’t Protect You

ANOTHER ATTACK, SAME LESSON: REDIRECTING PAYMENT DOESN’T PROTECT YOU

Attackers found a clever way to steal payment data from PrestaShop stores by slipping a malicious third-party script into the browser and making it look like a trusted part of checkout. The script stayed quiet across most of the site, then activated only when shoppers reached payment, where it presented a convincing, bank-branded payment step designed to look legitimate. That let the attackers capture cardholder and personal data before the shopper was redirected to the real payment provider and completed the purchase normally. Because the skimmer hid behind a professional-looking decoy, triggered only on checkout pages, and abused the browser session before the transaction left the site, traditional server-side tools and point-in-time scans had little chance of seeing it.

Attack details
The campaign targeted PrestaShop merchants in France, Italy, and Spain and used malicious infrastructure disguised as ordinary JavaScript delivery services. On most pages, the script behaved like a decoy, serving a fake license-style header and no obvious malicious activity. Once it detected checkout-related page paths, it inspected the payment options presented on the page, identified regional payment modules and card flows, and then injected a pixel-perfect overlay that mimicked trusted banks or PSP experiences such as Payplug or Nexi. Victims entered their card and personal details into the fake form, which the script captured in real time and transmitted to attacker-controlled domains. After the theft, the script pushed the shopper back into the legitimate payment journey, often by showing an error or forcing a retry, which helped the attack remain invisible while the real purchase still went through.

How Source Defense protects you
If this attack were found on a customer’s site, Source Defense would stop it before the skimmer ever had a chance to operate. Because the malicious script is loaded from a blacklisted domain, it would be blocked outright and would never load in the browser. Beyond that, Source Defense provides continuous, real-time visibility into script behavior, helping organizations stop malicious third-party code before it can touch payment or personal data, inject fake payment experiences, or send information to attacker-controlled infrastructure. That means protection where it matters most: in the browser, at the exact moment sensitive data is entered.

How Source Defense alerts you
If the malicious script were allowed to run in the browser, Source Defense would surface the activity through clear behavioral alerts tied to what the script attempted on the page. This is especially important for organizations using Source Defense for detection and visibility, since they would still receive the indicators needed to investigate and respond quickly. Alerts appear in the bell notification center, dashboard summaries, the “Found in blacklists” widget, and the “Script behaviors” widget when relevant, and they can also be sent through email or webhook integrations based on configuration. The alerts for this attack would include:

• Accessing PCI data
• Accessing PII data
• Transferring data
• Loaded from a blacklisted domain
• Sending data to a blacklisted domain

Key takeaways
This campaign shows why relying on external payment providers alone is not enough to stop digital skimming. If a malicious script can run in the browser before the redirect or hosted payment step, it can still impersonate the payment experience, capture sensitive data, and hand the shopper off to the real provider without raising suspicion. That is exactly where client-side security matters most. Traditional controls such as WAFs, server-side logging, CSP, SRI, and one-time scanning are often blind to browser-side behavior that changes by page, user flow, or runtime conditions. Source Defense helps organizations take control of that risk with continuous monitoring and real-time protection for payment pages, while also supporting PCI DSS 4.0.1 requirements 6.4.3 and 11.6.1 through stronger visibility and control over script activity.