What Is a Homoglyph Attack? 2025 Guide to Unicode Spoofing & Phishing Defense

• Homoglyph (homograph) attacks exploit visually identical characters often from different scripts to spoof domains, emails, or filenames.
• Example: example.com (Cyrillic “а”) appears identical to example.com (Latin “a”).
• These lookalike domains trick users into revealing credentials or downloading malware.
• In 2025, phishing remains the number one attack vector, with an average breach cost of $4.88M, making homograph spoofing a serious threat.
• Penetration testers should include homoglyph scenarios: generate confusable domains and simulate phishing attacks.
• Defense strategies:
  • User training and awareness
  • Technical controls: DMARC, punycode display, confusable-detection tools
  • Continuous domain monitoring for suspicious lookalikes.

A homoglyph attack is a form of visual spoofing where attackers replace letters in a name or URL with nearly identical characters from another alphabet. In practice, a user may click a link that looks like “amazon.com” but contains a Greek ο or Cyrillic а in place of a Latin letter. The browser or email client shows a familiar string, but the link points to a different domain. This exploits how Unicode works: many alphabets have characters (glyphs) that are confusable. For example, Unicode small Cyrillic о (U+043E) is indistinguishable from Latin o (U+006F) on most screens. When IDN (Internationalized Domain Name) support is used, these spoof domains become valid in DNS, meaning “аррӏе.com” all Cyrillic letters can resolve independently from “apple.com”.

Penetration testing often includes social engineering and domain reconnaissance. As part of a phishing or red-team test, attackers may register lookalike domains to see if users or systems are fooled. For background on pentesting, see What is Penetration Testing? for how these assessments work. In a homoglyph test, a pen tester might spoof a login URL or sender address with visually deceptive characters. This exploits the fact that humans and simple filters misinterpret the characters. In short: homograph (homoglyph) attacks hide malicious domains in plain sight.

How Homoglyph Attacks Work

Homoglyph attacks rely on Unicode’s vast character set. Attackers mix scripts (Latin, Cyrillic, Greek, etc.) or use lookalike symbols so the text appears unchanged. For instance, Google’s documentation notes “Latin ‘a’ looks a lot like Cyrillic ‘а’”, so an attacker could register xn--80ak6aa92e.com (which renders as “ebаy.com” with Cyrillic а), a perfect knock-off of “ebay.com”. The browser may display it as “ebay.com” or at least not raise alarm, but it leads elsewhere.

Common Attack Scenarios:

• Lookalike Domains: Registering domains that mimic real ones. Example: “аррӏе.com” (xn--80ak6aa92e.com) uses Cyrillic letters to appear as “apple.com”. Another is “example.com” with a Cyrillic а. Even digits and symbols are used (e.g. using “0” for “O” or “@” for “a”).
• Phishing Emails & BEC: Attackers put homoglyphs in display names or sender addresses. For example, an email from Sρօtifу (using Greek ρ and օ) can fool a user into thinking it’s from Spotify. These subtle swaps often bypass normal email filters because “pаypal.com” (with Cyrillic а) is technically a different string than “paypal.com”.
• Fake Logos & Filenames: Trojans and scams use homoglyphs in filenames or links. In 2017, attackers registered adoḅe.com (the ḅ is a dotted ‘b’ character) to mimic Adobe’s site and deliver the Betabot Trojan. Even software libraries have been impersonated (e.g. publishing a “numpi” package with a Cyrillic і to evade detection).

Attackers exploit visual confusion: to a human, “citibank.com” with a Cyrillic с looks identical, so victims may hand over credentials, not realizing they’re on an imposter site. Automated systems can also be fooled: filters that scan for “paypal.com” won’t catch “paypal.com” (Latin vs Greek alpha). This makes homoglyphs a powerful tool to evade defenses and impersonate trusted brands.

Homoglyph vs Typosquatting: Key Differences

A typosquatting victim simply mistypes a URL, whereas a homoglyph attack actively tricks the user with what appears correct. In fact, typosquatting depends on user input errors, while homograph attacks work even when links are clicked. As the DarkOwl CSA blog explains, homoglyph fakes are created using lookalike symbols (e.g. using “0” for “O”), whereas typosquatting is a straightforward spelling error.

Why Homoglyph Attacks Matter in 2025

In today’s threat landscape, homoglyph attacks amplify phishing and social engineering risks. Phishing remains the top attack vector DeepStrike’s 2025 report highlights average breach costs of $4.88M for phishing-based incidents and $10.22M in the U.S. on average. Homoglyph spoofing is a favored tactic for threat actors, from nation-states to cybercriminal rings, because it can slip past email filters and trick even security-conscious users. With AI-driven phishing on the rise up 1,265% year-over-year, these deceptive domains are more dangerous than ever.

