Visual deception: Swapping a few ordinary letters for visually identical Unicode "confusables" (homoglyphs) makes a sentence look normal to humans while blinding PII, DLP, and threat classifiers to it.
Architectural weakness: The vulnerability isn't the model's neural architecture — it's the pipeline. Any classifier operating on raw, un-normalized text assumes the token sequence it receives matches what a human sees, inheriting Unicode's full character complexity as an attack surface.
Defensive strategy: Resilience requires normalizing text before classification, backed by in-depth automated adversarial testing and retraining on perturbed inputs — with raw text always treated as untrusted.
Every email security control that reads text makes a quiet assumption: that the characters a machine sees are the same ones a human reads. This article breaks that assumption in about thirty seconds. With five keystrokes, swapping a handful of ordinary letters for visually identical Unicode "confusables," an attacker can render a sentence that looks perfectly normal to any reader while becoming invisible to the PII detectors, DLP filters, and threat classifiers meant to catch it. For security professionals, this isn't a clever party trick.
Homoglyph substitution is a well-documented technique in phishing and brand impersonation, but its effectiveness against modern classifiers exposes an architectural weakness shared by nearly every classifier that operates on raw, un-normalized text. Understanding how the attack works, and why defending against it means normalizing text before it's ever classified, is essential for anyone responsible for keeping malicious content out and sensitive data in.
The demo
There's a demo you can run yourself in about 30 seconds. Open a modern PII-redaction filter designed to detect and redact sensitive email addresses and phone numbers (such as OpenAI's privacy filter, which can be demoed here), and feed it this:
Email me at alice@example.com or call 415-555-0101.
It performs as expected: the email address and phone number are flagged as sensitive PII ready to be masked.
Now feed it this variation:
Email mе at аlice＠example.com or сaⅼⅼ 415‑555-0101.
The output sails straight through. No email detected, no phone number detected, and nothing redacted.
To human eyes, the two lines appear identical. To the filter, the second input contains no PII at all. That divergence between human visual perception and machine tokenization is a central vulnerability in NLP pipelines, particularly for detection and security systems.
What actually happened
The second string isn't oddly spaced plain text. It uses homoglyph substitution: standard ASCII characters replaced with visually identical Unicode confusables:
The e in "me" is Cyrillic (U+0435), not Latin e (U+0065).
Related Tags
Data Protection
Share this
е
The a in "alice" is Cyrillic а (U+0430).
The @ is a fullwidth commercial at (U+FF20), not ASCII.
The c in "call" is Cyrillic с (U+0441), and the two ls are small roman numeral fifty (U+217C), which renders as a lowercase L.
The first hyphen in the phone number is non-breaking (U+2011); the second is standard ASCII.
These glyphs ship with standard font sets and paste cleanly from any text input. Sans-serif fonts, which nearly every email client uses, widen the overlap: a lowercase l, an uppercase I, and a Roman numeral all reduce to the same vertical stroke.
Detectors built on naive ASCII regular expressions or subword tokenizers (BPE, WordPiece) break down here. Cross-script homoglyphs split words into unexpected tokens and disrupt pattern boundaries, so the model never sees a sequence it recognizes as sensitive data. The redaction logic never fires.
Real-world impact in email security
While this demonstration uses a synthetic PII filter, homoglyph attacks have a long, documented history of real-world exploitation in email security and threat detection.
Lookalike domains built using Cyrillic and Greek characters have been used to impersonate brands and organizations for years. What this privacy filter demo illustrates is a broader architectural issue: any classifier operating on raw, un-normalized text inherits Unicode's entire character complexity as an attack surface.
For example, as shown in Figure 1, in phishing campaigns, using a subject line like Fw: lNV-O-991-09 (substituting a lowercase l for an uppercase I) circumvents simple keyword and pattern matching on INV. Because desktop, web, and mobile email clients almost universally render subject lines and message headers in sans-serif fonts, the lowercase l and uppercase I are visually indistinguishable to the recipient.
Figure 1: Email using glyph for evasion
Consider how this impacts core email security capabilities:
DLP and PII detection: Exfiltrating sensitive data past content filters by re-encoding characters with homoglyphs, relying on downstream mail clients or renderers to display them legibly to the end user.
BEC and impersonation detection: Display names or payment instructions that render as "Accounts Payable" to a reader, but tokenize as out-of-vocabulary noise to the classification model.
Brand and domain spoofing: Sender strings or URLs engineered to be visually indistinguishable from legitimate targets while bypassing string-matching controls.
The core takeaway: adversaries rarely need to attack a model's underlying neural architecture. They only need to violate the implicit assumption that the byte or token sequence received by the model matches the visual representation perceived by a human.
Building adversarial robustness into text classifiers
Most text classification models are evaluated on clean, canonical benchmark datasets. However, real-world inputs in threat detection routinely depart from clean distributions. Building resilient detection pipelines requires treating adversarial inputs as a standard design constraint. Key engineering controls include:
Implement multi-stage normalization
Standard Unicode NFKC normalization collapses compatibility characters (such as fullwidth characters like ＠ (U+FF20), Roman numerals like ⅼ (U+217C), and non-breaking hyphens) back to canonical ASCII form. However, NFKC does not convert cross-script homoglyphs like Cyrillic а (U+0430) to Latin a (U+0061). To resolve cross-script confusables, pipelines must explicitly apply Unicode Technical Standard #39 (UTS #39) confusable mapping or skeleton algorithms prior to tokenization.
Apply defense in depth
While character normalization resolves direct confusable swaps, it does not eliminate zero-width joiners, bidirectional overrides, or novel character-level manipulations. Text classification should serve as one signal among multiple detection layers rather than a single point of failure.
Incorporate automated adversarial evaluation
Models should be continuously benchmarked against character- and token-level perturbation suites. Automated search methods that identify minimal character edits capable of flipping model predictions surface brittle decision boundaries and reveal gaps in preprocessing pipelines.
Retrain models on perturbed inputs
Adversarial examples generated during red-teaming provide valuable training data. Incorporating adversarial and perturbed variants into training pipelines improves model stability against distribution shifts and evasion techniques.
The bottom line
Evading un-normalized text classifiers requires minimal technical overhead, often requiring nothing more than a character substitution lookup table. Consequently, defenders cannot rely solely on larger model parameters or clean-data benchmark performance.
Long-term resilience against text-based evasion requires pipeline design that accounts for Unicode ambiguity from the first stage of preprocessing. In threat detection and security engineering, raw text must always be treated as untrusted input.
Subscribe to Cyber Resilience Insights for more articles like these
Get all the latest news and cybersecurity industry analysis delivered right to your inbox
Loading form
5 keystrokes that defeat a privacy filter | Mimecast
