A homoglyph attack works by replacing characters with lookalike symbols from another script, such as letters that appear identical in a domain, username, or file name. Attackers use it for phishing, impersonation, and deceptive links. Defenders should normalise text, block confusable registrations, and inspect mixed-script identifiers.
How homoglyph attacks turn lookalike text into trust abuse
The technique works because people and systems often treat visually similar characters as the same, even when they come from different scripts or Unicode ranges. That lets an attacker register a domain, create an account name, or name a file so it looks legitimate at a glance while pointing to something different underneath.
In practice, the attack succeeds when the target relies on visual recognition instead of strict normalisation and script-aware comparison. The deception can be used for credential capture, brand impersonation, malicious attachments, or quietly swapping an identifier inside a workflow where reviewers only skim the text.
A practical way to think about the mechanics is that the attacker is not “breaking” the character set, they are exploiting ambiguity in human review and inconsistent handling across browsers, mail clients, directory services, and file systems. A name may render as the expected brand or user while resolving to a different object, especially when mixed scripts, Unicode normalization, and punycode handling are not validated consistently.
Where homoglyph attacks are most effective
homoglyph attack are most effective anywhere a string is used as a trust signal. That includes domains, email display names, usernames, document titles, chat handles, package names, and file paths. The risk rises when the string is shown more often than it is parsed, because humans tend to trust the rendered form and miss the underlying encoding.
Phishing remains the most obvious use case, but the same technique also supports impersonation inside collaboration tools and supply-chain abuse through deceptive package or repository names. For a broader phishing context, see the Phishing Guide, which covers lookalike domains, brand impersonation, and layered defences. Attackers use this family of tricks to create a trusted first impression before the victim inspects the destination more closely.
Defensive controls need to account for how text is consumed, not just how it is stored. If a control only checks for exact ASCII matches, it may miss visually confusable characters; if it only checks the rendered label, it may miss the underlying code points. That mismatch is what gives the attack room to operate.
How to detect, block, and investigate confusable identifiers
Good defence starts with normalising identifiers before comparison and then comparing against a confusable-character policy, not just an exact-string rule. Registries and directories should reject mixed-script identifiers where they are unnecessary, reserve brand-critical names, and flag lookalike registrations for review. Security teams should also treat punycode, Unicode normalization, and display-name rendering as separate validation problems.
Investigation should focus on whether the suspicious string is merely deceptive or actually active in an attack path. Review the registration history, email routing, link target, file origin, and any authentication prompts that used the identifier. If the homoglyph was used in a message, page, or attachment, preserve the exact text as displayed and the raw encoded form, because both can matter during analysis.
When the deception is used in phishing or credential theft, the response often extends beyond takedown. If the lookalike asset captured credentials, sessions, or payment instructions, treat it as an identity-abuse event and verify whether the attacker reused the same naming pattern elsewhere. The State of NHI & AI Agent Breach Report 2026 is useful here because it shows how attackers chain credential theft, impersonation, and downstream abuse once trust has been established.
Risk and Threat Considerations
Homoglyph attacks are risky because they attack perception rather than protocol. The control gap is often between what a person believes they are approving and what the system actually processes, which makes the technique effective in phishing, impersonation, and deceptive registrations.
Failure mechanism: The attacker substitutes confusable characters, then relies on a weak review step, inconsistent Unicode handling, or display-layer truncation to make the malicious string look trustworthy.
Impact: Victims can be routed to attacker-controlled destinations, approve fraudulent actions, or accept a false identity as legitimate, which can lead to credential theft, message spoofing, or malicious file handling.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-10 — Human Use of NHI | Homoglyphs often enable impersonation and trust abuse via deceptive identifiers. |
| Recommendation — Scan identity surfaces for confusable names and block lookalike registrations before users can trust them. | ||
| CIS Controls v8 | CIS-5 — Account Management | Lookalike usernames and domains abuse naming and account trust controls. |
| Recommendation — Harden naming, approval, and review processes for externally visible accounts and identifiers. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Confusable-character handling depends on validating and normalising security-relevant text inputs. |
| Recommendation — Normalize and validate security-relevant text before comparing, storing, or displaying it. | ||
| OWASP ASVS | V1 — Encoding and Sanitization | Unicode confusables and mixed-script text are encoding and sanitization concerns in security-sensitive inputs. |
| Recommendation — Apply strict encoding and sanitization checks to identifiers that users can trust or act on. | ||
Practitioner Guidance
What to verify: Check both the rendered identifier and its underlying code points before trusting a domain, username, or file name. If a string is security-relevant, confirm whether the platform stores, normalises, and displays it consistently across all user-facing surfaces.
Common mistake: Relying on visual inspection alone. Security teams often harden against exact lookalikes but forget that multiple systems may display the same string differently, especially after copy-and-paste, email forwarding, or browser rendering.
Practitioner takeaway: Treat homoglyph defence as a validation problem, not a cosmetic one; the key question is whether your controls compare the real identifier the same way users see it.
Related resources from NHI Mgmt Group
- How should security teams use attack path analysis to prioritise resilience work?
- How should security teams build recovery procedures for identity systems so they work during an outage or attack?
- How should security teams reduce browser-based attack risk without blocking the browser tools employees need to do their work?
- Why does manual SOC work become harder to sustain as alert volumes and attack complexity increase?