Is that domain pretending to be yours? How look-alike domains are generated, how IDN homographs get past the eye, and how to tell a threat from a parked registration
DedSec Security Research ·
A finance team receives a reply to an invoice thread from [email protected]. A customer gets a password reset link to examp1e.com. A browser shows a padlock and a name that reads exactly as your brand, because the name is written in Cyrillic letters. None of these involves your DNS, your mail servers or your certificates, so nothing in their configuration prevents it. They are registrations somebody else made, and the earliest point you can act is when you notice them.
The breach and brand monitoring post introduced look-alike domains as one of the attack paths that never touch your network, and the email authentication post explained why DMARC cannot help with them. This post goes further: how look-alike candidates are generated, how internationalised names fool the eye in mechanism, where newly registered look-alikes become visible and what each source misses, and how to separate the domain that is being used against you this week from the one that will sit parked for ten years.
Examples use the reserved name example.com (RFC 2606). Where a statement is about a standard, the RFC or Unicode document is named so it can be checked. The detection and triage methods are general practice, not a description of how Maphra implements its checks.
A look-alike is a set of states, not a yes or no
Before any technique, separate the states a candidate name can be in, because each is visible through a different source and calls for a different response:
Candidate. A string someone could register. Not yet an object in the world.
Registered. The registry holds a record for it. RDAP or WHOIS shows a registrar and a creation date.
Delegated. The registry publishes nameservers for it in the TLD zone, so it can resolve. A registered domain is not necessarily delegated: one with no nameservers, or with an EPP hold status (RFC 5731 says delegation information must not be published for a domain on clientHold or serverHold), is absent from the zone and returns NXDOMAIN.
Resolving. The name or something under it has address records.
Mail-capable. It can receive mail.
Certificated. A publicly trusted certificate has been issued for it.
Serving content, which may be a parking page, a for-sale notice, a redirect, an unrelated business, or a copy of your site.
Most monitoring output collapses these into one row labelled "similar domain found". The rest of this post is about keeping them apart.
How candidates are generated
There is no index you can query for "domains that look like mine". The practical method, used by the open-source tool dnstwist among others, is to generate every plausible variant of your name, then ask DNS which variants exist. The classes worth generating, with example.com as the input:
Omission: one character dropped, exmple.com.
Repetition: one character doubled, exaample.com.
Transposition: two neighbours swapped, exmaple.com.
Adjacent-key substitution: a character replaced by its keyboard neighbour, exanple.com (n sits beside m). Layout matters: QWERTY, AZERTY and QWERTZ neighbours differ, and dnstwist carries more than one layout for that reason.
Adjacent-key insertion: a neighbour typed beside the intended key, exampke.com or examplke.com.
Vowel swap: exampla.com, exomple.com.
Hyphenation: ex-ample.com.
Added words: example-login.com, example-support.com, secure-example.com, example-billing.com. This class is common in phishing, because the result reads as a plausible service name rather than a typo.
TLD swap: the label is exactly yours under another TLD, example.co, example.app, example.net.
Brand as a subdomain: example.com.verify-account.example.net, or example-com.login.example.net. A reader looking at the left of the name sees your domain; the registrable domain is the attacker's. Dot-insertion (ex.ample.com, where ample.com is registrable) is a narrower relative.
Bitsquatting: a single bit flipped in the stored or transmitted name. Artem Dinaburg presented this at Black Hat USA 2011: he registered bit-flipped variants of high-traffic domains and received requests from machines whose memory had corrupted the name in flight, with no user typing anything. Flipping each of the eight bits of e (0x65) gives d, g, a, m and u as valid hostname letters; the others produce E, which DNS treats as the same letter, or characters not allowed in a hostname. For the seven letters of example, that yields 33 distinct valid single-bit variants, including exemple, which is an ordinary French word.
Homoglyphs: characters that look alike. In ASCII alone: rn for m, cl for d, vv for w, 1 or I for l, 0 for o. With internationalised names the set becomes far larger, which is the next section.
The space is large because the classes multiply. Every string exactly one insertion, deletion, substitution or adjacent transposition away from the seven-character label example, over the 37 characters a hostname label can use, comes to 550 distinct labels once those starting or ending with a hyphen are removed. That is distance one only. Multiply by the TLDs you care about, add the dictionary of words an attacker might bolt on, add homoglyphs, and the arithmetic runs away quickly: the 550 distance-one labels alone, under 50 TLDs, are 27,500 names. Enumerating them and resolving each is cheap. Deciding which matter is not.
Two limits of the enumerate-then-resolve approach follow directly from the states above. A DNS lookup cannot see a domain that is registered but not delegated, which is often the state between purchase and campaign. And a generator only finds what its rules produce: example-payments-portal.com is obvious to a person and is not within edit distance one of anything.
IDN homographs, in mechanism
DNS labels are ASCII. A name containing other scripts is stored as an ASCII-compatible encoding: the prefix xn-- followed by the Punycode form of the Unicode label, defined in RFC 3492. The current rules for which Unicode characters may appear in a label, and how a label is converted, are IDNA2008 (specified in RFC 5890 to RFC 5893). The registry, resolver and certificate all deal with the xn-- form. Only the display layer shows Unicode.
That gap is the attack. In April 2017 Xudong Zheng published a demonstration domain, xn--80ak6aa92e.com. Decode the Punycode and the label is five Cyrillic characters: а (U+0430), р (U+0440) twice, ӏ (U+04CF, palochka) and е (U+0435). Rendered, it reads as apple, and at the time Chrome and Firefox displayed it that way in the address bar. Chrome changed its display rules in response; Firefox users were pointed at the network.IDN_show_punycode preference, which displays every internationalised name in its xn-- form.
The vocabulary for reasoning about this is in Unicode Technical Standard #39, Unicode Security Mechanisms:
confusables.txt maps characters to a prototype they can be mistaken for.
The skeleton of a string is computed by normalising it (NFD), replacing each character with its prototype, and normalising again. Two strings with the same skeleton are confusable. This is the practical test: compute the skeleton of your brand and of every candidate, and compare skeletons rather than raw strings.
A mixed-script confusable combines scripts in one label, for example Latin letters with one Cyrillic о. A whole-script confusable is written entirely in one script that happens to resemble another, as the 2017 demonstration was. Whole-script cases are harder to catch with a rule against mixing scripts, because nothing is mixed.
UTS #39 also defines restriction levels, from ASCII-only through single-script and highly restrictive up to unrestricted, which describe how much script mixing a string contains. Browser display policies draw on this vocabulary.
Not every brand is exposed to whole-script spoofing. It needs every letter of the name to have a confusable in a single other script; many Latin letters have no close Cyrillic or Greek counterpart. Running your name through the skeleton algorithm with confusables.txt answers the question for your brand specifically.
Three more facts that change the practical picture:
Browsers protect the address bar, not the link text. Their IDN display rules decide whether the address bar shows Unicode or xn--. Mail clients, chat apps, PDF readers and SMS previews each make their own rendering choice, and the text of a link need not match its target at all.
Registries restrict scripts per TLD. Each registry decides which scripts and characters it accepts, often through IDN tables published in IANA's repository of IDN practices, and many prohibit mixing scripts within a label. Whether a homograph of your name can be registered depends on the TLD, so the candidate list should be filtered by each TLD's policy rather than generated once for all.
The encoding rules have changed under people's feet. Under IDNA2003, faß.de mapped to fass.de. Under IDNA2008, ß is a valid character and faß.de becomes xn--fa-hia.de, a different domain. Unicode's UTS #46 compatibility processing exists to bridge the two. A client using older processing and one using newer processing can resolve the same displayed name to different registrations, which matters if your brand contains ß, ς or the zero-width joiner or non-joiner, the characters UTS #46 calls deviations.
Where new look-alikes become visible, and what each source misses
Certificate Transparency. Publicly trusted CAs log certificates to public append-only logs (RFC 6962, version 2 in RFC 9162), and major browsers require proof of logging. A CA usually logs a precertificate before issuing the final certificate, so the name is public at about the moment of issuance, often before any page is live. Searching the logs for your brand string, and for the xn-- forms of its confusable variants, is an early signal that costs nothing. The TLS posture post covers what CT publishes about your own names. The limits for look-alikes: a name only appears if someone obtained a publicly trusted certificate for it; plain-HTTP phishing does not need one; and a wildcard certificate for *.verify-account.example.net hides example-com.verify-account.example.net completely, because only the wildcard is logged (a wildcard covers a single label, so the attacker picks a brand-bearing name one label deep).
Zone files. ICANN's Centralized Zone Data Service (CZDS) gives approved applicants access to the zone files of generic TLDs, with access requested and granted per TLD. Comparing consecutive files shows newly delegated domains. The limits: zone files contain delegations, so a registered but undelegated name is absent; they contain no subdomains, so brand-as-subdomain names are invisible; and country-code TLDs are outside ICANN's contracts, so most ccTLD zones are not available at all.
Passive DNS. Sensors record the names resolvers actually look up and what they resolved to. This is the source that sees example.com.verify-account.example.net once someone visits it, and it shows a name's address history. The limits: coverage depends on where the sensors sit, a name nobody has resolved yet does not appear, and data arrives after use, not at registration.
Newly registered domain feeds. Commercial and community lists of new registrations, typically assembled from the sources above. Useful as a convenience; check which underlying sources a feed draws from, because it inherits their gaps.
No source covers everything. A scanner that stops receiving from a source and reports "no new look-alikes" is reporting an outage as a clean result, so a monitoring set-up should alert when a source goes quiet, not only when it finds something.
Triage: from similar to dangerous
Distance from your name is a poor ranking on its own. Short brands have dense neighbourhoods full of dictionary words and unrelated businesses, so distance-one matches are mostly legitimate. Meanwhile the names doing damage are often far away in edit distance: example-billing-support.com is many edits from example.com, and an IDN homograph compared in xn-- form shares almost no characters with it. Score on what a reader would perceive instead (the skeleton of the Unicode form, and whether your brand appears as a token after splitting on hyphens and dots), then rank by corroboration.
The corroborating signals, roughly in order of how much they change the picture:
It can receive mail. An MX record means mail to the domain is accepted somewhere. That enables reply-chain fraud: an attacker who inserts a look-alike address into a thread receives the replies. Absence of an MX record does not mean the domain cannot receive mail. RFC 5321 falls back to the domain's address record when no MX exists, so a domain with only an A record may still accept mail; only a null MX (RFC 7505) declares that it does not. Sending needs no MX at all, and the look-alike can publish valid SPF, DKIM and DMARC of its own.
A certificate was issued, especially for a login-flavoured name such as login.example-secure.net.
The page copies yours. Similarity can be measured several ways: fuzzy hashes of the HTML (dnstwist supports ssdeep and TLSH), perceptual hashes of a rendered screenshot, a matching favicon, identical page title. A form whose action posts to a third party matters more than any similarity score.
It references your assets. Phishing kits often load your logo, stylesheet or scripts from your own servers. Requests to your CDN or web servers with a Referer header from a look-alike domain are evidence that only you hold, and a cheap detection to add.
Recent registration and fast infrastructure changes, such as nameservers or addresses moving between runs.
And the reasons a similar domain is not a threat:
It is yours. Defensive registrations, a campaign site an agency bought, a domain that came with an acquisition. Check your registrar accounts and legal records before filing anything. The attribution post covers why registrant data often cannot settle this.
It is a legitimate third party: a reseller, partner, integration, regional distributor, fan site or critic. The UDRP itself lists legitimate noncommercial or fair use of a domain as a legitimate interest.
It is parked. A registrar or parking provider's page, often with ads, or a for-sale notice. Parked is a state to watch, not a verdict, because a parked domain can be repointed in minutes. The event worth alerting on is the change: new nameservers, a new MX, a new certificate, a content hash that moves from the parking template to something else.
One caution about negative results. Phishing kits commonly cloak: they serve the kit only to visitors from certain countries, with certain user agents, via a specific path or token from the lure, and serve a blank page or a 404 to everything else, including scanners from data-centre addresses. "Nothing served at /" is weak evidence that nothing is being served.
Keep the evidence before you act
Look-alike infrastructure disappears and reappears. Whoever handles the report, whether an abuse desk, a dispute panel or your own legal team, needs to see what you saw, so capture it at detection time:
A full-page screenshot, with the address bar or the exact URL recorded.
The raw HTTP exchange: request, status line, headers, redirect chain and body, with a hash of the body.
DNS records as resolved (A, AAAA, MX, NS, TXT), with the resolver used.
RDAP or WHOIS output, including registrar, creation date and the registrar abuse contact.
Certificate details and the CT log entry.
UTC timestamps for each item, and the lure (the email with full headers, or the SMS) if there is one.
The post on why findings need evidence makes the general case; here it is concrete, because the domain may serve a parking page by the time anyone reviews the report.
Response options
These are general practice; which ones apply depends on the TLD, the hosting and what the domain is doing.
Registrar abuse report. RDAP shows the registrar's abuse contact. ICANN's 2013 Registrar Accreditation Agreement requires accredited registrars to publish one and to take reasonable steps to investigate reports. A report showing active phishing or malware, with evidence, is the most direct route to suspension.
Hosting and CDN abuse reports, to the operator of the address the domain resolves to. This removes the content even when the domain survives.
Browser blocklists. Google Safe Browsing has a public form for reporting phishing pages, and other browser and mail vendors run equivalents. A listing protects users even while the domain is still live.
UDRP. ICANN's Uniform Domain-Name Dispute-Resolution Policy is an administrative procedure, run by approved providers including WIPO, in which a trademark holder must show three things: the domain is identical or confusingly similar to its mark, the registrant has no rights or legitimate interests in it, and it was registered and is being used in bad faith. The remedies are transfer or cancellation. It suits a domain you want to own afterwards, not a phishing page you want gone today.
URS. The Uniform Rapid Suspension system was created for the new gTLDs delegated under ICANN's 2012 programme, and was later adopted by some legacy gTLDs. It requires a higher standard of proof and its only remedy is suspension for the rest of the registration period, so the name can be registered again later.
ccTLD dispute policies. Country-code registries set their own; some adopt the UDRP and others run their own procedure.
Defensive registration. Registering every candidate is impossible, and each one is a renewal and a domain to secure. It is reasonable for a short list: your exact label under TLDs where you trade, the obvious typos of your login and payment domains, and names you see attackers favour. Treat each as a non-sending domain: SPF of v=spf1 -all, DMARC at p=reject, a null MX, and a redirect to the real site.
Awareness. Publish your canonical domains, say which domains you send mail and SMS from, and make out-of-band verification of payment or banking changes a fixed process, because reply-chain fraud succeeds against people who are otherwise careful.
DMARC is not on this list for the reason the email authentication post gives: it protects domains you control, and a look-alike is not one of them.
Where Maphra fits
Maphra's breach and brand monitoring covers look-alike domains and impersonating applications, alongside credential exposure in breach corpora and dark-web mentions, and runs as continuous brand surveillance. Its discovery monitors certificate transparency, re-runs on a schedule and diffs the result against the last known surface, reporting what appeared, what changed and what disappeared. Every finding carries the evidence that produced it, and findings are deduplicated across scans and tracked through new, reopened and fixed states.
That is the whole claim. This post does not claim which permutation classes Maphra generates, that its certificate transparency monitoring searches for look-alike names rather than your own, that it computes UTS #39 skeletons, reads CZDS zone files, passive DNS or new-registration feeds, checks MX records or SMTP acceptance, renders screenshots or compares page hashes, applies the corroboration order above, or files abuse reports or disputes. The generation, discovery and triage methods are general practice, written so that you can apply them with dnstwist, a CT search, dig and RDAP.
A checklist you can run yourself
List the names you protect: brand labels, product names, login, payment and support hostnames, and the domains you send mail from.
Generate candidates across the permutation classes and the TLDs that matter to you, for example with dnstwist, including a dictionary of the words attackers bolt on (login, secure, support, billing, verify, account).
Compute skeletons with confusables.txt for your brand and each candidate, and check whether your name has a whole-script confusable.
Resolve candidates, and for the ones that matter most, check RDAP too, since DNS misses undelegated registrations.
Search Certificate Transparency for your brand string and its skeleton forms, and remember wildcards hide subdomains.
Watch your own web and CDN logs for Referer headers from domains you do not own.
Rank by corroboration, not distance: mail capability, certificate, copied content, references to your assets, recent changes.
Mark your own and known third-party domains so they stop resurfacing.
Alert on change, not only on discovery: nameserver, MX, certificate and content changes on parked names.
Alert when a source goes quiet.
Capture evidence at detection, with UTC timestamps, before you report.
Pick the response by goal: abuse reports and blocklists to stop a live page, UDRP to take ownership, URS for a fast suspension where it applies.
Lock down defensive registrations with SPF -all, DMARC p=reject and a null MX.
A look-alike domain is someone else's asset aimed at your users. You cannot prevent its registration, but you can notice it at certificate issuance or delegation rather than at the first complaint, and arrive at the abuse desk with evidence instead of a screenshot taken the morning after.