In April 2017, a security researcher registered a domain that Chrome, Firefox, and Opera all displayed as apple.com — padlock, valid certificate, and all. It wasn’t apple.com. Every character in it was Cyrillic. You could stare at the address bar as long as you wanted and never see the difference, because there wasn’t one to see.

That’s the whole trick behind a homograph attack: it doesn’t fool a filter, it fools your eyes.

TL;DR

  • Homograph (or IDN homograph) attacks register domains using Unicode characters from other scripts — Cyrillic, Greek, and others — that render visually identical to Latin letters in trusted brand names.
  • The technique is old (first demonstrated in 2005) and still works in 2026 in specific gaps left by browser and email-security defenses.
  • Punycode is the ASCII-safe encoding (xn--...) that makes these Unicode domains possible in the first place — and also the tell that gives them away, if you know to look.
  • Attackers now combine homograph substitution across the sender name, subject line, and body of an email, not just the domain, specifically to dodge automated text-matching filters.
  • You can’t out-eyeball this one. Detection has to be systematic — browser policy, email gateway rules, and domain monitoring — not “look carefully.”

Why This Matters to You

If your job involves anything security-adjacent — SOC analyst, IT admin, or just someone who reads a lot of email — you will eventually be shown a URL and asked “is this real?” A homograph domain is the one case where looking harder doesn’t help, because the visual rendering is designed to be indistinguishable from the real thing. Knowing the mechanism means you know where to actually look instead: the raw encoding, not the rendered text.

Table of Contents

What a Homograph Attack Actually Is

A homograph is a character that looks the same as another character but isn’t the same character. “Homograph attack” (also called an IDN homograph attack, homoglyph attack, or script spoofing) means registering a domain name built from characters that look like the letters in a trusted brand’s domain, but come from a different script.

The classic example: the Latin letter “a” (Unicode U+0061) and the Cyrillic letter “а” (Unicode U+0430) render identically in nearly every font. They are, as far as a computer is concerned, completely different characters. As far as your eyes are concerned, they’re the same shape.

Swap enough Latin letters in a brand’s domain for their Cyrillic, Greek, or other-script lookalikes, register the result, and you have a domain that a browser can display as paypal.com or apple.com while actually pointing somewhere else entirely.

This only works because of a feature called IDN (Internationalized Domain Names) — the standard that lets domain names contain non-ASCII characters at all, so that a business in Tokyo or Moscow can register a domain in its own script instead of being forced into Latin letters. It’s a legitimate and necessary feature. Homograph attacks are what happens when that legitimate feature meets a threat model nobody accounted for at first: what if the non-Latin characters aren’t there to spell a different word, but to impersonate one?

Punycode: The Encoding That Makes This Possible

The domain name system (DNS) was built in the 1980s around plain ASCII. It has no native concept of Cyrillic, Greek, Chinese, or Arabic characters. To support IDNs without rebuilding DNS, engineers created Punycode — an encoding that represents any Unicode string using only the ASCII characters DNS already understands (letters, digits, and hyphens).

A Unicode domain like аpple.com (with that Cyrillic “а”) gets encoded into a Punycode form starting with the prefix xn--, for example xn--pple-43d.com. That xn-- string is what actually gets registered and stored in DNS. It’s ugly, but it’s unambiguous — there’s no lookalike-character trick possible in a string made entirely of ASCII digits and lowercase letters.

The vulnerability isn’t in Punycode itself. It’s in the decision browsers make about whether to show you the Punycode or show you the pretty decoded Unicode version. Show the Unicode, and a well-built homograph domain is invisible. Show the Punycode, and the xn-- prefix is an instant red flag to anyone who knows to look for it — though most people don’t.

A Short History: From ShmooCon to аpple.com

This isn’t a new problem. It has been demonstrated, disclosed, and partially fixed, more than once, over two decades — which is itself worth understanding, because it explains why the fixes are incomplete rather than absent.

