Unicode Phishing: Attackers Exploit New Characters for Deceptive Domains

Key Takeaways

• Cybersecurity researchers have identified new techniques for creating deceptive domains that exploit Unicode characters to mimic legitimate brands within Chromium-based browsers.
• These “homograph attacks” bypass existing browser protections, displaying fake domains like “аррӏө[.]com” (a Cyrillic variant of “apple[.]com”) in their readable Unicode form instead of the expected Punycode.
• The vulnerability stems from gaps in Chromium’s script comparison rules and skeleton matching, particularly with less common Cyrillic characters.
• The risk extends beyond web browsing to email, where services like Gmail Web may display these deceptive sender domains in Unicode, potentially bypassing user awareness.
• Users must exercise extreme caution, verify domains through trusted methods, and leverage security tools like password managers, as visual inspection of the address bar is no longer sufficient.

New Unicode Vulnerabilities Create Sophisticated Phishing Pathways

Security researchers have uncovered novel methods for crafting fraudulent domains that appear virtually identical to established brands within Chromium-based web browsers. This sophisticated technique leverages specific Unicode characters, allowing phishing pages to masquerade as legitimate sites without triggering visible browser warnings, thereby deceiving users who rely on visual cues in the address bar.

Exploiting Internationalized Domain Names (IDNs)

The research, conducted by Ian Muscat and Leanne Briffa from Have I Been Squatted, focused on how internationalized domain names (IDNs) are rendered by Chromium’s display algorithms. Their proof-of-concept demonstrated an effective spoof, “аррӏө[.]com,” which is a Cyrillic rendition of “apple[.]com.”

During testing, Chrome 154 displayed this deceptive domain in its Unicode form, rather than converting it to its Punycode equivalent, “xn--80a6aa68c8d[.]com.” It is important to note that these domains were registered solely for controlled research purposes and were not part of any active phishing campaigns.

The Mechanics of Unicode Phishing

Originally, the Domain Name System (DNS) was limited to English letters, numbers, and hyphens. The introduction of IDNs expanded this to include characters from numerous global languages. To remain compatible with DNS, Unicode names are converted into ASCII via Punycode, identifiable by labels beginning with “xn--.” While this enables a truly global internet, it also introduces the risk of homograph or homoglyph attacks, where characters from different scripts bear a striking visual resemblance.

Chromium browsers incorporate various mechanisms to counteract such deception, including checks for mixed scripts, unsafe symbols, whole-script comparisons, and a normalized form known as a “skeleton.” These protective measures draw inspiration from the Unicode Technical Standard 39.

Bypassing Chromium’s Homoglyph Defenses

Following a prominent “аррӏе[.]com” attack in 2017, Chrome implemented a whole-script confusable check. This enhancement successfully identifies domains using only Cyrillic letters that mimic Latin script, displaying them as Punycode (e.g., “xn--80ak6aa92e[.]com”).

However, the new research reveals a critical flaw: this rule activates only when every Cyrillic character in a label is explicitly listed on Chromium’s lookalike inventory. The Cyrillic letter ‘ө’ (used in languages such as Kazakh and Mongolian), though permitted, is absent from this specific list. Substituting the final Cyrillic ‘е’ with ‘ө’ in “аррӏө[.]com” effectively bypasses the entire confusable check, despite the domain retaining its visual similarity to “apple[.]com.”

A second vulnerability lies within Chromium’s skeleton matching process. While many accents are removed during normalization for comparison, certain diacritics, like hooks or strokes, can persist. This means “oƙta[.]com” does not reduce to the same skeleton as “okta[.]com.” Similarly, the unique bar in ‘ө’ prevents “аррӏө[.]com” from matching the skeleton of “apple[.]com,” thereby evading detection.

The researchers registered 20 proof-of-concept domains, mimicking brands such as Apple, OpenAI, Skype, Pinterest, and Okta. Their testing also found that Chromium’s subsequent navigation warning failed to flag “аррӏө[.]com” because its skeleton was two edits away from Apple’s, exceeding the proximity threshold for that specific check.

Email Security Implications

The threat extends significantly to email communications. In tests involving 20 internationalized senders, Gmail Web consistently displayed all sender domains in their Unicode form. In contrast, Outlook Web rendered every sender as an encoded A-label. Gmail only showed the Punycode in the less prominent “mailed-by” field, which many users do not scrutinize. The study did not evaluate the effectiveness of spam filters, sender reputation systems, or link scanning technologies against these new methods.

It is crucial to understand that a valid SSL/TLS certificate merely confirms an encrypted connection to the domain specified in the certificate, not that the domain belongs to the brand it imitates. Attackers controlling a lookalike domain can also configure SPF, DKIM, and DMARC records correctly, rendering email authentication alone insufficient to verify sender legitimacy.

A review of .com domains in October 2026 revealed over 167 million delegated names, including 733,509 IDNs in Punycode. Researchers identified 161,894 visual lookalike pairs affecting 133,953 ASCII domains. While these statistics do not inherently indicate malicious intent—some may be defensive registrations, legitimate multilingual sites, or unrelated entities—they highlight the scale of potential confusion.

What You Should Do

• Organizations: Proactively monitor newly registered Punycode (xn--) domains that visually resemble your brand. Regularly review certificate records for suspicious entries. Implement and configure advanced impersonation protection within mail gateways to flag or block deceptive senders. Consider defensive registration of common homoglyph variants of your brand.
• Users: Never click on links in unexpected emails or messages to log in. Always navigate to sensitive websites by typing the known address directly into the browser or using a saved bookmark. Leverage password managers and passkeys, as these tools authenticate against the real domain and will not auto-fill credentials or respond on lookalike sites. While browser updates are vital, this research underscores that a quick glance at the address bar is no longer a reliable sole defense.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.