Stripe API Skimming Campaign: Additional Victims and Insights

with David Alves and Pedro Marrucho

Research Update 4/4/25 — Given some misrepresentations of the research described below, Jscrambler clarifies that it has not found any security issues with Stripe's API or infrastructure.

A recently discovered web skimming campaign has introduced a novel technique that leverages a legacy Stripe API to validate stolen payment details before exfiltrating them. This tactic ensures that only valid card data is sent to the attackers, making the operation more efficient and potentially harder to detect. Our research team investigated and found additional victims. Those results, along with some additional insights, are presented here.

How the Attack Works

This web skimming campaign, like many, uses different stages (i.e., multiple JavaScripts) to load skimming logic on the checkout page.

Stage 1: Malicious Loader Injection

The threat actors likely infected their victims by exploiting vulnerabilities and misconfigurations in WooCommerce, WordPress, and others to plant the initial malicious script. 

Similar to almost every web skimming campaign in the last couple of years, stage 1 is just a loader script made to look like Google Analytics. In this case, it is the GAO variant (GoogleAnalyticsObjects) that we’ve seen in previous campaigns.
 

Figure 1 - Sample stage 1 GAO variant

Stage 2: Decoding the Next Stage

The second-stage script is a one-liner that dynamically evals a simple base64-encoded code string that contains the URL for the final stage. It employs a very light form of obfuscation that can be removed effortlessly, but can be effective in preventing detection by hiding sensitive URLs from security controls that analyze scripts statically (e.g. WAFs).

Figure 2 - Sample stage 2

Stage 3: The Skimmer

The skimming script hides the legitimate Stripe iframe and overlays it with a malicious one designed to mimic its appearance. It also clones the “Place Order” button, hiding the real one.

After a user types payment details, the skimmer verifies the card's validity using Stripe’s API. 

If valid, the details are sent via a dynamically invoked form submission to a drop server controlled by the attackers. An error is then shown to the user, requesting a page reload, which clearly qualifies this as a double-entry skimmer. Some other variants of this attack were reportedly silent skimmers, but our research could not observe that across all variants investigated.  After the attack takes place, a _dt entry is inserted into local storage to prevent the skimming code from being triggered twice.

Uncovering Additional Victims

While the initial report did not disclose the number of compromised merchants, Jscrambler’s research team conducted an independent investigation and identified 49 merchants affected by this campaign, so far. This number is likely an underestimation, as new victims continue to be discovered.

Interestingly, the Stage 3 skimmer script appears to be dynamically generated and customized for each targeted site. Due to the structure and similarities across the different stage 3 scripts that we’ve seen, it appears that these skimmers are being generated using some skimming generation tool. Attackers are leveraging the Referrer header to determine which specific skimmer version to deliver, reinforcing the highly tailored nature of this campaign.

The analysis revealed that all infected sites found used two domains to serve the attack's additional stages (2 and 3). However, we found 20 additional domains hosted on the same server / IP address for which we have not yet found live victims. These domains are similar / variations and that could also be actively in use by this campaign.

Jscrambler reached out to the compromised websites, and so far, 15 of them have either successfully removed the malicious scripts or the threat isn’t active anymore.

Brute-forcing additional victim websites

Stage 3 skimmer scripts were clearly tailored to the target website. Since the skimmer backend determines which script to return based on the referrer header, this mechanism can be abused. So, next, we brute-forced the identity of additional victims by fuzzing the Referrer header and inspecting the returned scripts. This technique worked quite well, although it’s unlikely to remain effective for long, as it’s relatively easy for attackers to defend against.

Interestingly, in one of these additional victim instances, we discovered that the skimmer was faking a Square payment iframe, demonstrating that these attacks target different types of merchants and PSPs.

Figure 3 - Iframed fake square payment form

Common Characteristics Among the Skimmer Variants

Our research uncovered several key traits shared across the various skimmer variants:

• Minimal obfuscation: Only Stage 2 employs a basic base64 encoding technique. Stage 3 does not use obfuscation at all, which was surprising.

• No encryption on exfiltrated data: Stolen payment details are transmitted in base64.

• Attack timeline: We identified evidence suggesting the campaign has been active since at least August 20, 2024, based on domain activity logs.

• Platform focus: Most compromised websites use WooCommerce, with additional cases involving just WordPress or PrestaShop.

