A Fake Payment Page That Reused CSP Trust and Exfiltrated via WebRTC
A fake payment page is dangerous enough when it tricks shoppers into entering card data, but this attack went further by borrowing trust from the real page itself. The skimmer reused a valid Content Security Policy (CSP) nonce, a browser-approved marker meant to allow trusted scripts, to load attacker-controlled JavaScript and make the malicious flow appear more legitimate to the browser. That script then cloned the expected payment experience and used WebRTC, a browser feature normally used for real-time communication, to transmit stolen payment and personal data. It continues a repeated theme from recent client-side attacks: the browser is now the payment interception point. What is new here is how the attacker combined CSP trust reuse, a realistic fake checkout, and a less commonly monitored exfiltration channel into one flow.
Attack details
The attack began with injected HTML rather than a traditional script tag. A hidden image with a broken source used an Angular-style ng-on-error handler to execute when the image failed to load. That handler accessed the page, found an existing CSP nonce, copied it to a newly created script element, and used the newly trusted script to load attacker-controlled JavaScript from npm.clickcdn01[.]net. This is the technical pivot that makes the attack different from more routine skimming: the attacker did not simply work around CSP; they turned part of the CSP trust model into the loader for the next stage.
The external script then initialized WebRTC-based communication to attacker infrastructure at 85.17.55[.]137 and injected a fake payment form that closely mimicked the expected payment.paco.2c2p.com credit card experience. The form collected card number, expiration date, CVV, cardholder name, and email address, then sent that data through the WebRTC channel. In execution terms, this was first-party page injection that triggered attacker-controlled third-party script activity, followed by browser-side collection of PCI and PII data.
How Source Defense protects you
For organizations that have seen repeated warnings about Magecart, the lesson here is not just “skimmers still exist.” The new lesson is that attackers are adapting to the defenses many teams already rely on. CSP and SRI each have value as browser-enforced integrity controls, and WAFs and server-side monitoring help protect the application environment. But this attack shows why those controls alone are not enough when malicious behavior is created dynamically inside the shopper’s browser. Source Defense extends protection to that client-side execution layer by monitoring and controlling what scripts do on payment pages, including access to sensitive data, risky execution patterns, and attempted data transfers to attacker infrastructure. In this scenario, Source Defense would focus on the behaviors that matter most: access to payment and personal data, dynamic execution through eval, and outbound transmission to a blacklisted destination. That behavior-based visibility helps detect and block unauthorized scripts before data exfiltration, while also supporting PCI DSS 4.0.1 requirements 6.4.3 and 11.6.1 for payment page script control and change detection.
How Source Defense alerts you
Because this attack chain loads attacker-controlled third-party JavaScript, Source Defense would surface alerts in both block and monitor modes. Relevant alerts would include:
- Sending data to a blacklisted domain
- Accessing PCI data
- Accessing PII data
- Executing risky actions, such as eval
These alerts appear in the bell notification center and dashboard summaries. Where relevant, the blacklisted destination would be visible in the “Found in blacklists” widget, while the data access and risky execution activity would appear in the “Script behaviors” widget. Alerts can also be sent by email and/or webhook, depending on configuration.
Key takeaways
This campaign reinforces a repeated theme from recent client-side attacks: the browser is now the attack surface, and payment theft often happens before data ever reaches the web server. The new development is the chain itself: CSP nonce reuse gave the attacker a trusted loading path, the cloned payment form captured the shopper’s data, and WebRTC provided an outbound channel that many traditional controls do not inspect closely. Source Defense gives teams the visibility and control needed at the point of input, helping protect payment pages, detect unauthorized behavior, and stop eSkimming before sensitive data leaves the browser.
PCI DSS 4.0 makes client-side security a priority.
Source Defense delivers a solution for 6.4.3 and 11.6.1 without adding a burden to your security teams.