Web skimmers steal payment details inside the checkout page.

Web skimmers are scripts planted on compromised checkout pages to capture payment and billing details. The code reaches the browser through an injected script, a changed site bundle or a foreign script import, then reads the checkout or places its own form over it.

compromised store
  -> injected loader or script import
  -> real checkout fields or a fake payment form
  -> card and billing values captured in the browser
  -> fetch, XHR, WebSocket, beacon or image request

Two ways to capture a checkout

Some skimmers map the store's real fields and wait for the checkout button. VaultSkim watches the checkout-step-3-btn submit button, collects the form through FormData and sends encoded values to js-static[.]com/rbm through a beacon or POST. Others draw card-number, expiry and CVV inputs that look like the selected payment processor, collect the entries, then restore the real checkout so the order can continue.

The browser gives the collector several ordinary ways out. In the code we match, captured values leave through fetch, XMLHttpRequest, WebSocket, navigator.sendBeacon, an image query or the Telegram Bot API. Encoding ranges from Base64 to hostname-keyed XOR wrappers. Trace any of these requests when its destination is absent from the store's deployed checkout.

Loaders hide among site code

A script tag pointing to an unfamiliar host is the easy case. We also find loaders appended to existing JavaScript bundles, scripts locked to the infected hostname and code dressed as analytics. VaultSkim hides its checkout collector and sending routine in RC4-encrypted bytecode that an interpreter runs in the browser. Cache and optimisation bundles keep a copy of the injection after the original file changes.

HexMage imitates Google Tag Manager and reads its script host from an Ethereum Sepolia contract. The per-site chunk script derives an XOR key from the store's hostname, unwraps Base64/XOR layers and runs the skimmer through a JavaScript Blob. Its checkout scripts target WooCommerce, Stripe and FullCulqi payment forms. The WooCommerce overlay checks the card number, sends the captured values and puts the original checkout back.

RTCGnaw loaders read their controllers from BNB Smart Chain testnet and Polygon contracts and post the checkout path to them. The controllers answer by the shop's origin, so each infected shop gets a skimmer built for its own payment processor. After the theft it shows the shopper a card decline and puts the real form back for the second attempt.

SuperPixel is appended to scripts the shop already serves, usually WordPress's jQuery, and reads its collection host from an Ethereum mainnet contract. Its card-form builds copy the checkout, hide the original and draw their own card fields. The billing and card details leave as a XOR-scrambled GET query that carries its own key.

What we see across infected stores

Month	New sites
September	443
October	117
November so far	51

66% of the web-skimmer sites captured since 25 September run WordPress. Of the 324 sites recaptured at least 25 days after their first match, 283 still served web-skimmer code (87%).

Checking a store

Use a test checkout and inspect the page source, loaded scripts and network requests. Do not enter a real card number. Look for:

• script imports or inline blocks that were absent from your deployed checkout
• code appended to jQuery, theme, cache or payment-plugin bundles
• a second card form covering the payment processor's own fields
• JavaScript that reads card, expiry, CVV, name, email or address fields
• encoded values sent to an unfamiliar host by fetch, XHR, WebSocket, beacon or image request
• blockchain RPC calls from a store with no blockchain payment feature

Remove the injected loader and every cached copy. Compare the checkout, theme and plugin files with trusted releases, review administrator and hosting access, rotate those credentials, and clear server and CDN caches before testing again.