GBHackers

Researchers Discover New Domain Spoofing Techniques That Bypass Chrome’s Phishing Protections


Researchers identified two edge cases involving internationalized domain names (IDNs) that bypass Unicode display safeguards and certain navigation warnings in Chromium.

Published on October 3, 2026, their research demonstrates how carefully selected Cyrillic and Latin characters can create convincing lookalikes of trusted domains without triggering these protections.

The researchers Ian Muscat and Leanne Briffa at Have I Been Squatted, registered 20 proof-of-concept domains, including аррӏө.com, which resembles apple.com, and oƙta.com, which resembles okta.com.

In Chrome 154, macOS displayed the Cyrillic lookalike of Apple (аррӏө.com) in Unicode on macOS with a valid certificate. The findings raise concerns about domain display and lookalike-detection controls, but do not demonstrate a bypass of all phishing-defense systems.

New Domain Spoofing Techniques

Chromium usually converts suspicious IDNs into Punycode, an ASCII representation that begins with xn--. Its first inspection stage, SafeToDisplayAsUnicode(), evaluates individual domain labels for prohibited characters, unsafe script combinations, and whole-script impersonation.

The whole-script confusable check was introduced after Xudong Zheng’s 2017 demonstration of аррӏе.com, an entirely Cyrillic domain resembling apple.com. Chromium blocks that spelling because every character falls under its Cyrillic lookalike list.

However, the rule operates on an all-or-nothing basis. By replacing the final Cyrillic е with ө (U+04E9), the outcome changes. Although ө is an allowed character, it is not included in the lookalike list, allowing the domain аррӏө.com to pass the checks. The researchers refer to such characters as “breakers.”

Other eligible breakers include ү and ї. However, successful impersonation also depends on the remaining characters and subsequent checks. Mixing ordinary Latin letters with Cyrillic usually fails Chromium’s earlier script-mixing inspection.

Chromium’s second stage, GetSimilarTopDomain(), compares normalized hostname “skeletons” against 8,462 bundled domains. Exact matches with another site force the display to switch to Punycode.

 Chrome blocks the page and asks whether the visitor meant apple.com (Source: haveibeensquatted)

The weakness lies in the order of transformations. Chromium strips diacritics before applying confusable mappings. Characters that include combining marks during the later mapping retain those marks in their final skeletons.

As a result, the character ƙ in oƙta.com becomes a Latin k followed by a combining mark, preventing an exact match with okta.com. Similarly, the character ө becomes “o” plus a combining bar.

Thus, the Apple lookalike differs from apple.com both by a substituted letter and by the addition of a mark, allowing it to escape the bundled-domain comparison.

Chromium evaluates lookalikes during navigation, using popular domains and sites with sufficient user engagement. However, its near-match checks have limitations that favor these examples.

The skeleton for аррӏө.com is two edits away from apple.com, exceeding the one-edit comparison. Moreover, Chromium skips near-match checks for target domains with fewer than five characters before the top-level domain, which excludes okta.com. Consequently, both examples loaded without lookalike warnings under the tested conditions.

These tests did not include reputation checks, remote allowlists, or redirects, so the results should not be interpreted as a universal evasion of phishing detection.

Email rendering creates another point of exposure. In tests involving 20 internationalized senders, Gmail displayed every domain in Unicode, while Outlook Web showed their encoded A-labels. Researchers imported messages into their own mailboxes, but they did not evaluate spam filtering, reputation, or link scanning.

The researchers from Have I Been Squatted recommend monitoring encoded IDN registrations that are within two edits of protected domains, enabling gateway impersonation controls, and applying IDN-aware DNS and proxy policies.

Additionally, phishing-resistant FIDO2 authentication or passkeys provide another layer of protection because credentials registered for a legitimate domain cannot authenticate a lookalike.

Update defenses against new malware as soon as it appears. Integrate TI Feeds with data from 16K SOCs.



Source link