February 2005 — Security researcher Eric Johanson of the Shmoo Group demonstrated a working homograph attack at the ShmooCon hacker conference, spoofing PayPal’s domain using a Cyrillic “a” that Firefox 1.0, Safari 1.2.5, and Opera 7.54 all rendered as the genuine paypal.com. ICANN issued a public statement within days, and Mozilla shipped a fix that restricted which top-level domains would even attempt to display Unicode at all — a coarse but effective stopgap at the time.

April 2017 — Researcher Xudong Zheng showed the fix from 2005 hadn’t closed the gap for domains where every character comes from the same non-Latin script. He registered xn--80ak6aa92e.com, which decoded to аррӏе.com — Cyrillic “а,” “р,” and “ӏ” characters standing in for the Latin “a,” “p,” and “l” in “apple.” Because every character in the label was consistently Cyrillic (a “whole-script” match rather than a mix of scripts), it slipped past the mixed-script detection Firefox and Chrome had relied on since 2005. He reported it to both vendors on January 20, 2017. Chrome shipped a fix — whole-script confusable detection — in Chrome 58 that March. Firefox’s developers initially declined to fix it on the browser side at all, arguing it was primarily the responsibility of domain registrars and owners to prevent this kind of registration. Safari and Internet Explorer were not affected by this particular bypass.

The pattern across both incidents is the same: a defense gets built against the specific technique demonstrated, and a few years later someone finds the edge case the defense didn’t cover.

How Browsers Try to Stop This Today

