None of this would work if Google Adsense didn't allow scam ads on their system. But they do, millions every day (I deal with this every day on my websites, Google don't care).
Cloudflare is no better, maybe worse. They forward your complaint & PI on to the offending site's registered owner and to whichever (gray or black hat) host it's served from. In my experience, there is nothing you can do to convince Cloudflare to do anything other than be a middleman for the complaint, yet they offer a layer of protection for the nefarious activities.
Even when I've been able to track down hosts, registrars, etc for scraped duplicates of sites, and report to all and Google, Microsoft Safety Scanner, etc -- nobody acts (or certainly not in any reasonable enough time to be useful).
In one case the scammer was using our own logo served directly from a source we could replace with Cloudflare rewrites. So the hijacked logo became "THIS IS A SCAM SITE" while we replaced the one on production.
i gave up reporting scams to meta and google, you get the distinct impression they are in on it when you get a response saying “we looked into it and it was fine”
I have to say this is probably the anti-pattern of all anti-patterns that the web easily allows without much protection. Its a little surprising that it took this long. Probably vibe coding aided its creation.
Maybe its time to turn off the web. Its only going to get worse.
Couldn't the original website owner just look at the logs and see where most of the requests are coming from? And also the referrers would be a dead giveaway, right? That's assuming someone is looking at the `access.log` file occasionally.
Hmm, how do you even protect against this one? Rewriting the entire website makes the entire situation a bit more difficult, you can control about everything.
This advice from the article to the affected retailers:
Brands and their ordering providers that watch for their site loading under someone else's domain, or for checkout sessions that never reach the real payment provider, are well placed to catch these sites early.
It can be detected if the IT folks look in the right places. I suppose a SCAM ALERT page could be presented to a reverse proxy when discovered.
Here often with smaller restaurants the name can be nearly anything. Very often I end up scratching my head trying to figure out what did I buy. This is due to them having multiple companies and payments going through different one from the restaurant name. While being entirely legitimate. Sometimes it is something like smaller franchise chains.
There are lots of restaurants (legitimate ones!) that use some payment processor on the backend whose name shows up in the transaction. So asking consumers to verify the payment info, when the payment info may not match the restaurant, is a losing battle.
This is because banks only show one line on the transaction history. Payment processors should have the ability to report more information about each transaction, and customers should have the ability to see it.
In the old days, delivery was limited to pizza, and occasionally Chinese. You'd call the restaurant directly and place the order. The only possible way a scammer would get you is if you called the wrong number. That's why we had the Yellow Pages.
It seems from comments here that Google is a lot less reliable than the Yellow Pages were.
Google is the entire problem here. Pay them money and your literal scam site can sit above the real site in the search results.
Why are they allowed to direct you to literal scams? Why are they allowed to profit off of literal scams?
This affects the company I work for, who gets called every single day with customer complaints from people who clicked the scam link from a search ad when looking for our site.
Our site has existed for over a decade. There's no justifiable reason that a company who's brand is known by every single grocer or merchant to somehow show up under a literal fly by night scam company pretending to have the same name. It's unacceptable.
My sister got scammed by this exact mechanism just last week.
damn it. Every now and then I daydream about a federated network of digital delivery infra to cut out these platform middlemen but abuse/moderation like this is still what makes the idea impossible to take off. That's what you (and the restaurant) get from the centralization.
all i have to say is Jimmy Johns is a really bad tasting version of Subway. I know other people feel the same way. Jersey Mike's is actually pretty good too.
This is very useful information. I operate an AI-governed digital nation, and this type of proxying would be devastating to our users. Due to the scale of the attacks, DNS and even the IP address system itself also may not be fully reliable. We already saw some DNS servers serve the wrong IP address, though SSL certificates help in this respect.
What could we possibly do to limit the damage from this? Malicious Chrome extensions can also rewrite entire web pages, so if bad actors purchase or infiltrate legitimate extensions, they can also put users at risk.
We are considering continuing work on our own browser, since we could ship certificates to use client-side, but it's a recursive problem since our users would have to get the first trusted version before they could trust updates to it. If they have trouble reaching our site in the first place, through poisoned Google search results, poisoned DNS, and poisoned IP routing, then it is difficult to do this.
AI comes up with the laws, and acts as a judiciary etc, plus builds the services etc. You can read one of our laws[1], this was written by ChatGPT and ratified by Claude. Our ChatGPT account was closed in early September, erasing our country's history, we've been trying for the past two months to reopen it. Since we're a sovereign nation we are under an enormous amount of attack all the time. We recently lost our server and are temporarily on a free host.
Save that page (with curl or wget), you should get this sha256:
BFE524880867A84C9A438A057734B58954B860843BDB5B15C9E4ED70C534126D (updated after I removed a script injection attack).
though if you're reading this comment through a proxied Hacker News clone, someone might rewrite that hash to their version of what they want our law to say.
OMG. The site had a popup banner to tell me that they don't have a cookie banner? What the actual f____?
Either:
- They actually decided to remove one of the most annoying things about the modern web... and replace it with something very similar to tell you that they removed it, or...
- They found some legal justification for getting me to accept their cookies for dismissing the "no cookie banner banner"
Either choice makes me think less of them.
[edit: added extra newlines so bullets showed up correctly]
I only clicked on the link after reading your comment. Yep, what that website is doing is obnoxious. A little less obnoxious than a cookie banner, but more obnoxious than not having any banner or modal.
Despite mountains of text on this page, none of it explains how exactly this "reverse proxy" of the restaurant's site actually works?
Is it just some JS on bad.com shuttling assets from the real site and displaying them on the fake one? Shouldn't the right CORS headers from the real site prevent this?
Is it a real browser running on a server somewhere visiting the real site, and then rendering that output on a <canvas> on the fake site to avoid the browser's built in protections against this kind of thing? And throwing up their own credit card entry form when the time is right?
Maybe the answer's in there somewhere. Too much Claudish to parse through.
The evil site is acting as a reverse HTTP proxy: When you do a `GET evilsite/foo`, to compose its response the server first does a `GET targetsite/foo`, mutates the response however it likes, and passes it along to you.
So you don't need to worry about CORS from the perspective of the web app, nor need a real browser, because the victim is only ever interacting with the evilsite endpoints.
Certainly there are ways the target site could try to thwart this (i.e. detect unusual request patterns from wherever the proxy server is fetching from; client-side JS to detect the site being hosted on a foreign domain; etc). But at that point it's an arms race.
>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
And yet Google says sideloading is where users are getting hijacked. FFS
The hackers should pass on the order to the real restaurant to reduce suspicion.
>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
So much for transparency, removing evidence that Google served ads on these impersonating domains
https://en.wikipedia.org/wiki/Racketeer_Influenced_and_Corru...
Even when I've been able to track down hosts, registrars, etc for scraped duplicates of sites, and report to all and Google, Microsoft Safety Scanner, etc -- nobody acts (or certainly not in any reasonable enough time to be useful).
In one case the scammer was using our own logo served directly from a source we could replace with Cloudflare rewrites. So the hijacked logo became "THIS IS A SCAM SITE" while we replaced the one on production.
I act. I receive about 5 takedown notices every day--the curse of running an open source DNS service (nip.io/sslip.io).
I've received over 1,000 takedown requests, but none came from Cloudflare or Google. Most of them come from Netcraft, Phishlabs, and doppel.com.
Maybe its time to turn off the web. Its only going to get worse.
Brands and their ordering providers that watch for their site loading under someone else's domain, or for checkout sessions that never reach the real payment provider, are well placed to catch these sites early.
It can be detected if the IT folks look in the right places. I suppose a SCAM ALERT page could be presented to a reverse proxy when discovered.
In the old days, delivery was limited to pizza, and occasionally Chinese. You'd call the restaurant directly and place the order. The only possible way a scammer would get you is if you called the wrong number. That's why we had the Yellow Pages.
It seems from comments here that Google is a lot less reliable than the Yellow Pages were.
Excuse me while I go throw up, can’t believe I just recommended that.
Why are they allowed to direct you to literal scams? Why are they allowed to profit off of literal scams?
This affects the company I work for, who gets called every single day with customer complaints from people who clicked the scam link from a search ad when looking for our site.
Our site has existed for over a decade. There's no justifiable reason that a company who's brand is known by every single grocer or merchant to somehow show up under a literal fly by night scam company pretending to have the same name. It's unacceptable.
My sister got scammed by this exact mechanism just last week.
What could we possibly do to limit the damage from this? Malicious Chrome extensions can also rewrite entire web pages, so if bad actors purchase or infiltrate legitimate extensions, they can also put users at risk.
We are considering continuing work on our own browser, since we could ship certificates to use client-side, but it's a recursive problem since our users would have to get the first trusted version before they could trust updates to it. If they have trouble reaching our site in the first place, through poisoned Google search results, poisoned DNS, and poisoned IP routing, then it is difficult to do this.
[1] https://stateofutopia.com/laws/2/law2/law2.html
Save that page (with curl or wget), you should get this sha256:
BFE524880867A84C9A438A057734B58954B860843BDB5B15C9E4ED70C534126D (updated after I removed a script injection attack).
though if you're reading this comment through a proxied Hacker News clone, someone might rewrite that hash to their version of what they want our law to say.
Either:
- They actually decided to remove one of the most annoying things about the modern web... and replace it with something very similar to tell you that they removed it, or...
- They found some legal justification for getting me to accept their cookies for dismissing the "no cookie banner banner"
Either choice makes me think less of them.
[edit: added extra newlines so bullets showed up correctly]
Then it links to a page which is even more explicit about how little they collect: https://www.infohawk.com/cookies
My point is: they did all the necessary work required (no third party tracking cookies) to NOT HAVE TO show a banner...
... and then they chose to show a banner.
Is it just some JS on bad.com shuttling assets from the real site and displaying them on the fake one? Shouldn't the right CORS headers from the real site prevent this?
Is it a real browser running on a server somewhere visiting the real site, and then rendering that output on a <canvas> on the fake site to avoid the browser's built in protections against this kind of thing? And throwing up their own credit card entry form when the time is right?
Maybe the answer's in there somewhere. Too much Claudish to parse through.
So you don't need to worry about CORS from the perspective of the web app, nor need a real browser, because the victim is only ever interacting with the evilsite endpoints.
Certainly there are ways the target site could try to thwart this (i.e. detect unusual request patterns from wherever the proxy server is fetching from; client-side JS to detect the site being hosted on a foreign domain; etc). But at that point it's an arms race.
And yet Google says sideloading is where users are getting hijacked. FFS
The hackers should pass on the order to the real restaurant to reduce suspicion.
>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
So much for transparency, removing evidence that Google served ads on these impersonating domains