Invisible Unicode Is Now Hiding Phishing in Plain Sight

A phishing email can look perfectly ordinary to a person and still be a different piece of text to the software inspecting it. That gap is no longer a laboratory curiosity. In a 3 September investigation, Microsoft described a campaign that inserted invisible Unicode tag characters inside financial lure words. The recipient saw a familiar offer; a keyword rule or tokenizer could see a broken string.

The practical lesson is broader than email: every system that ingests untrusted text needs to distinguish what a human sees from what the machine processes. That includes support portals, document pipelines, search indexes, analytics feeds and AI assistants.

What Microsoft found

The campaign used characters from the Unicode Tags block, U+E0000–U+E007F. Most interfaces do not render these characters, but they remain present in the underlying text. Instead of hiding a full instruction, the senders inserted a tag character inside high-signal words such as “funding.” The visible word stayed readable while the machine-level sequence was interrupted.

Microsoft’s telemetry shows the scale. Matches rose from roughly 21,000 messages on 8 February to more than 1.3 million the next day, later peaking at 2.37 million in one day. The high-volume phase ran largely on weekdays for about three months. Around 96% of the detected volume belonged to a finance-themed cluster, and much of it travelled through legitimate shared marketing infrastructure.

This is why blocking one sender, one IP range or one tracking domain is not enough. Shared infrastructure also carries legitimate mail. Microsoft reports that more than 99% of the messages were caught by other layers—reputation, authentication, URL analysis, impersonation checks and machine-learning classifiers—not by a single Unicode rule.

The real defect is inconsistent text interpretation

Security controls often assume that the string shown to a user is the string evaluated by every downstream component. In practice, an email gateway, browser, database, regular expression, language-model tokenizer and screenshot-based OCR pipeline may each interpret the same input differently.

That creates two failure modes. First, a literal signature can miss a dangerous term after an invisible code point splits it. Second, an AI assistant may receive hidden content that the approving employee never saw. The same normalization gap therefore connects conventional phishing with cross-prompt injection.

The Unicode standard reference explains the Tags mechanism; the campaign maps cleanly to both MITRE ATT&CK phishing and obfuscated information. The important engineering conclusion is that visual equivalence is not semantic equivalence.

A normalization-first defence

1. Preserve the original, then create a security-normalized copy. Keep raw content for evidence and incident response. Separately derive a canonical representation for detection by removing or folding prohibited non-rendering characters. Log which transformations occurred so analysts can reconstruct the decision.

2. Normalize before every trust decision. Apply the same policy before keyword matching, URL extraction, data-loss rules, embedding, search indexing and AI ingestion. Normalizing only at the email gateway leaves later pipelines exposed when files or copied text enter through another route.

3. Treat rare invisible characters as a signal, not an automatic verdict. Tag-block characters are unusual in business email, but some legitimate emoji sequences use them. Detect the anomaly, exclude known-valid sequences, and combine the result with sender age, authentication, link reputation, volume and business context.

4. Compare rendered and parsed views. A useful test harness sends adversarial samples through the complete production path and records raw code points, normalized text, extracted URLs, model input and the final user-visible rendering. Screenshot-plus-OCR analysis can add an independent view when parsers disagree.

5. Put approvals after sanitized presentation. If an AI assistant can draft a payment, change a supplier record or send a message, the approval screen must show the normalized action and destination—not a summary generated from the untrusted input. High-impact tools still need scoped permissions and a separate confirmation step.

What teams should do this week

• Ask your email and security vendors how U+E0000–U+E007F and other non-rendering characters are handled before classification.
• Add Unicode-tag samples to phishing, document-ingestion and AI-agent security tests.
• Search recent telemetry for unexpected tag-block characters, but avoid treating shared marketing infrastructure as malicious on its own.
• Review every route by which email, PDFs, web pages or support tickets can reach an AI assistant.
• Give finance and operations teams a simple rule: verify payment and funding requests through a second channel.

The Qomra Tech view

This incident is a compact example of a larger product-security rule: canonicalize data at the boundary, preserve evidence, and layer controls around consequences. Founders do not need a new security product for every novel character trick. They need one documented text-handling policy, repeatable adversarial tests and approval flows that assume machine-readable content may differ from what a person sees.

For teams adding AI to inboxes and operational workflows, the next sprint should include normalization tests alongside prompt-injection tests. The control is small; the trust boundary it protects is not.