The Clone That Never Registered a Domain

Background

In mid-2026, a full copy of an AI solutions and consulting provider's public website was found live on the internet. It served over valid HTTPS, showed no browser warning, and used the company's own pages and wording.

The unusual part was the absence of a domain. The attacker had not registered one at all. Instead of buying a look-alike address, they opened a free account on a mainstream static-site hosting platform, the kind developers use every day to publish sites. They named the project after the company's brand and uploaded the copied site. Within minutes they had a branded hostname on well-regarded infrastructure, with a TLS certificate issued automatically, at no cost.

The Problem

A clone is dangerous on any infrastructure. This one sat in a place most brand-protection setups cannot look:

• No registration, so no paper trail. There was no registrar, no WHOIS or RDAP record and no entry in any newly-registered-domain feed. Controls that trigger on a suspicious registration had nothing to trigger on.
• Free permutation tools are blind to it. Typosquat scanners such as dnstwist, and the many free tools built on the same idea, generate candidate registrable domains (typos, homoglyphs, TLD swaps) and check which ones exist. This clone lived on a subdomain of a domain owned by a large hosting company, with the brand sitting in the label: brandname.com → brandname-cloud.hostingplatform.dev. It is not a permutation of the company's domain, so it appears in no permutation list. A daily typosquat scan would never have surfaced it.
• The infrastructure came pre-trusted. The clone inherited the platform's reputation: automatic HTTPS, no certificate warning, no "newly registered domain" flag in a mail filter, clean hosting IPs. The checks people are trained to make, such as looking for the padlock or hovering the link, all came back green.
• There was nothing to seize. With a conventional clone you have two levers: the registrar and the host. Here there was no registrar. The platform operator was the entire takedown path, and knowing how to reach it quickly was the difference between one day and several weeks.
• It was named after a previous takedown. The project label was built from a look-alike domain that had already been taken down for this brand once before. A clone removed from a registered domain does not necessarily stop. It can reappear somewhere there is no domain left to take away.

Market Context

Free developer hosting is now standard impersonation infrastructure. Namespaces such as *.pages.dev, *.web.app, *.netlify.app, *.vercel.app, *.github.io and *.azurewebsites.net exist so that anyone can publish a site in minutes with automatic HTTPS at no cost. For an attacker that combination is hard to beat: no spend, no registration footprint, instant TLS, a reputable parent domain and a free choice of hostname.

It also changes the economics of impersonation. A look-alike domain costs money, creates a public registration record, is visible to monitoring the moment it is created, and can ultimately be suspended by a registrar. A free project subdomain costs nothing, publishes nothing about who created it, and can be stood back up under a new label within minutes of a takedown.

There is also a gap in how brand monitoring is usually framed. The default model, watching for domains that look like yours, has a hard boundary at the domain itself. It sees yourbrand.io. It does not see yourbrand.somefreehost.dev. Attackers know where that boundary sits, and look-alike domain attacks are increasingly staged just outside it.

Risks to the Company

• Client and prospect deception: A consultancy's website is a funnel: enquiry forms, document requests, contact details, portal links. A convincing copy is a ready-made harvesting point aimed at the people the company most wants to reach.
• Employee and candidate exposure: Staff and applicants directed to a page that looks like the company's own have no reliable way to tell the difference, particularly when the link arrives inside an otherwise ordinary email or message.
• The padlock working against them: Because the platform issued a valid certificate automatically, the single check most people rely on confirmed the fake site as secure. Security awareness training does not help when the trust signal is genuine.
• A slow response if found late: Without a known abuse route to the platform, chasing a takedown for a hostname that has no registrar and no WHOIS record burns days of security and legal time while the clone stays up.

The Solution

The clone was picked up by the monitoring layers that do not depend on a domain existing, and missed by the one that does. DefendDomain's proactive domain monitoring, the layer most people mean when they say "domain monitoring", never saw this attack and could not have, because there was no registration to see. Three other layers could.

• Certificate monitoring. Every certificate the platform issues is published to the public Certificate Transparency logs. DefendDomain streams those logs in real time, more than 75 million certificates a day and around 2.5 billion a month. Every hostname is matched against protected brand terms, not only registrable domains, which is what makes brand abuse inside someone else's subdomain visible at all. A brand used as a project label on a free hosting platform is an explicit high-risk pattern in our triage, treated as impersonation until proven otherwise. Fragment matches, where the brand sits inside an unrelated word, are suppressed rather than passed on as noise.
• Content fingerprinting. Because the site was a straight copy, it carried the company's own distinctive wording. Fingerprints of that content are monitored continuously against search results, so the company's own copy surfacing on a host it does not own is a signal in itself, wherever that host lives and whatever it is called.
• Embedded security markers. An invisible marker in the real site travels with any copy of it. When a cloned page loads from an unauthorised host, the marker reports where it is running from. Copy the site, and you copy the beacon with it.
• Evidence assembled automatically. Screenshots of the clone alongside the real site, DNS and hosting detail, and an AI content comparison confirming the pages matched. All of it packaged into a ready-to-send abuse case rather than pieced together by hand under time pressure.
• A takedown aimed at the only party that mattered. With no registrar in the picture, the platform operator both hosted the content and controlled the namespace, which made it the attacker's single point of failure. One evidence-backed abuse report went to that operator on the day the clone was confirmed.

The site was offline the following day, roughly twenty-four hours from confirmation to takedown. No client, prospect or employee was known to have reached the page before it went down.

Monitoring continued afterwards, including a deliberate sweep of the other free hosting namespaces for the same brand. A clone that costs nothing to host also costs nothing to rebuild somewhere else. Protecting a brand means watching for your content wherever it appears, rather than watching a list of domains someone might buy.