New Homoglyph Tricks Let Cybercriminals Mimic Trusted Domains

New homoglyph attack techniques are turning tiny visual differences in text into a reliable way to spoof trusted domains, steal credentials, and bypass weak Unicode handling in security stacks.

By abusing Internationalized Domain Names (IDNs), Punycode, and Unicode “confusables,” attackers can register domains that look legitimate in the browser bar while resolving to attacker‑controlled infrastructure.

A classic example is Latin “a” (U+0061) vs Cyrillic “а” (U+0430), or Latin “o” (U+006F) vs Greek omicron “ο” (U+03BF); in most fonts, users cannot distinguish them at a glance.

When these characters are swapped into domains, filenames, or display names, humans and sometimes filters that do not normalize Unicode interpret them as the original brand.

In the DNS world, these strings are encoded using Punycode, so a deceptive Unicode domain like one containing Cyrillic “а” is stored as an ASCII xn‑‑label but usually rendered back to Unicode by browsers.

According to the report, Homoglyph attacks rely on characters that look almost identical but have different Unicode code points, often from different scripts such as Latin, Cyrillic, Greek, or Armenian.

Modern browsers apply heuristics (for example, script checks and TLD policies) to decide when to show Unicode vs Punycode, but homograph attacks remain viable in many locales and edge cases.

New Homoglyph Tricks

Attackers now automate the generation of confusable variants of high‑value brands, then bulk‑register IDNs that pass registrar checks and automatically obtain free TLS certificates from services like Let’s Encrypt.

These lookalike domains are used in spear‑phishing campaigns, fake login portals, malware download sites, and brand‑impersonation links embedded in ads or chat messages.

Beyond domains, homoglyphs appear in package names, repositories, and usernames, confusing developers and users into trusting malicious code or fake corporate accounts.

On the technical side, adversaries take advantage of Unicode normalization quirks (NFC/NFKC), confusable character mappings from the Unicode Consortium, and even bidirectional override controls to manipulate how text is rendered versus how it is stored.

This means that naive string comparisons, allowlists based on visible labels, or logging pipelines that do not normalize inputs may all miss that “trusted” names actually contain foreign characters.

Homoglyph domains appear heavily in credential‑harvesting and financial fraud, where phishing emails or messages link to a login page that looks indistinguishable from a real banking or SaaS portal.

In business email compromise, attackers combine a deceptive display name with a subtly altered domain so that busy employees approve payments or share sensitive data without inspecting headers.

Fake download portals and update sites on homoglyph domains push malware that escapes reputation‑based blocking simply because the domain is freshly registered.

These techniques map cleanly to multiple MITRE ATT&CK techniques: spearphishing links for initial access (T1566.002), open‑source reconnaissance on brands and infrastructure (T1593), domain acquisition for malicious infrastructure (T1583.001), and masquerading and deceptive naming for defence evasion (T1036).

Once credentials are stolen, attackers move into credential‑access techniques and onward to fraud or data‑encryption impact, using homoglyph infrastructure as the first hop.

Why defences still fail

Many organisations still treat Unicode as an edge case, so email gateways and web proxies may not normalize or flag mixed‑script domains, allowing homograph URLs through.

Certificate‑based checks can be misleading because modern PKI does not distinguish between legitimate and deceptive domains; as long as domain control is proven, a padlock is issued.

Even where browsers show Punycode for suspicious IDNs, users are accustomed to trusting visual cues and rarely understand xn‑‑labels or subtle script differences.

Security pipelines often log and correlate based on raw strings, not normalized or “de‑homoglyphized” forms, which breaks detection of related campaigns using slight confusable variations.

Mixed‑script detection and confusables checks exist as libraries and tools, but they are rarely integrated into SIEM rules, URL rewriting layers, or SSO security controls by default.

Robust homoglyph defence starts with policy: forbid official use of mixed‑script IDNs, and proactively register key lookalike domains for critical brands to reduce available attack surface.

At the technical layer, email and web security should normalize Unicode, highlight or rewrite suspicious IDNs into their Punycode form, and treat xn‑‑domains or mixed‑script labels as high‑risk until reviewed.

DNS security should track newly registered lookalike domains, while certificate‑transparency monitoring can alert when TLS certs are issued for suspicious variants of corporate brands.

Specialised security solutions, including modern endpoint and gateway products from vendors such as Quick Heal / Seqrite, increasingly incorporate URL reputation, IDN awareness, and phishing detection that looks beyond simple string matching to catch deceptive domains at click time.

Organisations should also add homoglyph‑aware phishing simulations, clear user training, and strong multi‑factor authentication so that a single mistaken click does not directly translate into account takeover.

Combined with confusable‑character hunting in logs and strict verification for financial actions, these layered controls significantly raise the operational cost of homoglyph‑based spoofing.

Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.