• Infrastructure insights: Over 20 additional domains were found being served from the same IP, hinting at a broader operation.

Why Are Attackers Using Stripe’s API?

The quick answer could be that they only need to skim valid credit card information. Attackers could easily do that later using, for instance, carding bots or dark Web services. But if you think about it, there are a couple of benefits from doing it client-side:

• All websites were already using the API as part of their normal payment flow. Although we also observed instances where the threat actors were using hardcoded stripe API keys.

• Secondly, security tools and researchers often use invalid credit card details as part of their work, so not skimming in these cases means being less likely to be detected.

Could Stripe detect this?

These verifications are hard to detect as fraudulent, because nothing changes compared with the normal use of those APIs:

• These card validations are called when legitimate users are about to make a purchase, so checking the frequency of API requests should not reveal anomalies. In some variants, attackers were cautious enough to avoid making duplicate requests per purchase.

• Requests originate from a real user device using a legitimate IP address, so device checks and IP reputation will not reveal anything.

• Also, it is a real user navigating the browser, so Bot Detection doesn’t work either.

• However, some hope may rely on the fact that the skimming requests are using a deprecated version of Stripe’s API, contrary to the legitimate requests that are using the latest, and sometimes using an API key associated with the criminals.

Adding payment options to the victim websites!

Sometimes, we observed the skimming code adding other payment options, like paying using cryptocurrencies. 

In these cases, the skimmer dynamically injects an HTML DOM element that mimics a legitimate MetaMask wallet connection window, in the hope of tricking users. 

We added at the bottom the unique wallets addresses seen in all analyzed scripts.

We checked the activity of all wallet IDs that we found in use by the threat actor, but we couldn’t find a single one that had recent transactions. Most wallets had no transactions, and a few only had some in 2013 - so, in this case nothing relevant. But it is probably a matter of time until we see this tactic returning profits for the fraudsters.

How to Protect Against This Attack

To mitigate the risk of web skimming, merchants and PSPs should consider robust security solutions:

• Merchants can use real-time webpage monitoring
  Implementing solutions like Jscrambler Webpage Integrity can detect unauthorized script injections and enforce PCI DSS 4.0 requirements 6.4.3 and 11.6.1.

• TPSPs can help their merchants by adopting a hardened iframe implementation
  Jscrambler’s recently launched Iframe Integrity solution prevents unauthorized iframes and form modifications on a webpage. This solution protects merchants by blocking iframe hijacking and ensuring TPSPs (Third-Party Service Providers) can confirm that merchants' sites are not susceptible to script-based attacks.

Given that small merchants often lack the expertise or resources to fully implement PCI DSS 4.0’s stringent requirements, these automated solutions provide an essential layer of protection.

Conclusion

This sophisticated web skimming campaign highlights the evolving tactics attackers use to remain undetected. And as a bonus, they effectively filter out invalid credit card data, ensuring that only valid credentials are stolen. 

Jscrambler’s research team continues to track this campaign, and we urge all online merchants to prioritize security measures against client-side threats. If you suspect your site might be compromised, reach out to us for a security assessment.

Indicators of Compromise (IOCs): Malicious Domains

Indicators of Compromise (IOCs): Stripe API Keys

pk_live_51H2IxSIClY5DGt7iuSnSBYQMO6zR8DGYtwLd6oGeaCKovAezwxyHGkyrIUyybKvt46PXB8yGbrxeNVrjdL0Nup8S00l8suNOAa

pk_live_51HpgKZFLzaFQsfiXfWB9VE9tXDi8ecUppY46TiJJyB2bAsCcKp9H9e9NdsYXxM7ZmqIjQE0ApCWk61oiRVTnCNa500jmJDOga0

pk_live_51Kn968HWTqClCNSz38qX6cfIiIcUyzPwmBNGIT17xjYtx9fG6zH6ccohpaX0B8AeAt7vv2TQbxwiMNPKWWMYo4RZ00CYoBWe8S

pk_live_Ac5zctYSc2Pb0woVdIdXzydQ

pk_live_BE5dBdmbimjikuSQPSikoTAN

pk_live_E4VDojiYs4GBUMdyAZEw9oil

pk_live_LB9l97CQDVEGxyeLr7VS46EO00mIYbx7FL

pk_live_OLgzcciecW3V6Huzr4IZFBlF

pk_live_iBIpeqzKOOx2Y8PFCRBfyMU000Q7xVG4Sn