Moreover, as internationalized domain name IDNs proliferate globally, the attack surface grows. Non-ASCII character support means millions more possible lookalikes exist. Browsers like Chrome and Firefox have had to tighten their IDN policies; for example, Chrome now shows punycode for mixed-script domains to warn users. Still, in email clients or social networks, homoglyphs often render as normal text. This tactic has led to high-profile scams: from Google Drive phishing to business email compromise BEC schemes. For organizations, any account takeover or data theft facilitated by a homoglyph site can trigger expensive breaches and regulatory fines. In short, proactive testing and defense against homograph attacks is critical to protect brand and data integrity.

Real-World Homoglyph Attack Examples

• PayPal 2000 Early ASCII trick: attackers registered “PayPaI.com” (capital “I” instead of lowercase “l”) and sent bogus payment emails to steal PayPal credentials. Many victims couldn’t tell I from l in small text.
• Adobe Betabot 2017 Researchers found an attack where the domain adoḅe.com (using a dotted ‘b’) was registered to appear as “adobe.com.” Visitors were lured into downloading a fake Flash update, installing the Betabot banking trojan.
• Enterprise Phishing 2020s Palo Alto Unit42 reported BEC campaigns using Cyrillic letters in sender names and subjects. One email impersonated DocuSign with a sender “Сonfidеntiаl Тicket” Cyrillic С, е, а, etc. to disguise as an internal message. Another mimicked Spotify: “Sρօtifу Support Team” using Greek ρ, ο. In each case the display looked normal, so victims clicked malicious links.
• Chromium Research 2017 Security engineer Xudong Zheng showed that replacing every letter in “apple.com” with a homoglyph forming аррӏе.com bypassed Chrome’s IDN filter. This proof-of-concept emphasized how undetectable mixed-script domains can be.

These incidents highlight that even savvy users and automated defenses can be fooled by homoglyphs. They also show a common pattern: the top-level domain (TLD) remained the same e.g. “.com”, but the letters themselves came from another alphabet, blending seamlessly into the interface.

How to Test for Homoglyph Attacks (Penetration Testing Steps)

To ensure your organization isn’t vulnerable, include homoglyph scenarios in your security assessments. Here’s a step-by-step approach for testers:

