A homograph attack (also called a homoglyph attack) is the use of characters that look identical to other characters to forge a domain name (opens in new tab), email sender, username, or file name that a target cannot visually distinguish from the real one.
One form is the internationalized domain name (IDN) homograph attack, in which an attacker registers a domain that swaps a Latin letter for a Unicode look-alike, such as the Cyrillic "а" (U+0430) for the Latin "a" (U+0061). The two domains resolve to entirely different servers but can appear indistinguishable in many fonts and applications, even during careful inspection.
How homograph attacks work
Homograph attacks exploit how the domain name system handles non-ASCII characters. DNS stores and resolves internationalized domain names in an ASCII form that Punycode encoding (opens in new tab) produces: every internationalized label begins with the prefix "xn--" followed by an ASCII string, so DNS itself needs no changes.
Browsers and other applications then convert that ASCII form back into Unicode for display. The deception happens during that display step: applications normally display Unicode (opens in new tab) rather than the Punycode version unless configured otherwise.
In 2017, security researcher Xudong Zheng registered xn--80ak6aa92e.com, which he built entirely from Cyrillic characters, and it rendered as apple.com in Chrome and Firefox during academic testing (opens in new tab). He also served it over HTTPS (opens in new tab), so the spoofed address carried a browser padlock.
The attack class is older still: a 2005 ShmooCon demonstration spoofed paypal.com with a Cyrillic "a" and drew a public statement (opens in new tab) from ICANN weeks later.
Why homograph attacks are hard to stop
Browsers, registries, email clients, and certificate authorities apply fragmented defenses across every layer that renders text. Browsers apply heuristics (opens in new tab) that force suspicious IDNs to display as Punycode, but each application implements its own policy, and no two convert alike (opens in new tab).
Whole-script confusables (opens in new tab), labels that use only one non-Latin script, can slip past the mixed-script checks some browsers rely on. Registry controls carry the same seam: gTLD registries must restrict labels to a single script, but they need not constrain whole-script confusables under ICANN's IDN guidelines (opens in new tab).
Email is weaker still. Clients including Gmail and iCloud displayed homograph IDNs (opens in new tab) in Unicode sender addresses during peer-reviewed testing, even for domains that browsers would have blocked, and some non-browser messaging contexts do not apply the same IDN display protections browsers use.
Certificate authorities compound the problem because their requirements focus on domain control validation (opens in new tab); visual similarity to another brand's domain plays no role in issuance, so a homograph site can carry a legitimate padlock.
Types of homograph attacks
The technique appears wherever applications render text for human eyes. The domain-level classes come from Unicode Technical Standard #39 (opens in new tab), the formal framework for confusable detection; attackers also use ASCII-only and non-domain variants.
- Mixed-script IDN homographs: A Latin domain with one or more characters swapped for look-alikes from another script, such as "pаypаl" carrying the Cyrillic "а". Attackers use these substitutions to phish cryptocurrency users (opens in new tab).
- Whole-script confusables: An entire label that uses a single non-Latin script to mirror a Latin string, like the all-Cyrillic apple.com domain above. This class can bypass defenses that check only for mixed scripts.
- ASCII homographs: No Unicode required. paypaI.com, with a capital "I" standing in for a lowercase "l", can closely resemble paypal.com on mobile. ASCII homograph spoofing (opens in new tab) predates IDN implementation standards.
- Email display name homoglyphs: Attackers place look-alike characters in the "From" display name rather than the domain. Business email compromise (opens in new tab) campaigns have used Greek and Cyrillic homoglyphs (opens in new tab) to render sender names such as "Sρօtifу Support Team." Because authentication checks the sending domain rather than the visual display name, these messages can pass SPF, DKIM, and DMARC.
- Supply chain and file name homoglyphs: Attackers substitute look-alike characters in software package names (opens in new tab) to impersonate legitimate dependencies.
The Right-to-Left Override character produces a parallel effect in file names under the MITRE ATT&CK T1036.002 (opens in new tab) classification.
How to defend against homograph attacks
Mature programs combine continuous monitoring (opens in new tab) with the controls below:
- Register defensively. Register homoglyph variants of critical domains before attackers do and forward them to the main site.
- Generate and monitor permutations. Tools such as dnstwist produce homoglyph and typo permutations (opens in new tab) of a brand domain, then check which ones resolve, host mail servers, or serve look-alike content.
- Watch certificate transparency logs. An HTTPS phishing site needs a certificate, which appears in public CT logs (opens in new tab) after issuance. If the attacker obtains the certificate before publishing the page, it appears in the logs before the phishing page goes live. Pair this with newly registered domain feeds (opens in new tab) and filter them by brand keywords.
- Enforce email authentication. For corporate email, follow CISA's Cybersecurity Performance Goals and set SPF, DKIM, and DMARC to reject spoofed messages (opens in new tab). These controls stop spoofing of your own domain; a homograph domain, being a different domain, still authenticates as itself.
- Train against the visual channel. "Check the URL and the padlock" fails against characters the eye can struggle to distinguish, so phishing simulations (opens in new tab) should include IDN homograph scenarios that mirror how real attackers build them.
- Prepare removal paths. Report the domain to its sponsoring registrar and hosting provider, and use the UDRP process (opens in new tab) to transfer it within weeks; URS offers faster temporary suspension for clear-cut cases.
Homograph variants are cheap to register and re-register, so these controls hold only if detection and takedown run continuously, not domain by domain.
How Doppel helps
Doppel, the AI-native Social Engineering Defense (SED) (opens in new tab) platform that unifies Digital Risk Protection (DRP) (opens in new tab) and Human Risk Management (HRM) (opens in new tab), detects homograph domains and other lookalike threats across domains, social platforms, ads, app stores, messaging, dark web, telco, and crypto.
The Doppel Threat Graph links spoofed domains to fake social profiles (opens in new tab) and scam ads (opens in new tab). It also connects them to sending infrastructure (opens in new tab) to create a campaign-level view (opens in new tab). The platform's agentic AI (opens in new tab) correlates and prioritizes those signals, then executes takedowns at scale (opens in new tab) while analysts handle complex escalations.
A guided demo shows the Threat Graph mapping live lookalike infrastructure against your brand. Request a demo (opens in new tab) to get started.
Frequently asked questions about homograph attacks
What is a homograph attack?
A homograph attack is a spoofing technique in which an attacker substitutes characters that look identical to other characters, most often to create a domain name that can be difficult to distinguish visually from a trusted brand's domain. The classic substitution replaces the Latin letter "a" with the Cyrillic "а", which has a different Unicode code point but the same shape in most fonts. The forged domain resolves to a server the attacker controls and can host a credential-harvesting page (opens in new tab). The same trick appears in email display names, usernames, software package names, and file names.
What is the difference between a homograph attack and typosquatting?
Typosquatting attacks (opens in new tab) register domains that exploit typing errors, such as transposed or omitted letters, and those domains look wrong when read carefully. A homograph attack registers a domain that can closely resemble the target, so it can deceive users who inspect the address bar closely, even after copying and pasting the URL. Visually similar ASCII pairs such as "l" and "I" or "0" and "O" also constitute homograph domain spoofing under ICANN's description. Homograph domains can defeat the "look before you click" advice that works against typos.
What is an example of a real-world homograph attack?
In 2017, a researcher registered an all-Cyrillic domain that rendered as apple.com in Chrome and Firefox, served over HTTPS (opens in new tab) with a padlock. Real campaigns have followed the same playbook, including an August 2025 campaign (opens in new tab) against Booking.com customers that abused the Japanese hiragana character "ん", which resembles a forward slash in some fonts. Software repositories are targets too, where look-alike package names (opens in new tab) can impersonate legitimate dependencies.
Does HTTPS protect against homograph attacks?
No. A TLS certificate and the padlock icon confirm only that TLS encrypts the connection to a domain. Certificate authorities validate domain control (opens in new tab), so attackers can obtain valid certificates for homograph domains and present a padlock alongside the spoofed address. Multi-factor authentication narrows the damage but has limits of its own, because a real-time phishing proxy (opens in new tab) can relay a one-time code to the legitimate site the moment the victim enters it. For stronger protection, use phishing-resistant authentication (opens in new tab), such as hardware security keys.