Executive Summary
Date: September 2026
Source: Research by Hans Dekker
An active campaign behind account takeover and stolen credit cards.
A pattern we’re increasingly seeing in Chinese-language fraud channels is the use of fake e-commerce stores, advertised through Google Shopping, as a delivery mechanism for phishing payment credentials and card data.
This fraud works as follows:
- You search on Google Shopping for a brand you know.
- You click on the top result: an ad impersonating the brand.
- You browse the store and proceed to checkout
- The checkout page is a phishing page harvesting your credit card details or login details to a payment provider or BNPL.
Bfore detected an active campaign running this playbook on over 2,000 Shopify stores, with roughly 100 new ones appearing each week.
The phishing kits used have strong links to Outsider, the phishing-as-a-service operation Google sued in June 2026 and the FBI targeted in Operation Ghost Hook. Months after that operation, the kit is still being deployed on new e-commerce stores.
Why Defenders Should Care:
Victims authenticate the fraud in real time: A live operator relays the victim’s own OTP or in-app approval to complete the transaction, so even out-of-band app controls pass. Real Shopify confirmations are sent to further lower victim suspicion.
Full identities can be harvested: Card, PIN, Amex code, online-banking login, SSN, and date of birth can all be captured, enabling account takeover and new-account fraud.
The theft and the fraudulent charge happen in different places: The fake store processes nothing itself, so it can stay under the radar while the stolen data is cashed out on other merchants and issuers.
In this report, we show how these two phishing kits are delivered through Shopify storefronts, analyze the kits observed, and explain what we can learn about the attackers’ operations from an exposed admin panel.
The Shopify Mechanism
The stores in this campaign are actual Shopify storefronts, registered by attackers, most of them impersonating consumer brands.
Each store’s theme carries one malicious file, a custom asset named custom-checkout-redirect.js. When the shopper clicks checkout, that script intercepts the click and redirects them off Shopify’s infrastructure to an attacker-controlled page that looks like the brand’s real checkout.
The same asset also uses the fake store’s own Shopify Admin API token to create a real “paid” order and send the victim a genuine order-confirmation email, so the purchase looks legitimate and the victim will not realize they’ve been phished.
When a victim submits their card, the checkout reports it to Google Ads as a conversion, the same signal Google’s automated bidding can use to find more users like the one who just handed over a card.
Two Phishing Kits Used
Kit 1: The Outsider / JWR kit.
The first kit has strong similarities to the JWR framework Cisco Talos documented in toll and postal text scams. It runs in real-time: a human operator watches what the victim types over WebSocket and pushes back the next screen. The fake payment pages load from the attacker’s own server (a_index.html), not the store.
It can phish many payment methods, card, PayPal, Apple ID, Klarna, Afterpay, and Amex, plus follow-up verification screens (SMS, email, PIN, and bank-app approval). In the stores we examined, only card, Klarna, and Afterpay were active.
Kit 2: Playswing. A related but different kit.
The second kit redirects victims to a separate payment host (originally pay[.]playswing[.]net, now per-store pay.{store} subdomains). Where Kit 1 loads separate HTML pages and talks to the operator over an encrypted WebSocket, Playswing is a single bundled web app that uses a different messaging protocol (MQTT) and a separate backend with a different stack.
Despite the different architecture, it has naming similarities: its injected theme asset (the same custom-checkout-redirect.js) still carries the JwrIsShopify marker seen in the Outsider codebase.
In the stores we observed, card capture was active, while PayPal, Klarna, and Amex flows were present in the code but not seen live.
For the Playswing kit, the operators left their admin panel exposed, and it hints at the industrialized nature of these types of campaigns.
The Admin Panel
The panel is a single-page app, and its client-side code was served with no login required. Reading that code showed us how the panel is built: its screens, the data fields it is built around, and the API endpoints it calls. The following details from the panel caught our attention because they show the level of sophistication of this type of threat:
Separate operator roles and a store production line: Role-based access with distinct roles in the code, including ‘ads’ and ‘fisher’, among others, plus store lifecycle tracking with 8 different stages from unregistered to deleted.
Built as a multi-tenant SaaS: Account records include a sales rep, a plan tier, device-seat licenses, a subscription expiry date, and a service fee billed daily, monthly, quarterly, or yearly.
A view for captured cards: Screens and APIs for captured cards, with fields for the issuing bank and card tier, routing rules that assign cards to cashout channels, and a flag for whether a card cleared 3DS.
A Google Ads module: Integrations for two virtual-card platforms (cvvgo, vicard) and Google Ads account management, tracking which cards start getting declined so they can be rotated.
An identity module: Built to hold US identity records, with fields for SSN, name, address, LLC name, an EIN-registration action, and uploaded ID documents.
Anti-detect browser automation: The panel uses the BitBrowser API, a commercial anti-detect browser, and ties a separate browser profile, each with its own fingerprint and proxy, to ad accounts, stores, cashouts, and identities it manages.
Detection and IOCs
Every store in this campaign serves a file called custom-checkout-redirect.js from its Shopify theme. On a newly registered domain, that is a strong indication.
The filename alone is not enough. Matching only on the filename can produce false positives, so a reliable check should include the file’s contents.
IOC list:
- Theme asset: custom-checkout-redirect.js
- Content markers: JwrIsShopify, getSyncSettings, a redirect to a_index.html
- Playswing backend: webapi[.]playswing[.]net, mqtt[.]playswing[.]net, per-store pay.{store} subdomains
- JWR C2s: shopus[.]it[.]com, myshop-fly[.]it[.]com, us-shopnow[.]com, myshopusa[.]shop, shoppayying[.]com
- Operator infra: ipinfo[.]chenlun[.]workers[.]dev
- Phishing kits and domain list available on request to security and safety teams
JWR example: https://urlscan.io/result/01a01bce-bf70-75f9-860f-e03cd038c3bb/
Playswing example: https://urlscan.io/result/01a05af2-283f-75b8-a70e-5d23391662bb/
We disclosed this campaign to Shopify on September 1st but have received no reply. Many of the domains remain active at time of publishing.
PreCrime™ Predicts: A clear escalation event coinciding with heightened GTA 6 pre-release speculation and media coverage was noted. At this observed rate, the campaign is projected to surge significantly even after GTA 6’s confirmed release date, with peak velocity expected around any official release announcement. The campaign is ongoing and has not reached its ceiling. Any GTA 6 release date announcement, trailer, or major media event will trigger another registration spike.
