InfoHawk finds 820 cloned restaurant delivery sites skimming cards and bank SMS codes

Researchers at InfoHawk have documented a payment-skimming campaign that clones restaurant ordering websites at scale. Across two research passes, the team identified 820 domains impersonating 35 restaurant brands, 808 of them registered under the .delivery top-level domain and the remainder using .com or .shop addresses. The report, which surfaced on Hacker News in early November 2026, describes clones convincing enough to pass as the real thing even to careful customers.

How the clones work

The investigation began with a single suspicious domain imitating Jersey Mike's, the US sandwich chain. According to InfoHawk, the attackers did not rebuild the restaurant's site from scratch. Instead they ran a reverse proxy in front of it: the proxy fetches live pages and assets from the legitimate website and serves them to visitors on the attacker's own domain. Menus, images and the ordering flow all originate from the authentic source, so the clone behaves like the genuine article.

The only part the operators replace is the checkout. InfoHawk reports that the substituted payment form asks for credit card details and then for the SMS verification code the customer's bank sends to approve a transaction. A stolen card number is valuable on its own; pairing it with a live one-time code can let criminals push fraudulent payments through bank verification, depending on how the victim's bank uses that code.

Scale and targets

Most of the 820 domains are typosquats: near-miss spellings of brand names, with repeated or swapped characters, parked on a TLD that superficially suits food ordering. Jimmy John's is the most heavily impersonated brand, with 404 lookalike domains, and InfoHawk's registration and scan dates for that brand span 3 March to 21 October 2026. That range suggests the operation built up its infrastructure gradually over months rather than appearing overnight.

The restaurant is not the weak link

A detail InfoHawk stresses: none of this requires the legitimate restaurant's website to be hacked. The attackers operate entirely on infrastructure they control and use the real site merely as a content source for the proxy. A merchant can secure its own domain perfectly and still watch customers get funneled to a pixel-accurate copy elsewhere, which makes this a brand-abuse problem as much as a web-security one.

Why it matters

Reverse-proxy phishing, sometimes called a real-time or browser-in-the-middle phishing proxy, neutralises most of the cues people rely on to spot fraud. Because the pages really are the brand's pages, fetched live, the layout, content and session behaviour all look correct; only the address bar differs, and a plausible typosquat on .delivery is easy to miss on a phone screen.

For merchants, the campaign shows why monitoring for lookalike domains needs to be continuous: hundreds of registrations spread across TLDs are slow and expensive to take down, while the financial harm lands on customers and card issuers. For developers building ordering and payment flows, it argues for trust signals baked into the payment step itself rather than depending on the authenticity of the surrounding site. And for anyone ordering food online, the practical defence is mundane but effective: reach the restaurant by typing its known domain or using its official app, and treat any checkout that collects a bank SMS code in the same form as card details as a red flag.