Inside a Restaurant Delivery Payment-Skimming Campaign — InfoHawk News

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.