Two Letters Are All It Takes to Fool Chrome - Why Lookalike Domains Still Slip Past Browser Security

Researchers Ian Muscat and Leanne Briffa of Have I Been Squatted have found that two obscure characters can slip fraudulent lookalike domains past the URL–spoofing defences built into Chromium–based browsers such as Chrome and Edge. The characters are the Cyrillic barred o (ө, Unicode U+04E9), used in Kazakh, Mongolian and Tatar, and the Latin k with hook (ƙ, U+0199), used in Hausa and Karai–karai. Using them, the researchers registered 20 convincing imitation domains — including one impersonating Okta with the ordinary “k” swapped for the hooked one, and one impersonating Apple using the barred o — which Chromium displays exactly as written rather than converting to the tell–tale Punycode form that would expose them as fake.

The detail that matters most for a UK business is not in the headline. Chromium’s strongest lookalike check compares domains against a hardcoded list of roughly 8,500 popular websites. The new bypass lets attackers slip past that list for big brands. But the overwhelming majority of UK businesses were never on it in the first place — which means the protection this research defeats was never protecting their domain at all. A convincing imitation of a regional accountancy practice, a solicitor or an online retailer did not need a newly discovered character to get past the check. The lesson is not that browsers have a new hole. It is that the visual appearance of a URL was never a reliable test of who you are dealing with, and that any security process which depends on a person spotting a fake address is depending on something browsers themselves cannot guarantee.

How Chromium tries to catch lookalike domains, and how this gets past

Internationalised domain names allow web addresses to contain characters from scripts beyond basic Latin, which is essential for a global web. It also creates an obvious opportunity: many characters in other scripts look identical, or nearly so, to familiar Latin letters. Browsers deal with this by deciding, domain by domain, whether to display the Unicode form as written or to fall back to Punycode — the encoded form beginning “xn--” that looks obviously machine–generated and immediately signals that something is unusual.

Chromium makes that decision using two main defences. The first, a check called SafeToDisplayAsUnicode, flags domains made entirely of known lookalike Cyrillic characters — the classic trick of spelling a familiar name using Cyrillic letters that happen to resemble Latin ones. The second, GetSimilarTopDomain, strips accents and marks from a domain to produce a simplified “skeleton”, and compares that skeleton against a hardcoded list of roughly 8,500 popular websites. If the skeleton matches a well–known site but the actual domain does not, the browser treats it as suspicious.

The researchers found that both checks fail against the two characters they identified. Neither character is on Chromium’s hardcoded list of known lookalikes, so the first check does not catch them. And both retain their distinguishing marks when accents are stripped — the bar through the o and the hook on the k survive the simplification — so the skeleton of the fake domain does not match the genuine site it is impersonating, and the second check does not catch them either. The result is a domain that looks, in the address bar, exactly like the real one to a casual glance, and which the browser displays without complaint.

There is a third layer. Chromium also shows Safety Tip warning pop–ups for domains that are a very close match to a genuine site — one character different, or two adjacent characters swapped. According to the researchers, those warnings do not trigger when two or more characters differ, which is the case for the newly discovered bypass domains. So all three layers of visual protection can be passed by the same domain.

This is not a new class of problem. Chrome has fixed similar bypasses before: Chrome 148 closed off two previously abused characters. The researchers’ point is that new “breaker” characters not yet on Chromium’s hardcoded list keep being found and exploited, and that this is a structural consequence of browsers adding support for more of the world’s scripts and languages. A defence built on a list of known–bad characters is always one discovery behind. At the time of disclosure, this specific abuse chain had not been publicly confirmed as fixed in a stable Chromium release.

How this class of flaw keeps recurring

The sequence below follows the research and the pattern it describes. Most stages are not tied to a published date, and the entries say so rather than inventing one.

The recurring shape is what matters. A defence that works by listing known–bad characters will be bypassed by the next character nobody has listed yet, and the supply of such characters grows as browsers support more languages. That is not a criticism of Chromium’s engineers, who are dealing with a genuinely hard problem: refuse to display legitimate non–Latin domains properly and you break the web for a large share of the world. It is a reason for businesses to stop treating the address bar as a security control.

Which controls actually stop a lookalike–domain phish

The chart below is an indicative planning model — not measured data — ranking common controls by how well they protect a business against credential phishing that uses a lookalike domain the browser displays as genuine.

The top two rows share a property that explains their position: they do not look at the domain the way a person does. A passkey or hardware security key is bound cryptographically to the genuine site, so it simply will not authenticate to a lookalike, however convincing it appears. A password manager compares the exact domain against the one the password was saved for, so it does not offer to fill on an imitation — and that refusal is itself the most useful warning a user can get. Both work regardless of which character an attacker used, which is exactly the property a list–based defence lacks.

The sixth row is placed where it is not because training is worthless — it remains essential for the many phishing attempts that are visibly wrong — but because, against this specific technique, there may be nothing on screen for a trained eye to catch. The appropriate role for training here is different: teaching staff that if their password manager does not offer to fill a login form it normally would, that is a reason to stop, not to type the password manually.

Three layers of visual protection, one domain past all of them

Count the browser’s visual defences against lookalike domains, and how many the new technique gets past.

Three independent layers sounds robust, and in most cases it is. The weakness is that all three share an assumption: that the browser can tell from the characters in a domain whether it is trying to imitate something. When an attacker finds characters the browser does not yet recognise as imitations, every layer that relies on that recognition fails together. It is the same lesson this series has returned to repeatedly about fallbacks: several controls that share a failure mode amount to one control with several names.