pk_live_kCjJzjlsjrVzxN7wVn84X8zC00LHDvjKmL

pk_live_n6g2DkfukoaRZDnfoRK1wLXm00SDyGwxtA

pk_live_qF9asPU7ruSHJBHUaBPFvszL

pk_live_zGG4CClrhqn0vXK91t5N5W9Y00krRYyz9j

Indicators of Compromise (IOCs): Wallets Addresses

BTC

33MLWAaupK5PUBxgDG6gjNH6Qf4VAtFCia

35XK6WbrL93ACUUwx5mBXZrP6QCg6jomr7

38xSCQFaoSt5qhFGRc5NyHFQQmgZBgtcA5

39kDs8XUEAzwrNrT9iQJqVZKafk96To1Po

3DTpBuuB1gEPm7EfwmWm1YKFfaFYnykAWt

3GHDteZ8LH6wYGrPzoBByEwbVcUbpKkeHU

3Hzi9EJkGEPq2M6Xk6kjthRJT99qM9t64F

3N58EQPyTVPj9fWcyBxEsFUEfnU72CxRho

3NMvSSB1Cju2tKBJVcE6JBMARaHUTsxv3W

3PFZG97VbmmJcuGz3GN1j7C5b2TR9o597S

ETH

0x1700714C02789a6C7AB2857BFaEb68D6B129b768

0x26d3fe121627bEe4a5080b3d603D041AE5664D2a

0x2b673A5BDa1f036749F66A09505DbB6dbafEf690

0x6a119c4F155667119b9aF705F8DeaCad2bffC200

0x893B0B82294432c003cFe4DBd80781039C75d082

0x8E6D26c16909D469A2d21AA0F1F37E360Bb705aa

0x952bc2A8C0Df54f6759623B14Cf421686C27ff70

0xB6F5Fd8f898DEA61CAFACdB9FF093F9C06E6C204

0xE3D24E5b326dfee08C652ee0030B303D22C44691

0xF555ad1446D9E54D4caA4cd64AC1aC54a70BBCf0

XMR

44iQSvdhaFHTSZkVwW4oxbdZjZBieEBjPJbjopgmfSozDBPpMipBeCoftyUhc8G7tdNd1H4Tfa4UqSH8wunh2B5zSmt9x5D

45WR5Fo5z66JhZd8GuRsu1Uci7tBnPCWBH2CDk9ya5Pjdb4gFRzW6z3aw83JQzdmpw3Ly7SqJW6ScedpiaLeQexfQgTEmEZ

473HYYUMBT3JJ4fBi4Q33UWqyELj77nxGKZb8FdrC7MBPvjDgERsqXUFhuBqjoRs9KUrLeXrxK4uJK5f1LAx1C5BG2Net6i

47RVsuruym44SaTZwdp5fRLcCuWcGd8pp3gmMQM61QGjCgoD5VewCwvPH3yGh2if21NPs2DaHP1wUCvLJkhNLgaKFxUHTLX

48XBaRawyzA9jY3hsbm5pGdVxkNV1zytJ1cozWePCvpS5v4ndc9Nf6J3dFihNgyxNH2qTWfVbZ75q5swnTBhZQ5xVNvSgC5

49X3qTsXHfza54tjwzYFFJJJyedAqxCohNTxUtUNHsEnJMsc9f6MG9CbWU96mevFm9iwQ1MuLzC2nfqCc8oV8nuJ4Arcrsz

49eDKoKnnAGXqKV6LdEZMAfkHbAqGq6mKc1PEAVUYFRuKEBeHnabbxKDfzJzDmQXUuNe1dG6vJuuXLTaTou325unNaL9TaF

49pSaeq6QZahprKHnQRkfC5zDZcYStoE2VMpkk3UBkMdRP5JSQsKdmiV7Qio9rcqXdW23mJkSty3FXGTS3rw5aVTSMbcgKA

4A6SWsBAK7XTcoYDFiJZQpLZtDfsjeTUgC6G6QWmzL82d3bcLB15KFVSSHvQgmDY4hX3JUH7uFn4cLwCjR7Msb4G2ccVSWr

4AA5nNfK81jFrD3zbQJYVsdvauFTFrTxu5rnoAu6yrKM5Ci9dYRKk5ahp7WnexPkPremq9ZgurYDtfZByXkVWFsbDWvDEby