1. Identify Key Domains/Names. List the critical domain names, URLs, and email sender addresses e.g. corporate domain, partner brands. These are the targets for spoofing.
2. Generate Homograph Variants. Use tools or scripts to find all possible look-alikes. For example, use dnstwist-style generators or the Unicode confusable tables (UTS #39) to swap letters. This yields domains like “example.com” (Cyrillic а) or “microsfot.com”.
3. Register or Simulate Domains. Optionally register the spoof domains in a safe testing environment, or at least create test records. This lets you see how browsers and systems display them often in punycode. If actual registration isn’t feasible, simulate by editing your hosts file or DNS in a lab.
4. Conduct Phishing and Access Tests. Send controlled phishing emails using the spoof addresses, or have testers visit the fake sites. Verify whether email filters catch them and whether users notice the anomalies. Check if authentication systems properly flag mismatched domains for example, password managers usually won’t autofill on the wrong domain.
5. Analyze and Report Findings. Document which homoglyphs were most convincing and which defenses failed. Provide clear remediation: this might include blocking those domains, updating spam filters, or adding monitoring rules. Recommend 2FA or password alerts for potentially compromised accounts.

This approach can be integrated into a standard external or red-team test. By simulating real attacker steps, you can validate whether your organization’s email filters, browser settings, and user awareness are effective against homoglyph deception.

Defense & Prevention Strategies

Why this matters: Preventing homoglyph attacks requires both technical and human-focused controls. Below are key best practices:

• Use Punycode Display/Policies: Configure browsers and email clients to reveal suspicious IDNs. Modern browsers follow strict IDN rules: if a domain mixes scripts or matches known confusables, it is shown in Punycode instead of Unicode. For example, Chrome 59+ will display xn--80ak6aa92e.com instead of “аррӏе.com,” warning users. Administrators should enable any available “show punycode” settings (e.g. Firefox’s network.IDN_show_punycode) so confusing domains stand out.
• Deploy Email Authentication: Enforce DMARC, DKIM, SPF on your domains. While these don’t stop a homoglyph, they help recipients identify legitimate senders. If a phishing email appears to be from “paypal.com” but comes from an unapproved server, DMARC will mark it. In other words, good email hygiene makes any spoofed domain easier to spot.
• Monitor Domain Registrations: Use a domain monitoring service to watch for look-alikes. Many security vendors offer brand-protection tools that scan for newly registered domains resembling your name. If a malicious homograph domain appears e.g. “Аmazon.com” with a Cyrillic А, you can take it down or block it early. We also recommend proactive defensive registration of common variants for your brand.
• Educate & Test Employees: Train users to hover over links before clicking, check login URLs, and report suspicious emails. Simulated phishing tests should include homograph examples to see if users notice the trick. Empower staff to manually verify any unexpected login prompts or email requests, especially those claiming urgency.
• Enforce Strong Authentication: Even if credentials are phished, multi-factor authentication (MFA) can block account takeovers. NIST guidelines SP 800-63B emphasize phishing-resistant MFA like hardware keys or app-based one-time codes for high assurance. In practice, require 2FA for any sensitive system so that a spoofed login alone isn’t enough.
• Integrate Confusable-Detection Tools: Use security solutions that analyze Unicode at the codepoint level. Some advanced email gateways and DNS firewalls can detect confusable strings. For example, they may map “sρotify.com” to its ASCII skeleton and flag it if it’s not an approved sender. Ensuring your security stack is homoglyph-aware can catch those phishing URLs that simple regex misses.

By combining user vigilance with technical checks e.g. forcing punycode, using spam filters that decode Unicode, and verifying SPF/DKIM, you can greatly reduce homoglyph risks. Remember that even best practices are only effective if regularly reviewed. As attackers invent new tricks, mixed fonts, unconventional scripts, keep your defenses updated. Periodic retesting including re-running homograph generators ensures you stay one step ahead.

Stay Vigilant, Test Often

Homoglyph (homograph) attacks are a subtle but potent phishing technique. In this article we explained what they are, how they work, real examples of scams, and concrete ways to test and defend against them. The key takeaway is that visibility matters: both users and security systems need to notice when a name isn’t truly what it seems. By including homoglyph scenarios in penetration tests and by implementing controls punycode display, domain monitoring, email auth, MFA, etc., organizations can greatly reduce their risk.

Ready to strengthen your defenses? The evolving threat landscape demands proactive action. If you need to validate your security posture, uncover hidden risks, or improve your resilience, DeepStrike can help.

Our expert team delivers clear, actionable guidance to protect your business from sophisticated attacks. Explore our penetration testing services to see how we can uncover vulnerabilities including homoglyph vectors before attackers do. Drop us a line, we’re always ready to dive in.

About the AuthorMohammed Khalil is a Cybersecurity Architect at DeepStrike, specializing in advanced penetration testing and offensive security operations. With certifications including CISSP, OSCP, and OSWE, he has led numerous red team engagements for Fortune 500 companies, focusing on cloud security, application vulnerabilities, and adversary emulation. His work involves dissecting complex attack chains and developing resilient defense strategies for clients in the finance, healthcare, and technology sectors.

FAQs

• What is a homoglyph (homograph) attack?

It’s a spoofing attack where a domain, email, or filename is made to look identical to a legitimate one by swapping characters with visually similar glyphs often from another alphabet. For example, using Cyrillic а in place of a Latin a in “example.com” results in a lookalike URL. The user thinks they see the correct name, but in reality it points to a fake resource.

• How do homoglyph attacks differ from typosquatting?

Typosquatting relies on common typing errors like “gooogle.com”, whereas a homoglyph attack actively deceives by using identical-looking characters. Typosquatting only succeeds if the user spells wrong; a homoglyph attack can fool users even if they copy-paste or click a link, because the text appears correct.

• Can browsers or email systems automatically block homoglyph attacks?

Modern browsers Chrome, Firefox, Edge use IDN policies: if a domain has mixed scripts or looks confusable, they often display the punycode form instead of the Unicode string. For example, “аррӏе.com” would appear as “xn--80ak6aa92e.com.” This alerts savvy users. Email systems with advanced filters may also catch known bad domains, but many standard filters do not flag Unicode confusables. Therefore, technical measures help, but user awareness and strict email authentication DMARC/SPF/DKIM are also crucial defenses.

• What are common targets of homoglyph phishing?

Large brands and financial sites are prime targets. Attackers have mimicked PayPal, banks, cloud services, and popular apps. For instance, phishing campaigns have spoofed Google Drive and DocuSign notifications by inserting Cyrillic letters into names. Streaming and SaaS platforms are also attacked e.g. fake “Spotify” emails. Essentially, any site where users enter credentials can be targeted with a homoglyph-laced fake.

• How can penetration testing include homoglyph scenarios?

Pen testers can simulate these attacks as part of phishing or red-team assessments. Using tools like dnstwist or custom scripts, testers generate homograph variants of target domains and use them in phishing templates. They then check if employees or security controls notice. Including homoglyph tests in a pentest ensures that any gaps in email filtering or user training are identified and remediated.

• Why are homoglyph attacks dangerous even if I have email security in place?

Homoglyphs can bypass simple filters because the malicious URL/email looks legitimate at a glance. A filter for “paypal.com” won’t match “pаypal.com” with different characters. Also, if an email is already in a user’s inbox (say, it’s from a trusted provider but with a deceptive address, even SPF/DKIM checks can pass if the domain itself is spoofed. That’s why multi-layered defense authentication, display warnings, MFA and user skepticism are needed alongside technical controls.