MASSIVE CAMPAIGN: NO OBFUSCATION, JUST A CLEAR ‘F-OFF, MY FRIEND’
Attackers discovered a new way to hijack online payments and accounts by running a loud, in-your-face Magecart operation that barely bothers to hide. In this campaign, overconfident hackers use profanity-laced field names, ship their scripts with no obfuscation at all, and still manage to quietly steal card data and account credentials from checkout and registration flows worldwide.
A 52-script toolkit spans multiple languages and regions, targeting popular ecommerce platforms like OpenCart and WooCommerce and major payment service providers such as Stripe and Mollie, while abusing both visible payment forms and background data capture.
The result is a highly sophisticated client-side operation that looks “normal enough” to users and traditional defenses but silently captures payment details, personal information, and credentials in the browser before they ever reach the safety of your server or a secure payment provider’s environment.
For merchants who believe redirecting to a payment provider keeps them safe, this campaign shows how attackers can build fake “safe zones” on your own pages and turn that assumption against you.
Attack details
Under the hood, this is a single, unified operation built around a shared loader that pulls in one of 52 attack modules depending on the victim’s country, language, ecommerce platform, and payment provider, with scripts observed in Russian, French, Dutch, German, Bulgarian, Romanian, Portuguese, Vietnamese, Icelandic and English.
The attackers do not rely on obfuscation; their JavaScript is largely readable, which, paired with internal jokes and explicit profanity aimed at researchers—including a hidden input field literally named “f*off_my_friend”—underscores their confidence and makes the brazenness of the operation stand out even more.
Each module abuses first-party checkout or registration flows by inserting malicious logic that still executes in the user’s browser but behaves differently depending on how the site handles payments.
One of the most aggressive techniques, driven by the third-party pizza.js, is a payment flow hijack that programmatically injects an entirely new “Credit Card” (or “Kreditkarte”) payment option into sites that normally rely only on off-site redirects like standard PayPal.
Selecting this fake option prevents the user from being redirected to the legitimate processor; when the shopper clicks “Confirm,” the script interrupts the real transaction and launches a high-fidelity fake payment iframe that mimics a secure SSL gateway while it harvests raw card data directly in the browser.
In other words, pizza.js turns what should be a quick review-and-redirect step into an attacker-controlled card-capture page on the merchant’s own domain, stealing sensitive details before the customer ever reaches the genuine payment gateway.
Pizza.js is the loudest example of one of three behaviors we observed across the toolkit:
1. “Fake Form Replacement” swaps out an embedded payment form on the page with attacker-controlled inputs, as can be seen in the image below.
2. “Fake Iframe Overlays” replace a payment provider’s hosted page or iframe with a convincing phishing overlay that looks like Stripe, Mollie, or other gateways. This is the method used in the pizza.js script.
A range of customized fake Iframe overlays matching the language and look and feel of the targeted site are displayed below.
3. “Silent Skimming” scripts attach to legitimate fields and continuously harvest what the user types, using hidden inputs as staging buffers specifically in these covert modules so that card numbers, addresses, and login credentials can be captured without changing the visible page.
The toolkit attacks multiple ecommerce stacks, including OpenCart and WooCommerce, and works across several PSPs such as Stripe, Mollie, PagSeguro, MobilPay, OnePay, PlatiOnline, and PayPal Payflow, while exfiltrating data through different techniques, sometimes disguised as image loads and sometimes as background browser requests.
It is also evasive: when common test cards are used, the skimmer logic is designed not to send the data, so QA teams never see their own test numbers leaving the page even though real customers’ cards would be stolen.
Across at least 14 malicious “shadow CDN” and typosquatted domains, most of which are already blacklisted, every attack module loads from and sends data back to the same domain for that module, keeping traffic patterns consistent enough to blend into normal logs while powering what is effectively a global, multi-technique skimming-as-a-service platform.
How Source Defense protects you
This type of operation plays entirely in the browser, where traditional controls like WAFs, CSP, and server-side logging cannot reliably see or stop what thousands of lines of JavaScript actually do at runtime; Source Defense is specifically built to close that gap by monitoring and governing script behavior on the client side, in real time.
By placing a virtual security layer between third-party (and other unmanaged) scripts and sensitive user data, Source Defense can prevent these skimmers, fake forms, and fake iframes from ever accessing payment card fields, personal data, or credentials on protected pages, regardless of which language the script is written in or which PSP it impersonates.
Behavior-based controls look for exactly the actions this campaign relies on, such as accessing PCI data in payment forms, touching credential fields during account creation, attempting to transfer data off-site, or using browser storage and cookies to stage stolen information, and can block those behaviors before any exfiltration occurs.
Because the domains used in this campaign were either already on industry blacklists or were marked as such by Source Defense, these scripts would be proactively blocked from loading and would never get the chance to execute their malicious behaviors.
For brands that rely on hosted PSP pages or iframes and assume they are out of scope, Source Defense extends protection to those parent and embedded pages as well, ensuring that attackers cannot simply inject a fake payment method or overlay and harvest data by turning what looks like a ‘safe’ pre-payment page into a hidden data-entry point in the checkout flow.
How Source Defense alerts you
When a campaign like this runs on a site monitored by Source Defense, the platform can generate clear, actionable alerts so security and compliance teams can see which scripts are involved, what behaviors were observed, and on which pages they occurred.
Any time a script on a payment or registration page attempts to access PCI data, PII, or credential fields, execute risky actions such as aggressive timers or dynamic code evaluation, use browser storage or first-party cookies for staging data, or transfer information to an external endpoint, Source Defense can surface alerts mapped directly to those behaviors.
Because the domains in this operation are either already on industry blacklists, or were promptly added to the Source Defense repository, activity involving those hosts can also appear in widgets such as “Found in blacklists” and “Script behaviors,” giving teams additional context about where suspicious scripts are coming from and where they are trying to send data.
Alerts are visible in the bell notification center and in dashboard summaries so teams can quickly spot anomalous activity on payment and account-creation pages and investigate the scripts involved.
Alerts that can be triggered include:
- Loading data from blacklisted domains
- Sending data to blacklisted domains
- Accessing PCI and PII data
- Executing risky actions
- Accessing storage
Organizations can route alerts via email or webhook into SIEM, SOAR, or ticketing systems, ensuring that a global, multi-script campaign like this is surfaced alongside other high-priority security events instead of hiding behind normal web traffic.
Key takeaways
This campaign shows how overconfident hackers can run a massive, sophisticated web-skimming operation with no obfuscation, dozens of scripts, multiple languages, and a mix of skimmers, fake forms, fake iframes, and silent credential theft, all while bypassing traditional server-side tools and payment-provider redirects by attacking directly in the user’s browser.
Client-side security that inspects behavior at the point of data entry is essential to stop this kind of attack because it focuses on what scripts actually do – accessing card fields, touching login credentials, exfiltrating data to suspicious domains – rather than just where they are hosted or how they are written.
Source Defense offers a concrete way to control third-party and unmanaged JavaScript, support PCI DSS 4.0.1 requirements for script inventory and change detection, and reduce the risk of large-scale payment and account takeover incidents without constant manual review.
For security leaders, it is a reminder that redirecting to a PSP, relying on CSP/SRI, or watching server logs is not enough when attackers are comfortable leaving profanity in cleartext and still stealing data at global scale; only dedicated client-side controls can reliably see and stop what happens in the browser before sensitive information leaves the page.
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.