Lookalike Domains: The Attack Surface You Don't Own

External attack surface management is built on a simple premise: you can't defend what you don't know you own. Discover the assets, scan them, fix what matters. But there's a category of attack surface that never shows up in an inventory, because you don't own it and you never will — the domains someone else registered specifically to be mistaken for yours.

A lookalike domain costs about the same as a cup of coffee and takes ninety seconds to register. It needs no exploit, no CVE, and no misconfiguration on your side. It borrows your reputation and points it at someone else's server. And because it lives entirely outside your perimeter, every scanner pointed at your infrastructure will report a clean bill of health while it's happening.

This is the part of your attack surface you can only find by looking outward. Here's how the attack works, what the data actually says about its scale, and how to find these domains before your customers do.

Four ways to misspell your domain on purpose

Lookalike domains aren't creative. They're generated, and the generation techniques are well-documented and finite. That's genuinely good news: a finite technique space is an enumerable technique space.

Combosquatting deserves particular attention, because it's the one that defeats the mental check most people actually perform. Your brand name is spelled perfectly in secure-example-login.com. A user scanning for a misspelling finds none, because there isn't one. The deception is in the structure, not the spelling — and structure is exactly what a hurried person skims past.

The Unicode variant

There's a nastier relative worth knowing about: the internationalised domain name homograph. Unicode contains characters from non-Latin scripts that are visually identical to Latin ones — the Cyrillic а renders indistinguishably from the Latin a in most typefaces. A domain displaying as аpple.com is encoded in DNS as xn--pple-43d.com, an entirely different domain.

Modern browsers mitigate this by displaying suspected homograph domains in their raw Punycode form rather than the rendered Unicode, which turns an invisible attack into a visible one. That defence is real but partial — it protects someone looking at a browser address bar, and does nothing for a domain that arrives in an email, a chat message, or a QR code.

What the numbers actually say

It's worth being precise here, because this topic attracts a lot of hand-waving.

Zscaler's ThreatLabz team examined more than 30,000 lookalike domains across 500 of the most-visited sites over a six-month window, and found in excess of 10,000 of them serving genuinely malicious content. Roughly a third of the lookalike space they sampled was actively hostile rather than merely parked. Three brands — Google, Microsoft and Amazon — accounted for close to three quarters of the impersonation attempts they catalogued. Nearly half of the malicious domains carried free Let's Encrypt certificates, which is worth remembering the next time someone equates a padlock with legitimacy.

Volume against a single brand can be startling. L'Oréal identified 705 fraudulent domains registered against it in under three weeks — not a slow drip, but an industrialised campaign.

The most useful figure, though, comes from a 2026 study that generated 400 permutations across 15 brands and then checked what actually existed. Around two thirds resolved to a live site. Only about half of those resolving domains were indexed by Google.

Sit with that second number. It means a substantial share of live impersonation domains are effectively invisible to anyone who checks for this by searching for their own brand name. Searching Google for lookalikes finds the ones Google happened to crawl. It is not a survey of what exists.

Registered is not the same as reachable

The single most common analytical mistake here is treating every registered lookalike as an emergency, and the second most common is treating a domain with no website as harmless. Both are wrong, and the distinction determines how you should triage.

A lookalike domain that resolves in DNS and answers on HTTP can serve a credential-harvesting page to anyone who visits it, right now. Free certificate authorities mean it will have a valid TLS certificate and a padlock icon — which, unhelpfully, is precisely the signal a generation of security awareness training taught users to look for.

A lookalike that's registered but serves no website is not harmless. It is a loaded weapon that hasn't been aimed yet. Whoever holds it can:

• Send email from it. Your SPF, DKIM and DMARC records govern your domain. They have no authority whatsoever over a domain you don't control, and a well-configured lookalike can pass its own authentication checks perfectly.
• Stand up a phishing page in the time it takes to deploy a static site.
• Sit dormant for months, accruing the domain age that makes reputation systems trust it more, not less.

The practical consequence: a live HTTP listener is an escalation, not the threshold for caring. Registration is the event worth knowing about.

Why your existing controls don't cover this

Email authentication protects your domain, not your brand

DMARC is essential and you should have it. It is also frequently misunderstood as anti-impersonation protection in general. A DMARC policy of p=reject instructs receiving mail servers to reject unauthenticated mail claiming to be from your domain. Mail from example-billing.com isn't claiming to be from your domain. It's claiming to be from a different domain that merely looks like yours, and it can hold flawless SPF and DKIM records of its own.

Certificate Transparency is your early-warning channel

