Scamwich campaign uses reverse proxies to steal restaurant delivery payments

Security researchers have identified a sophisticated payment-skimming campaign dubbed "Scamwich" that targets customers of major restaurant chains. Active between July and October 2026, the operation used fake domains promoted through Google Search ads to intercept credit card details during the checkout process. The attackers employed reverse proxy technology to mirror legitimate restaurant websites in real time, ensuring that menus and prices appeared authentic while silently redirecting payment data to their own servers.

What happened

The campaign relied on a network of at least 820 look-alike domains, many of which were registered shortly before being promoted via paid search advertisements. These ads mimicked official restaurant listings for brands such as Jersey Mike’s, directing users to fraudulent sites hosted behind Cloudflare. Because Cloudflare automatically issued valid TLS certificates from Google Trust Services, browsers displayed a secure connection indicator, lending false credibility to the scam sites. As of November 4, 2026, 367 of these domains were still active and serving content, even though the specific ad campaigns had been removed from Google’s platform.

Once a user landed on one of these clone sites, a reverse proxy server sat between the victim and the legitimate restaurant website. This proxy fetched every page, menu item, and price directly from the real site, ensuring that store hours and inventory were always up to date. The system rewritten URLs and headers on the fly, replacing the brand’s actual hostnames with the fake domain. This technique allowed core functionalities like address lookup, login, and cart management to work seamlessly because those requests were still routed to the legitimate backend APIs through the proxy.

The deception occurred exclusively at the payment stage. The attackers injected three specific scripts into every page to manipulate the checkout flow. A script blocker prevented legitimate third-party tools, such as cookie banners or app-redirect services, from loading. Another script, labeled _jmu(), used a MutationObserver to continuously replace the legitimate payment iframe with a fake one hosted on the scammer’s server. A third script, _chkT(), monitored the order total button every half second to ensure the fake payment form displayed the correct amount. When users entered their card details, the data was sent via a live socket.io connection to the operators, who then manually processed fraudulent transactions elsewhere.

Key details

• The campaign utilized at least 820 unique domains, with 367 still active as of November 4, 2026.
• Attackers ran at least 47 Google Search text ads under 46 different advertiser accounts using unrelated business names.
• The fraud kit used a reverse proxy to fetch live content from real sites, ensuring menus and prices were always accurate.
• Three injected scripts handled script blocking, payment frame replacement, and order total synchronization.
• Stolen card data was transmitted via socket.io to human operators who bypassed 3-D Secure checks in real time.
• Successful victims were redirected to legitimate competitor sites via href.li links after a valid=77777 cookie was set.

Background

A reverse proxy is a server that sits between client devices and backend servers, forwarding requests and returning responses. In legitimate use cases, reverse proxies improve performance, handle load balancing, and provide security. In this attack, however, the proxy was weaponized to create a perfect mirror of a target website. By fetching content dynamically from the real site, the attackers avoided the need to maintain static copies of menus or prices, which would quickly become outdated. This approach also allowed them to reuse the same codebase for multiple restaurant brands simply by changing the target URL and domain configuration.

The use of Content Delivery Networks (CDNs) like Cloudflare played a critical role in the scam’s credibility. CDNs often provide automatic TLS certificate management, which means the fraudulent domains displayed valid HTTPS connections. For most users, the presence of a padlock icon in the browser address bar is a primary signal of trust. By leveraging this infrastructure, the attackers ensured that technical indicators of security did not raise alarms, forcing users to rely on subtle visual cues or URL inspection to detect the fraud.

Why it matters

For teams that manage self-hosted software or internal web applications, this incident highlights the limitations of traditional security perimeter defenses. The attack did not exploit a vulnerability in the restaurant’s code or infrastructure; instead, it exploited the trust users place in search results and browser security indicators. Organizations that run customer-facing web services must recognize that their brand identity can be hijacked externally without any breach of their own servers. This means that monitoring external brand impersonation is just as critical as patching internal vulnerabilities.

The sophistication of the script injection mechanism demonstrates that automated bot detection and standard integrity checks may not be sufficient against determined adversaries. The attackers specifically targeted and disabled scripts that could have revealed the fraud, such as those redirecting mobile users to official apps. For IT leaders, this underscores the need for deeper visibility into how third-party scripts behave and how external entities might manipulate the Document Object Model (DOM) of their public-facing sites. It also raises questions about the reliance on automated certificate issuance without additional domain validation steps for high-risk transactions.

What you can do

• Monitor search engine ad archives regularly to detect unauthorized use of your brand name or look-alike domains.
• Implement strict Content Security Policy (CSP) headers to restrict which scripts can load and where data can be sent.
• Use subresource integrity (SRI) hashes for critical JavaScript files to prevent tampering or replacement by proxies.
• Educate customers to verify the exact domain name in the browser address bar before entering payment information.
• Set up alerts for newly registered domains that contain variations of your brand name or common misspellings.
• Consider implementing mutual TLS authentication or other strong client verification methods for sensitive API endpoints.