What Is a Punycode Attack?

What Is a Punycode Attack?

A punycode attack is the registration of a domain built from Unicode characters that look identical to a trusted brand's domain but carry different code points, so a browser renders the lookalike as the genuine name while resolving it to an attacker's server.

It abuses a legitimate standard: Punycode converts a Unicode domain label into the ASCII string DNS can store under RFC 3492 (opens in new tab), so the mechanism that lets münchen.com exist as xn--mnchen-3ya.com also lets an attacker register a Cyrillic twin of a Latin brand.

How a Punycode attack works

This is also called an IDN homograph attack. A homoglyph is a lookalike character, while a homograph attack uses a string of them for deception. An internationalized domain name has two forms: the U-label, the Unicode string a user reads, and the A-label, its ASCII encoding, which begins with xn-- and which DNS actually resolves (opens in new tab).

Punycode builds the A-label by passing ASCII characters through unchanged and encoding the rest as base-36 integers after a hyphen delimiter. Browsers, email clients, and messaging apps then each decide, by their own policy, which label to show the user.

The attack lives in that display decision. An attacker selects characters from a non-Latin script whose glyphs match Latin letters, registers the resulting label, and obtains a TLS certificate for it. Where the rendering policy is permissive, the user sees the brand's name; where it is strict, the user sees the xn-- string and the deception collapses.

Researcher Xudong Zheng published a demonstration in April 2017. He registered xn--80ak6aa92e.com, which decodes to аррӏе.com, using Cyrillic а (U+0430), р (U+0440), and ӏ (U+04C1) in place of Latin a, p, and l.

Because all characters were Cyrillic, the label passed the mixed-script checks browsers had relied on since 2005: Chrome 57 and Firefox both displayed it as apple.com, and the page loaded over HTTPS with a padlock, completing the illusion.

Why Punycode attacks are hard to stop

A whole-script confusable uses one non-Latin script to mimic Latin and can bypass same-script registration rules and permissive display policies. Registration policy blocks the wrong thing. Current rules require the code points in a label to come from one script under ICANN's IDN Implementation Guidelines (opens in new tab), fully in effect since April 30, 2025; that rule stops mixed-script registrations but permits a label that uses only Cyrillic.

Registries can choose whether to apply Unicode Technical Standard #39 confusable detection. Whole-script confusables stay visible in Firefox because its display design permits (opens in new tab) them, a gap Mozilla assigns to registries to close.

Chrome instead flags a whole-script confusable when its TLD has no association with that script, which catches Cyrillic labels on non-Cyrillic TLDs (opens in new tab).

Browser hardening also stops at the address bar. Email clients that support IDNs show homograph domains in Unicode in the sender address, including domains browsers already block (opens in new tab). In Outlook, Word, Excel, OneNote, and PowerPoint, users see the international name (opens in new tab) rather than the Punycode form.

Depending on the client, SMS messages, PDF hyperlinks, QR codes, chat-app link previews, and truncating mobile screens can present the lookalike without exposing an xn-- fallback. A certificate authority validates control of the registered domain, and the attacker genuinely controls it, so the padlock still appears (opens in new tab) as it does on the real site.

Types of Punycode attacks

Punycode attacks differ in which characters the attacker substitutes and which channel delivers the lookalike.

• Whole-script confusables. Attackers draw the letters from a single non-Latin script, most often Cyrillic, so the label satisfies same-script registration rules and mixed-script browser checks. Attackers can compose a word like "scope" entirely of Cyrillic letters (opens in new tab) that closely match the Latin spelling.
• Diacritic and extended-Latin substitutions. Characters such as ḅ or į sit close enough to their base letters to pass on a small screen. In 2017 (opens in new tab), adoḅe.com delivered the Betabot trojan, and in 2020 Verisign changed its .com and .net rules after researchers showed attackers could register Latin IPA Extension characters as brand lookalikes.
• Ad-delivered homograph domains. The attacker places the Punycode domain behind a Google Ad whose display URL shows the legitimate domain, then serves a trojanized installer to searchers who click.

How to defend against Punycode attacks

Effective defense layers display, detection, registration, and enforcement controls, because each one covers a gap the others leave open.

