When customers order food online, they expect a familiar experience: find their restaurant, choose their meal, and pay. Increasingly, criminals are exploiting that familiarity by creating convincing clones of restaurant ordering websites, right down to the original site's underlying code.

In early November 2026, InfoHawk researchers investigated a collection of suspicious websites that appear to be part of one or more coordinated restaurant impersonation and payment-skimming operations.

Across two research passes, we identified 820 domains impersonating 35 restaurant brands. Of those, 808 use the .delivery top-level domain, and the rest use .com or .shop.

The scale is concerning, but what makes these sites particularly dangerous is how convincing they can be.

These aren't ordinary fake websites

The investigation began with a suspicious domain: mlckessejersstey[.]delivery.

The site impersonated Jersey Mike's, the popular sandwich chain, and reproduced its online ordering experience.

Rather than simply displaying a crude imitation of the restaurant's website, the attackers used a more sophisticated approach: reverse-proxying the legitimate site while replacing the checkout payment form with a malicious one.

A reverse proxy can retrieve content from a legitimate website and present it to visitors under a different domain. This allows an attacker-controlled site to display genuine pages and assets while selectively modifying the parts of the experience that matter to the attacker.

In this case, the malicious checkout requested credit card information and also asked customers for the SMS verification code sent by their bank.

This is a particularly dangerous combination. Capturing a credit card number is valuable to criminals; obtaining a one-time verification code could also help them authorize fraudulent transactions, depending on how the victim's bank uses that code.

For consumers, the experience can appear nearly indistinguishable from ordering directly from the restaurant. The site looks familiar, the menu and ordering flow can behave normally, and the fraudulent payment form appears at the moment a customer expects to pay.

Importantly, this does not require the legitimate restaurant's website to have been hacked. The attackers can operate on infrastructure they control while using the authentic restaurant website as the source of the content they display.

How the attack works

Each clone is a reverse proxy: a server that sits between the victim and the real restaurant site, fetches every page from the real site as it is requested, edits it on the way through, and passes it on. Menus, prices, store hours, and the cart are live and correct, because they come from the real site. Only the payment step is replaced. Described from mlckessejersstey[.]delivery (Jersey Mike's); we believe the clones of the other brands run the same kit.

1. The victim arrives from a search ad

   A Google Search ad imitates the restaurant's listing and shows a look-alike domain. The domain is behind Cloudflare, so its real server is hidden, and Cloudflare gives it a valid certificate automatically (Google Trust Services here), so the browser shows "Connection is secure".

2. Every page is fetched live from the real site

   The proxy forwards each request to the restaurant's own servers, adjusting the host name and cookies, and relays the answer. The real site's headers come through (on Jersey Mike's, x-powered-by: Nuxt and Amazon CloudFront headers), which is how we could tell which paths came from the real site and which from the scammer's server.

3. Addresses are rewritten to keep the victim on the fake domain

   The proxy replaces the brand's own host names in pages, scripts, and redirects with the fake domain, and maps each backend to a path on it, such as /__bapi__/ or /__payments__/. Store lookup, menus, login, and cart all work, because those calls go back through the proxy to the real APIs. Even the brand's own bot-detection script still runs, with its endpoints rewritten.

4. Three scripts are injected into every page

   A script blocker patches HTMLScriptElement.prototype.src so that listed scripts never load (on Jersey Mike's, the OneTrust cookie banner and Branch, which could send phone users to the app or the real domain). _jmu() finds the real checkout payment frame and points it at /js/index.html on the fake domain; a MutationObserver puts the fake one back whenever the page restores the real one. _chkT() reads the order total from the "Place order" button every half second and saves it, so the fake form shows the right amount.

5. The card form is the scammer's

   A few paths are answered by the scammer's server instead of the real site: /js/* (the card form and its scripts) and /payment/socket.io. The form looks like part of checkout. On submit it collects every field (card number, expiry, CVV, name, phone) and sends it, with the site name, to the operator over a live socket.io connection.

6. An operator gets past the bank's check live

   We believe a person watching a control panel uses the card elsewhere and, when the bank challenges that payment, tells the victim's page what to show next: "card declined, try another", a page asking for the SMS code (/js/confirmation/), an "approve in your bank app" page (/js/app/), or "invalid code, try again". We believe the code the victim types is what lets the operator's charge through 3-D Secure.

7. The victim is sent away

   When the operator marks it a success, the page sets a cookie valid=77777 lasting until 2038 and sends the victim to another chain's real site (href.li/?https://www.jimmyjohns.com/; href.li hides where they came from). No order reaches the restaurant: the real payment step never runs, so there is no confirmation email and no food. We believe the victim's card is then charged for whatever the operator bought.

Why this design. The clone never goes out of date, the victim builds a real order with a real total before anything looks wrong, and one kit works against any restaurant by changing the target site, the domain, and a few path rules. The scammer's server does very little work, which makes it cheap to move. Some variants skip the payment wording and only pin the frame's address, re-setting it every time the page changes it.

Distribution of the Delivery Scam

Searching Google's ad archive (Ads Transparency Center) for the domains in our first sweep found at least 47 Google Search text ads between July 7, 2026, and October 20, 2026, run under at least 46 separate advertiser accounts with at least 43 different, unrelated-looking business names (construction firms, a reptile rescue, a watch company). The ads below are a sub-sample: we searched only for the domains in our first sweep, so there are likely more. Each ad imitates a restaurant's search listing and shows a look-alike domain. Most ran for 1–4 days, usually starting days after the domain was registered.

Status: On November 4, 2026, 367 of the 820 domains still served a site, so they could be getting traffic through means other than ads. None of the ads below were still running on November 3, 2026, but this scam may also be running through other ads, or other means. Google's public Ads Transparency pages now show "Can't find ad" for the creatives and "No ads found" for the domains we checked, which suggests Google has taken them down; the "Ads Transparency page" links below will likely not load. The images and text here come from InfoHawk's own capture of Google's archive, made on or before November 3, 2026. Of the 47 ads below, 41 have Google's rendered image; the rest show the text from Google's ad preview. Domains in the image ads were read from the image and may contain small reading errors.