One High-Profile European Culinary Brand, Two Different PayPlug Skimming Incidents

A prominent European pastry chef and e-commerce merchant surfaced in two separate payment-skimming incidents, creating an unusual overlap between a broad Magecart campaign and a direct compromise of the merchant’s own site. In the first incident, attackers repeatedly used the identity of the same well-known European culinary brand with a personality-led e-commerce business inside counterfeit PayPlug payment forms displayed across more than 50 compromised websites in the EU. Most of those victims were not PayPlug customers at all, reinforcing that the attackers were impersonating a trusted payment brand rather than abusing a legitimate PayPlug integration. Separately, that merchant’s actual e-commerce site was compromised and served a different fake PayPlug checkout. The result looks, at first glance, like the same high-profile merchant was targeted twice. But the technical evidence supports a more cautious assessment: the incidents used different delivery mechanisms, different infrastructure, and different counterfeit forms. The strongest confirmed link is the repeated merchant identity, not a shared attacker.

Attack details

In the broader campaign, malicious code running on compromised merchant pages created an RTCPeerConnection and opened a WebRTC DataChannel whose label incorporated the current page URL. Rather than retrieving the next stage through a normal script request, the loader received JavaScript through that DataChannel, collected the transmitted bytes until an end marker or channel closure, decompressed gzip content when necessary, and executed the resulting code dynamically.

The counterfeit PayPlug forms made the campaign especially distinctive. Across more than 50 affected websites in the EU, most observed forms displayed the identity of the same prominent European pastry chef and e-commerce merchant, even though those sites had no obvious relationship to that business. Most were not PayPlug customers either, making the payment-provider branding itself part of the deception rather than a reflection of the victims’ actual payment infrastructure. Several forms also reused the same transaction number and often omitted the real purchase amount. That pattern suggests the attackers were reusing a largely static payment-overlay template rather than generating the merchant details from a legitimate payment session.

The same identity then surfaced again in a separate incident, this time on the actual website of the well-known European culinary brand. That creates several plausible explanations. Material may have been copied from the merchant’s checkout, both incidents may have reused a common skimmer kit or developer code, or one implementation may have borrowed from the other. Coincidence also remains possible. The current evidence does not establish which explanation is correct.

The WebRTC campaign itself used an unusually stealthy delivery path. The loader contained a fallback capable of creating a new script element and copying a nonce from an existing script on the page. That matters for Content Security Policy (CSP): CSP is a browser-enforced control, but a deployment that assumes an existing nonce cannot be reused by injected code may allow malicious code to inherit that trust.

Later variants also forced WebRTC traffic through attacker-selected TURN relays on port 443 while communicating with a logical remote peer on port 3479. Because the browser communicated through the TURN service, perimeter telemetry could show only the relay connection while obscuring the logical peer behind it. The second-stage skimmer then monitored dynamically inserted checkout elements with MutationObserver, wrapped XMLHttpRequest methods to inspect FormData, JSON-like content, and URL-encoded request bodies, and accessed local and session storage.

Analysis also found additional WebRTC activity consistent with splitting collected information into chunks and placing attacker-controlled data into TURN-related signaling or authentication material. This creates a potential exfiltration path that does not depend on conventional fetch, XHR, form submission, or image-beacon traffic.

The second incident followed a materially different chain and should remain analytically separate. A malicious loader embedded in a JavaScript asset on the merchant’s site decoded additional logic and attempted to retrieve JavaScript over WebSockets from attacker-controlled livesupp.online infrastructure. If WebSocket delivery failed, it fell back to HTTP POST requests sent to randomized paths.

On the compromised merchant’s checkout, the legitimate PayPlug card fields were hosted inside a cross-origin payment-provider iframe. That matters because those fields are isolated from JavaScript running on the merchant origin. The counterfeit form, by contrast, was inserted directly into the compromised merchant page and reproduced merchant-specific details, including the current amount, merchant branding, and a different transaction number. It was more tailored than the largely generic forms seen in the WebRTC campaign.

That distinction between origin ownership and visual appearance is critical. A fake payment form can look highly convincing, including the correct amount, branding, and familiar payment-provider imagery, while still exposing card data because the fields belong directly to the compromised merchant document rather than the legitimate payment-provider iframe.

The similarities justify comparison, but not attribution. The incidents share PayPlug impersonation, the same merchant identity, and similar payment-skimming objectives, yet they use different transport protocols, infrastructure, loader code, and fake-form behavior. No shared payload hash, backend protocol, encryption routine, infrastructure credential, or operator identifier currently proves a common actor or toolkit.

How Source Defense protects you

Source Defense extends security into the browser, where these attacks access and manipulate sensitive information. Browser-side runtime visibility and control can identify when code on a payment page accesses PCI data, reads browser storage, performs risky dynamic execution, or attempts unauthorized data transfers, regardless of whether the malicious functionality arrived through a conventional script request, WebSocket, or an unusual WebRTC channel.

That matters here because neither attack depended on an obvious redirect or a simple malicious script URL. CSP and Subresource Integrity (SRI) are browser-enforced controls, but they address different risks. CSP relies on correctly defined execution and trust policies, while SRI verifies the integrity of specific external resources. Neither is designed to analyze the runtime behavior of arbitrary code delivered dynamically, and the observed nonce-reuse fallback shows how an attacker may try to exploit weaknesses in CSP trust assumptions.

WAFs, firewalls, backend logs, and server-side monitoring operate outside the customer’s browser. They may therefore miss malicious behavior that occurs while a shopper is entering card data and before that information reaches the application server. Source Defense adds browser-side runtime visibility and behavior control at that point of interaction, helping organizations understand what scripts are doing with sensitive data during a live customer session.

How Source Defense alerts you

For this attack pattern, Source Defense can surface behaviors that align directly with the malicious activity observed in the browser, including:

• Sending data to blacklisted domain 
• Accessing PCI data
• Accessing data
• Transferring data using WebRTC
• Using browser storage
• Executing risky actions, including new Function and similar dynamic execution techniques

Relevant events can appear in the bell notification center and dashboard summaries, with behavioral detail available under Script behaviors. Security teams can use email and webhook notifications to route relevant alerts into existing monitoring and incident-response workflows.

Key takeaways

The same high-profile European culinary brand appeared across two distinct PayPlug skimming incidents, but the evidence does not establish a shared actor. The broader campaign stands out for using WebRTC and TURN to deliver malicious JavaScript and potentially move stolen payment data, while the separate compromise used WebSockets and HTTP.

Source Defense provides browser-side runtime visibility and control over data access, risky execution, and unauthorized transfers, closing the gap that allows eSkimming to operate inside the shopper’s browser.