There is a second, less obvious point in the 8,500–site list. GetSimilarTopDomain protects popular websites — banks, major brands, large platforms — by comparing lookalikes against them. That is a sensible design, because those are the sites most often imitated. But it means the skeleton check has never applied to the vast majority of UK businesses, whose domains are not popular enough to be on the list. An attacker imitating a mid–sized accountancy firm, a regional builder’s merchant or a specialist online shop does not need a newly discovered breaker character; ordinary lookalike techniques were never subject to that comparison. For most businesses, the news is not that a protection has failed. It is a reminder that the protection was never theirs.

That reframes who should care. Large organisations should care because a defence they relied on has a gap. Small and medium businesses should care because their customers and suppliers can be targeted by imitations of their domain with very little browser resistance, and because their staff can be phished by imitations of the larger services they log in to — Microsoft, Google, banking portals, payroll systems — which is where this specific bypass bites.

Where UK businesses are exposed

The rows below reflect where lookalike–domain risk typically sits in a UK SME, with badges indicating how much attention each usually needs. They cover both directions: your staff being phished, and your customers being phished in your name.

The second row needs a word of explanation, because it surprises people who have already rolled out multi–factor authentication. One–time codes and simple push approvals are a real improvement over passwords alone, but a convincing fake site can sit in the middle: it collects the password, asks for the code, and passes both straight to the genuine service in real time. The user sees a normal login. That is why the controls at the top of the bar chart — passkeys and hardware keys — are categorically stronger rather than incrementally so. They will not complete authentication to a domain that is not the real one, however it is displayed.

The seventh row is where lookalike domains most often turn into money lost. A supplier’s domain imitated with a near–identical address, an email saying bank details have changed, and an invoice paid to the wrong account. Email authentication standards protect your own domain from being forged directly, but they do nothing about a different domain that merely looks like yours. The defence is procedural: confirm any change to payment details by phoning a number you already hold, never one given in the email requesting the change.

What reducing this exposure costs

The bands below are indicative planning figures for UK businesses reducing their exposure to lookalike–domain attacks — not quotes.

The pattern across the table is that the most effective controls are among the cheapest. A password manager and passkeys cost little and defeat lookalike domains of every kind, including ones based on characters nobody has discovered yet. The more expensive items — monitoring, filtering, takedown — are valuable for businesses whose own brand is likely to be imitated, but they are additions to those foundations rather than substitutes for them.

Two ways to defend against convincing fakes

The right–hand column is built around one idea: remove the human eye from the point of decision. That is not a criticism of staff, who are being asked to do something browsers themselves cannot reliably do. It is a recognition that the security of a login should not depend on whether a person can distinguish a barred o from an ordinary one at a glance. Every item on the right either works without that judgement or makes the judgement unnecessary.

Why the address bar was never the right control

This research fits a long pattern. Lookalike domains have been a phishing staple for as long as there has been phishing, and every generation of defence has been built around making fakes easier to spot: browser warnings, Punycode fallbacks, colour cues, training. Each helps against the bulk of attempts. None closes the gap entirely, because the underlying task — deciding from appearance alone whether two strings represent the same organisation — is one that neither people nor list–based software can do perfectly when an attacker is actively looking for the cases they miss.

The durable answers move the decision somewhere appearance does not matter. Passkeys and hardware security keys bind authentication to the genuine domain cryptographically. Password managers match exact strings rather than visual similarity. Filtering services evaluate domains by registration age, reputation and history. Payment processes verify through a separate channel. These are not new ideas; what this research adds is a fresh, concrete reason to prioritise them over further rounds of “check before you click”.

For businesses that run their own websites, there is a second perspective. Your customers face the same problem when an attacker imitates your domain to collect their details or redirect their payments, and as noted above, your domain is almost certainly not on the list of popular sites the browser protects. Monitoring for lookalike registrations, registering the most obvious variants defensively, and giving customers guidance that does not rely solely on checking the address are reasonable steps for any business whose name customers trust with money or personal data. The recent ASOS incident showed how quickly impersonation follows a moment of public attention.

For organisations pursuing Cyber Essentials, the most relevant connection is the scheme’s emphasis on multi–factor authentication for cloud services. Phishing–resistant forms of multi–factor authentication are the strongest available answer to this class of attack, and moving the accounts that matter most onto passkeys or security keys is a sensible next step beyond the baseline. It is worth raising with whoever manages your identity platform, because many already support it and simply have not had it switched on.

The story at a glance

This story connects to several we have covered recently. The ASOS push–notification breach is the clearest current example of how impersonation follows a moment of public attention, and why customers cannot be expected to tell genuine messages from fake ones. The BT email password reset flood showed what happens when the signals people rely on to spot an attack are buried or made indistinguishable from the real thing. Ofcom’s investigations into VoIP number misuse cover the same impersonation problem in telephony, where a familiar caller display is no proof of who is calling. Our piece on the end of security through obscurity makes the general argument that list–based defences are always one discovery behind. The NCSC advisory on Integrity Tech describes automated scanning that finds weaknesses faster than lists can be updated. And the Supreme Court hearing on trivial data protection claims is a reminder of the cost when personal data ends up in the wrong place, however it gets there.

Frequently asked questions

Cloudswitched

London-based managed IT services provider offering support, cloud solutions and cybersecurity for SMEs.