Every publicly-trusted TLS certificate issued today is logged to public, append-only Certificate Transparency logs. Because a convincing phishing site needs HTTPS, and HTTPS needs a logged certificate, attackers are pushed into announcing themselves in a public ledger you can monitor.

CT monitoring frequently surfaces a lookalike domain days before it is used, in the window between certificate issuance and campaign launch. If you already monitor CT logs for your own subdomains — and you should, since it's how attackers enumerate them — extending that watch to brand-similar strings is a small increment of work for a large increment of warning.

How to find them

Detection is mechanical, which means it can be automated and should be continuous rather than annual.

1. Generate the permutation space. Feed your base domain to a permutation engine. The open-source dnstwist is the reference implementation and produces typo, homoglyph, TLD-swap and combosquat variants.
2. Resolve every candidate. Most permutations don't exist. A DNS lookup that returns nothing is a domain nobody has bothered to register, and you can discard it cheaply.
3. Probe what resolves. For every candidate with an A record, attempt an HTTPS connection with a short timeout. What answers separates a live phishing host from a dormant registration.
4. Check the mail records. A registered lookalike with an MX record is configured to receive email. That is a strong signal of intent, and it is frequently the tell that precedes a business email compromise attempt.
5. Watch Certificate Transparency continuously. Permutation scanning is a snapshot. CT monitoring is a live feed.
6. Re-run it on a schedule. The permutation space is static; its occupancy changes weekly. A scan you ran last quarter tells you about last quarter.

What to do when you find one

Not every lookalike warrants the same response, and the two escalation paths have very different costs.

Capture evidence first. Dated screenshots, the full URL, DNS and WHOIS/RDAP records, and the hosting provider. Malicious sites are taken down or rotated quickly, and a report submitted after the evidence has evaporated goes nowhere.

For active phishing, the registrar abuse report is almost always the correct first move: it is free, it is fast, and suspension stops the harm. UDRP is a property-recovery mechanism, not an incident response tool. Winning one requires demonstrating that the domain is confusingly similar to your registered trademark, that the registrant has no legitimate interest in it, and that it was registered in bad faith — all three, not any one.

Whichever route you take, be specific. Include the URL, the dated evidence, the observed behaviour and the concrete harm. Vague reports are deprioritised; well-evidenced ones get actioned.

On defensive registration: buying the handful of permutations closest to your real domain is sensible and cheap. Attempting to buy the whole permutation space is not — it runs to thousands of domains per brand, and the attacker only needs one you didn't think of. Register the obvious few, monitor the rest.

How FortWatch handles this

FortWatch's brand monitoring scanner automates the detection loop above. It reduces each domain asset to its base domain and runs eight permutation engines against it — keyboard-adjacent typos, character omission, character duplication, adjacent transposition, ASCII homoglyphs, TLD swaps, and phishing-style prefixes and suffixes such as login- and -portal.

Each generated candidate is resolved via DNS, and anything with an A record is probed over HTTPS with an HTTP fallback. The result maps directly onto the distinction above: a registered lookalike serving live HTTP is raised as high severity, and one that is registered but DNS-only is raised as medium — real attack surface, not yet aimed.

Two honest limitations. The homoglyph engine covers ASCII lookalikes rather than the full Unicode IDN space, so a Cyrillic-substitution homograph is outside its current coverage. And the permutation list is capped, which keeps scans fast but means it prioritises the highest-probability variants rather than exhausting every theoretical permutation. Both are deliberate trade-offs, and it's better that you know where the edges are than discover them later.

What do I do with this?

• Run a permutation scan against your primary domain this week. If you've never done it, budget some surprise — the first run against an established brand rarely comes back empty.
• Triage by capability, not by aesthetics. Live HTTP first, then domains with MX records, then dormant registrations. Don't dismiss a registration because there's nothing on it.
• Stop treating a Google search for your brand as coverage. Roughly half of live squats aren't indexed. Searching finds what Google crawled, not what exists.
• Monitor Certificate Transparency logs for brand-similar strings. This is your earliest warning, often days ahead of a campaign.
• Write the abuse-report template before you need it. URL, dated screenshots, DNS and WHOIS records, observed behaviour, business impact. Having it ready converts a scramble into a task.
• Register the obvious few defensively. The nearest handful of permutations and the major TLD swaps. Then monitor, rather than trying to buy the whole space.
• Put it on a schedule. Registration activity changes weekly. Point-in-time checks answer a question about the past.

Your own infrastructure can be flawless — every port justified, every certificate valid, every header correct — while a domain one keystroke away from yours quietly collects your customers' passwords. That domain will never appear in an asset inventory, because it isn't an asset. It's still your problem, and looking for it is the only way you'll know it exists.