Five clones of one store: what each abuse team did
这篇文章显示的是英文原文。
中文版暂未发布,因此先展示原文。
OpenBait is a takedown service for fake websites and phishing sites that copy a company's website. When a copy steals passwords or card numbers, as these did, we report it with evidence to the companies that can take it offline and stay on it until it's down; a plain copy is taken out of Google search results instead. Pro is $299 a month for up to 3 takedowns, Business is $499 a month for up to 10, and a single takedown is $199, paid once. To get started, paste the copy's link into "Check a link" on our homepage or pick a plan. If it is your Shopify store that was copied, here is how we get the copy taken down. What follows is one of those cases.
Between 2026-09-16 and 2026-09-19 we worked one case for a US home-products retailer: five clone storefronts on .shop domains, feeding four card-collection domains. This is the record of what each party did and when. It includes the four days the retailer spent with our wrong "offline" notice for a site that was still serving visitors in some countries.
If your own store has just been copied and you want the short version first, read what to do when someone copies your website. This page is the full record behind it.
All times are UTC. The collection domains behind the storefronts are attacker infrastructure that was still live when we last checked. We call the storefronts shop-A to shop-E and the collection domains collector-1 to collector-4 instead of publishing a working map of it. Where our case ledger says "inferred" or "cannot be determined", this text says the same.
What the sites were
These were card- and identity-theft kits with a cloned shop as the front end, not counterfeit stores. The front end was a copy: in a sample of 30 product pages on shop-A, all 30 descriptions matched the retailer's originals word for word, under the retailer's logo.
At about 09:30 UTC on 2026-09-16 we found that checkout on shop-A asked for card data. The card-number field was an iframe served from a separate domain (collector-1), and during checkout no request went to any payment gateway.
The kit behind that form asks for the one-time passcode the bank sends, the card PIN, and approval of the payment in the banking app. A fake prize step then asks the victim to upload photos of both sides of a driver's license. The kit captures everything a shopper types, and nothing they do buys anything.
None of this shows on the homepage. When the retailer first reported shop-A at 01:04 UTC on 2026-09-11, our own classifier scored it legitimate (0.93) and Google Web Risk returned no threat. The theft only appears once you add a product to the cart and reach the payment step.
The five storefronts were all registered at one registrar between May and July 2026 and hosted on one network. Two of the four collectors shared a single IP. We hold records of each, captured on 2026-09-16 while they were serving. shop-E broke at add-to-cart on the first pass, so we identified its collector afterwards.
Timeline
The first abuse emails went out at 09:35 UTC on 2026-09-16; by the morning of 2026-09-17 all five storefront domains were gone from DNS.
| Time (UTC) | What happened |
|---|---|
| 09-16 09:35 | First reports sent. |
| 09-16 10:00 | We submit automatically to third-party feeds. One submission fails because of an error on our side. |
| 09-16 11:10 to 12:10 | shop-A stops answering us. The registry shows no hold. |
| 09-16 12:10 | After three failed liveness checks and manual checks from four networks (all in one country), we mark shop-A offline and notify the retailer. |
| 09-16 12:52 to 12:57 | The retailer submits four more clone domains, shop-B to shop-E. We walk each one to the payment step. Three are confirmed, each with its own collector. |
| 09-16, before 14:49 | We send a second batch of reports. The storefronts stop answering us within 30 minutes. |
| 09-16 14:49 | shop-B is silent from both of our vantage points. We mark it offline and notify the retailer. |
| 09-16 22:58 | Registrar places clientHold on shop-E; it leaves the .shop zone. |
| 09-17 01:05 to 01:37 | Third-party scans from several countries return the full storefront for shop-B (verdict malicious); from several other countries, and from every network we use, the same URL returns nothing. |
| 09-17 02:03 | Third-party scans show shop-A and shop-C serving again. |
| 09-17 05:17 | We re-report to the registrar. |
| 09-17 06:11 to 06:13 | shop-C then shop-D: nameservers change to the registrar's own, and each domain now redirects to a WHOIS-verification suspension page. |
| 09-17, morning | shop-A and shop-B: the A records in their Cloudflare zone are emptied. Whether the attacker or Cloudflare did this cannot be determined from outside. |
| 09-17 12:43 | The .shop registry places serverHold on collector-3. We had never reported it to the registry. |
The takedown that wasn't: how a live site looked dead to us
shop-B was never down. It answered visitors from some countries and ignored others, including every network we had; we recorded "cannot connect" as "offline" and told the retailer so. Third-party scans from other countries exposed it: on the morning of 09-17 the same URL served a complete storefront to several countries and nothing to several others, in the same window.
A server that is really down doesn't behave the way this one did. But a site that quietly filters out the people watching it can look just like one that is gone, if you only look from one place. We had no evidence the host had removed anything, only that the site had stopped answering us.
The "Offline" notice the retailer received was wrong, and it went out automatically after three failed checks. The written correction, with the state of all nine domains as measured that day, went out on 2026-09-20, four days after the first wrong notice. That gap is the worst part of this case: an automated status change is cheap to send, and the correction that undoes it is not, so the system has to stop making that claim in the first place.
The lesson: a single vantage point cannot declare a site dead. Every probe we had sat in one country, so a site that ignored that country looked gone to us while it kept taking cards from everyone else.
Why one domain was suspended before the others
The registrar suspended shop-E at 22:58 UTC on 09-16, about six hours before we re-reported the rest. It was also the only one of the five flagged by the major antivirus vendors rather than by smaller feeds. We handled all five identically: same emails, same evidence, same automated submissions. The other four weren't suspended in that first round. Five domains is a small sample, and we can't say why one moved first. The only difference we can see is in who flagged it, not in what we sent.
What happened at the registrar
shop-C's nameservers changed at 06:11 UTC and shop-D's a minute later, under an hour after the re-report. Only a registrar can change a domain's delegation, and the page it lands on is a WHOIS-verification suspension notice, so this was registrar action. We got no confirmation. The timing fits, but it doesn't prove that our report was the cause. Unlike the network-level filtering of the day before, a suspension at the registrar survives a change of host.
Reporting a phishing domain to its registrar explains where a registrar report fits.
Can a lookalike domain be taken down without a registered trademark?
Yes, if the site takes passwords or card numbers: that is fraud, and a registrar's abuse process covers fraud whether or not the brand holds a trademark. This case is weaker evidence for that than an earlier version of this page claimed.
Every abuse letter we sent cited the brand's original US trademark registration. On 09-19 we read the USPTO status record and found it had been cancelled in August 2025, because a required declaration of use was never filed; the registration certificate itself shows nothing about the cancellation. On 09-22 we found that the brand had registered the same word mark again in December 2025. So the registrar suspended three storefront domains on letters that cited a cancelled registration number. The brand did hold a live registration the whole time, so this case doesn't show what happens to a brand with no registration at all. The earlier version of this section said the brand had no valid registration. That was wrong.
What is still standing
Most of the operation is still up. At our last check on 2026-09-19, three of the four collectors were live and unchanged. The fourth is on serverHold from the .shop registry, which we had never written to.
The storefronts were disposable. The collectors are shared, and a new storefront domain can be attached to them the day it is registered. None of the parties we wrote to has sent us a notice saying what it did with our report, as far as our records show. This is not a success story.
What we changed
We no longer call a site offline until we have confirmed it.
How reports, evidence and case status fit together is on how it works.
最后更新: 2026年10月22日
相关文章
仿冒域名(Typosquat)检测实务指南:5 种方法
从运维视角梳理 Typosquat 检测的 5 种主流方法:dnstwist、Certificate Transparency 日志、新注册域名(NRD)feed、注册局区域文件、搜索引擎/社交监控。每种方法的强项、盲区,以及实际工作中如何组合。
浏览器拦截名单能把钓鱼站挡到什么程度
Google Safe Browsing、Microsoft SmartScreen 和 DNS 级拦截名单各自能做什么,为什么慢、结果难预测,以及我们在一个计时案例里实际测到的情况。
向注册商举报钓鱼域名之后:谁动了,谁没动
钓鱼站的每一层分别由哪类公司掌握、能停掉什么,为什么又慢又难,以及我们自己两个案子里发生的事,包括犯过的错。