• Force Punycode display in managed browsers. Set network.IDN_show_punycode to true in managed Firefox deployments (opens in new tab) because "IDNs displayed in Punycode are easier to identify". Chrome and Edge apply the Chromium spoof-check algorithm by default, and admins can tune its lookalike warnings through enterprise policy (opens in new tab).
• Monitor Certificate Transparency and DNS logs for xn--. A certificate for an IDN must carry the xn-- form in its common name and SAN entries, so CT logs expose a homograph domain within seconds (opens in new tab) of TLS issuance. Grep resolver logs for xn--, decode the labels (opens in new tab) in Python, and match candidates against your brand list, since legitimate non-Latin domains carry the same prefix.
• Turn on email impersonation protection. Microsoft Defender for Office 365 supports domain impersonation protection, but admins must enable it: the default anti-phishing policy (opens in new tab) does not turn it on.
• Register high-risk variants defensively. Prioritize Cyrillic and Greek lookalikes of the primary brand domain and keep renewing them. The confusable character space across scripts and TLDs is too large to cover in full, so treat this as risk prioritization.
• Use the fastest enforcement path first. Under the 2013 Registrar Accreditation Agreement (opens in new tab), registrars must monitor an abuse contact continuously and review well-founded reports within 24 hours; the 2024 global amendment (opens in new tab), effective April 5, 2024, added a duty to disrupt well-evidenced DNS abuse. UDRP and URS follow, and the domain lock both impose is the useful step while a campaign is live, since non-Latin and accented characters (opens in new tab) establish confusing similarity under WIPO Overview 3.0.
• Teach xn-- as an indicator, within limits. Employees should hover over links and read the full sender address (opens in new tab), though training and simulations do not cover the full range of attempts (opens in new tab).

How Doppel helps

Doppel is the Frontier AI Social Engineering Defense (SED) platform that unifies Digital Risk Protection (DRP) and Human Risk Management (HRM). It runs these detection and enforcement controls continuously and dismantles homograph infrastructure across domains, certificates, ads, social, and messaging to stop rendered lookalikes before they reach the people they target.

Brand Protection, the DRP product on the SED platform, detects lookalikes across domain registrations, certificate logs, paid ads, social profiles, and app stores. It identifies xn-- variants that browsers, email clients, and mobile apps still render as the genuine name, then dismantles the infrastructure behind confirmed threats.

The Doppel Threat Graph connects the homograph domain, the certificate behind it, and the ad or message that delivers it into one campaign view, along with any infrastructure the same operator reused. Doppel's agentic AI correlates and prioritizes these signals, then executes automated takedowns against registrars, hosts, and ad networks at scale, so your analysts spend their time on the complex escalations that need human judgment.

Request a demo to see the platform against live impersonation infrastructure targeting your brand.

Frequently asked questions about the Punycode attack

What is a Punycode attack?

A punycode attack registers a domain that uses Unicode characters from a non-Latin script to look identical to a trusted brand's domain, then uses it to capture credentials, deliver malware, or drain funds from people who believe they are on the real site. Punycode itself is the Request for Comments (RFC) 3492 encoding standard that stores such Unicode names in the Domain Name System (DNS) as ASCII strings (opens in new tab) beginning with xn--, which many browsers, email clients, and messaging apps still render as the deceptive Unicode form. The technique is also called an internationalized domain name (IDN) homograph attack.

What is the difference between a Punycode attack and typosquatting?

Typosquatting attacks register a domain with a common spelling or keyboard error, such as gooogle.com, and succeed when the user mistypes the address. A punycode attack registers a domain that reads correctly to the human eye, so it fools users who click a link or copy and paste a URL exactly. The two techniques fail different defenses, too. Browser IDN display policies can expose a punycode domain by showing its xn-- form; typosquatted domains use pure ASCII, so that rule doesn't reach them, which is why enterprise brand-protection programs run separate detection logic for each.

What is an example of a Punycode attack?

The lookalike bįtpay.com swaps į for Latin i to spoof bitpay.com, and DNS records represent it as xn--btpay-b4a.com in 2025 abuse measurement (opens in new tab) data. A credential-capture page on that domain holds a valid TLS certificate because the attacker legitimately controls it. Attackers also place lookalike domains behind paid search ads (opens in new tab) whose display URL shows the real brand, putting a sponsored result above the genuine site.