The Payment Skimmer That Went Silent Around Store Insiders
A highly targeted payment skimmer deliberately shut itself down for the people most likely to uncover it. Before displaying its counterfeit card form, the malware compared the shopper’s billing email against 32 addresses associated with the store owner, internal departments, a related business, and an external developer. Anyone on that exclusion list received a normal checkout, while ordinary customers were exposed to payment card and personal data theft. This selective silence helped the attacker avoid detection during test purchases, maintenance checks, and payment investigations. The skimmer also replaced Stripe’s protected payment interface rather than attempting to read data from it, creating a convincing imitation that captured information before Stripe could tokenize it.
Attack details
This was a first-party script attack. The malicious JavaScript was delivered from the compromised merchant’s own domain through a fake WordPress plugin directory designed to resemble a legitimate installation. The heavily obfuscated file targeted WooCommerce stores using the official WooCommerce Stripe Gateway.
Stripe normally places its card fields inside a cross-origin iframe, which separates payment data from the merchant page. Because scripts in the merchant’s document cannot directly read values entered inside that iframe, the skimmer avoided the security boundary entirely. It repeatedly checked for Stripe’s payment element, hid the legitimate iframe when it appeared, and injected a same-origin counterfeit form into the same area.
The fake interface was built to withstand casual inspection. It included CSS copied from Stripe Elements, familiar placeholders, live card-brand detection, input masking, expiry and security-code validation, and a Luhn check for card numbers. Card-brand images were loaded from Stripe’s own trusted domain, helping the form look authentic while remaining compatible with a Content Security Policy that permitted Stripe resources. A MutationObserver also removed visual error indicators as soon as they appeared, preventing the fields from turning red or warning the shopper.
When the shopper clicked the legitimate Place Order button, a global click handler collected the card number, expiration date, CVV, cardholder name, address, phone number, and email. This included PCI data and PII. The script encoded the values, inserted a percent sign after every character to disguise the encoded content, and transferred it through the query string of an image request to an attacker-controlled domain designed to resemble WooCommerce telemetry.
The skimmer then set a long-lived first-party cookie, removed its overlay, and restored the genuine Stripe iframe. The shopper saw what appeared to be a temporary checkout problem, re-entered the card details, and completed the transaction normally. The card was stolen once, while the successful second attempt reduced the likelihood of a complaint or payment-provider investigation.
Its strongest evasion feature was the email exclusion list. The script remained inactive for internal role accounts, the merchant’s related business, a development contractor, and a test address. It also avoided administrators, recognized WordPress admin sessions, checked for developer tools, and stopped running after its first successful collection. The purpose was not to spare these users for their benefit. It was to prevent the people most likely to investigate the checkout from seeing any sign of compromise. The breadth of the list also suggests that the attacker had studied the merchant’s environment before deploying the payload, rather than installing a generic skimmer during a brief compromise.
How Source Defense protects you
Source Defense extends protection into the browser, where this skimmer manipulated the checkout experience and accessed sensitive data. Runtime behavior analysis can identify scripts that interact with PCI and PII fields, replace or modify payment-page elements, use first-party cookies for persistence, and transfer collected data to an external destination.
Behavior-based controls help secure the information entered into checkout forms even when malicious code is delivered from a plausible first-party path. This matters because the fake plugin name and same-origin delivery could make the file appear trusted during a superficial review. Source Defense evaluates what scripts do during each browsing session, providing visibility and control at the point where payment and personal data are entered.
Relevant behaviors can generate alerts for accessing PCI data, accessing PII data, transferring data, using first-party cookies, and, when threat intelligence identifies the destination, sending data to a blacklisted domain. These events are available through the bell notification center, dashboard summaries, “Script behaviors,” and “Found in blacklists” when applicable. Security teams can also configure email or webhook notifications to support timely investigation and response.
Key takeaways
This attack shows why predictable synthetic purchases are not enough to validate checkout security. A skimmer can recognize employee, agency, or testing identities and remain completely inactive for them. Monitoring transactions with unrelated, rotating identities can reduce that blind spot, but it does not replace continuous browser-side protection.
CSP and Subresource Integrity are browser-enforced controls, but they address different parts of the problem. CSP restricts where approved resources may load from, yet a trusted Stripe image can still be used inside a malicious counterfeit form. SRI verifies the integrity of eligible static resources, but it does not prevent an authorized or same-origin script from abusing page elements and sensitive inputs at runtime. WAFs, firewalls, backend logs, and server-side monitoring operate outside the shopper’s browser and may not observe a legitimate payment iframe being hidden before stolen data leaves through an image request.
The new twist is not simply that the skimmer looked like Stripe. It was programmed to disappear whenever the merchant, developers, or likely investigators entered the checkout flow. Browser-side runtime visibility and control help close that gap by revealing how scripts interact with payment fields, page elements, cookies, and outbound destinations during real customer sessions.
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.