Modern Chromium (and by extension Chrome, Edge, and Brave) runs every candidate domain through a multi-step spoof-check before deciding whether to render it as Unicode or fall back to the raw xn-- Punycode string. In broad strokes, the checks include:

  • Mixed-script detection — a label combining, say, Latin and Cyrillic characters is shown as Punycode.
  • Whole-script confusable detection — the fix for exactly the 2017 bypass: a label that’s entirely one non-Latin script but visually resembles a Latin word gets flagged too, unless the top-level domain is one where that script is expected (a .ru domain in Cyrillic isn’t suspicious; a .com domain that’s entirely Cyrillic but spells an English brand name is).
  • Skeleton matching against popular domains — Chrome maintains a precomputed list of the skeletons (a normalized, diacritic-stripped form) of the web’s most-visited domains, and checks candidate IDN labels against it using the Unicode Consortium’s confusable-character mappings (Unicode Technical Report #39).
  • Digit-spoofing and invisible-character checks — catching tricks like characters that look like digits, or the use of invisible/formatting characters within a label.

If a domain fails any of these checks, the browser shows you the Punycode xn--... string instead of the pretty Unicode rendering. That’s the browser’s way of saying “I don’t trust this enough to decode it for you.”

Firefox has converged on broadly similar protections over time, and both engines periodically expand their confusable-character lists and TLD rules as new bypass techniques surface — the same reactive pattern that’s defined this problem since 2005.

Where the Gaps Still Are in 2026

None of this makes homograph domains extinct. A few structural reasons why:

  1. The checks are heuristic, not exhaustive. Skeleton matching only protects domains on the precomputed popular-domains list. A regional bank, a smaller SaaS vendor, or an internal corporate portal that isn’t on that list gets none of that protection — Chrome will happily render a homograph of a brand it’s never heard of.
  2. Email clients and other software don’t inherit browser protections. The confusable-detection logic lives in the browser’s URL-rendering code. A desktop mail client, a chat app, or a PDF viewer rendering a clickable link may apply no such policy at all, showing decoded Unicode with none of the spoof checks a modern browser runs.
  3. Attackers don’t need the domain alone to work. As covered below, homograph characters are now routinely spread across multiple parts of a message — not just the URL — specifically to route around defenses that only inspect the link.
  4. A valid TLS certificate is trivial to obtain. Certificate authorities validate domain control, not brand intent — free automated issuance (Let’s Encrypt and similar services) will happily issue a certificate for a xn-- domain the same as any other, so the padlock icon tells a victim nothing about whether the domain is a homograph.

How Attackers Combine It With Other Tricks

Contemporary campaigns rarely rely on a spoofed domain in isolation. Palo Alto Networks’ Unit 42 documented a set of phishing campaigns in July 2025 that illustrate how far this has moved: homograph character substitution wasn’t just applied to the domain, but layered across the sender display name, the subject line, and the body text of the same email, using Cyrillic and Greek lookalikes throughout.

In the campaigns Unit 42 described, one message impersonated a document-signing platform with a display name and subject line built from homograph characters (rendering as something like “Confidential” and “Financial Statement” with individual letters swapped for lookalikes), routed through a legitimate-looking intermediate domain before landing on a credential-harvesting page protected by a custom CAPTCHA meant to block automated scanners. Another impersonated a well-known media-streaming brand, using a homograph sender address to claim a failed payment and push the victim toward a fake payment-update page.

The tactic behind spreading homograph characters across multiple fields, rather than just the URL, is straightforward: automated text-matching filters that look for exact brand-name strings (“PayPal,” “DocuSign,” “Spotify”) in the subject or sender name simply don’t match against a string where several letters have been swapped for Unicode lookalikes — to the filter, the “word” the filter is scanning for and the word actually present are byte-for-byte different, even though a human reads them as identical.

This is the same principle behind invisible-character attacks elsewhere in the stack — text that reads one way to a human and parses another way to software — applied specifically to the phishing lure itself.

Detecting Homograph Domains

The reliable detection method has nothing to do with looking harder at rendered text — it’s about getting at the underlying encoding, which can’t lie the way rendered Unicode can.

For individuals:

  • Don’t trust the rendered domain in an address bar or a link preview as ground truth. Inspect the hostname with a Punycode-aware URL or IDN tool that explicitly shows its ASCII form; ordinary copy and paste may preserve the Unicode rendering instead of revealing xn--.
  • Treat any xn-- prefix you encounter in a business context as worth a second look. It isn’t automatically malicious — plenty of legitimate non-English-script domains use it — but it’s never something you should see in a URL that’s supposed to be a familiar English-language brand.
  • Don’t rely on the padlock/certificate icon as a signal of legitimacy. It confirms encryption, not identity.
  • Navigate to sensitive sites (banking, email, payment providers) by typing the address yourself or using a saved bookmark, rather than clicking a link from an email or message.

For organizations:

  • Email security gateways should decode and flag xn-- domains in sender addresses and body links, and should apply confusable-character normalization to subject lines and display names before running brand-name/keyword matching — otherwise a homograph substitution defeats the filter for free.
  • Run proactive domain monitoring / brand-protection services that search for homograph and Punycode registrations of your own domains, so you find out about a lookalike registration before it’s weaponized against your customers or employees, not after.
  • Consider Punycode-aware detection rules in your SIEM or DNS logging — a spike in xn-- lookups against domains resembling your brand, or against known confusable patterns, is a legitimate hunting signal (this pairs naturally with the kind of URL and header inspection covered in our phishing email analysis walkthrough).
  • If you operate a brand that’s a common phishing target, consider registering the most obvious single-character homograph variants of your own domain defensively — the same practice used against ordinary typosquatting.

What You Can Do Today

  1. Before clicking an uncertain URL, inspect its hostname with a Punycode-aware tool that displays the ASCII form. If a familiar English-language brand unexpectedly resolves to an xn-- label, treat it as suspicious until independently verified.
  2. Bookmark the login pages for services you use often (banking, email, SSO providers) and use the bookmark, not a link from a message.
  3. If you manage email security, confirm your gateway actually decodes Punycode and normalizes confusable characters before keyword/brand matching runs — many default configurations don’t, which is precisely the gap the 2025 campaigns above were built to exploit.
  4. If you’re a defender responsible for a recognizable brand, ask whether your organization has any domain-monitoring or brand-protection coverage for homograph/Punycode registrations — if the answer is “we’d find out from a customer complaint,” that’s a gap worth closing.
  5. Treat a valid TLS certificate and a familiar-looking address bar as necessary but not sufficient signals of legitimacy — pair them with checking where a link actually leads before entering credentials.

Sources