Invisible Unicode turned an AI evasion trick into a phishing filter test

TL;DR

Microsoft’s September 3, 2026 security analysis describes a finance-themed phishing campaign that inserted invisible Unicode tag characters into lure words. The technique borrowed the character range made famous by ASCII-smuggling demonstrations in prompt-injection research, but the observed use was narrower: it fractured words such as “funding” so a literal detector could miss the contiguous string. Hits on Microsoft Defender for Office 365 hunting logic rose from a low-thousands baseline to more than 1.3 million messages on February 9, 2026, peaked above 2.3 million on February 11, and then declined over the following months. Netics’ view is that the important lesson is not a new magic indicator. It is the need to define normalization, preserve raw evidence, and combine weak signals without pretending a telemetry window proves the whole campaign’s lifetime.

The technique crosses from AI research into the inbox

ASCII smuggling became visible in AI security because invisible characters can carry text that a person cannot see but a language model or software parser can still receive. The relevant range here is the Unicode Tags block, U+E0000 through U+E007F. It contains tag code points that mirror printable ASCII characters, and typical interfaces do not render most of them as visible glyphs.

In prompt-injection demonstrations, an attacker can hide instructions in a page, document, or message and rely on an AI system ingesting the underlying text. The recipient sees an ordinary page; the model processes a different textual surface. Microsoft’s finding reverses the direction of the trick. The characters were not observed carrying a secret instruction for an assistant. They were inserted into finance-related lure terms to alter what an email filter, tokenizer, or keyword matcher received.

That distinction matters for responsible reporting. Calling every tag-character sequence “a hidden message” would overstate the evidence. In the sampled emails, Microsoft describes invisible-character insertion inside words, not a complete encoded ASCII payload. The mechanism is still relevant to AI security because the same gap between rendered text and raw text can affect both model ingestion and traditional message processing.

The first naive hunting signature had its own blind spot: it flagged any character in the range. That included the tag sequences used by the England, Scotland, and Wales subdivision flag emojis. Microsoft excluded those legitimate sequences, then found that remaining hits were largely security gateways, mailbox providers, and researchers forwarding or testing messages until the campaign produced a sharp anomaly. A detector is not useful merely because it is sensitive. It needs a defensible account of what normal traffic looks like.

The detector sees a different word

Consider the visible word “funding.” In the observed pattern, the underlying text could place U+E0020, the invisible TAG SPACE, between letters: “fun” + U+E0020 + “ding.” A human reading the rendered message may still perceive the intended word. A literal search for the contiguous sequence funding will not.

This is where normalization becomes a security decision rather than a library detail. A pipeline that removes or normalizes the tag character before matching may recover “funding.” A pipeline that tokenizes first may split the word into familiar fragments plus an unusual code point. A model might assign an unfamiliar sub-token pattern, while a regular expression sees no contiguous keyword. Another parser might discard the character during HTML extraction. The result depends on the exact order and semantics of each stage.

Teams should therefore document at least three representations: the raw submitted bytes or Unicode string, a canonical analysis representation used for matching, and the rendered or extracted text shown to analysts. Do not overwrite the raw message with the normalized copy. If an alert fires, investigators need to prove which code points were present and where they appeared. Conversely, do not assume that “Unicode normalized” means “safe.” Different normalization forms do not all remove every invisible or format character, and a normalization operation designed for display consistency may not be the operation a detector needs.

A useful test suite should include U+E0000-U+E007F, zero-width space U+200B, no-break space U+00A0, soft hyphen, combining marks, and look-alike characters. It should test subjects, plain-text bodies, HTML bodies, decoded URLs, attachment text, and the output of every gateway in sequence. A control that works only on the mailbox copy is not necessarily working on the message that the upstream classifier evaluated.

Why Microsoft’s numbers are useful but bounded

Microsoft reports that the signature rose sharply on February 9, 2026. The day before, it fired on roughly 21,000 messages; the next day, on more than 1.3 million. The signal peaked above 2.3 million messages on February 11. Most of the emails could be clustered around roughly 150 finance-themed sender domains. The observed activity then kept a pronounced weekday rhythm, with weekday volumes between 1 and 2.37 million and a peak on February 26.

The pattern is operationally interesting. Weekend collapses and weekday rebounds suggest scheduled bulk-sending infrastructure rather than a random trickle. Microsoft also reports roughly 80% less weekday volume by late March, followed by a sharp decline after May 15 and lower residual activity through mid-June. Those observations help defenders identify when a particular signature is worth investigating.

They do not establish that the broader phishing operation began on February 9 or ended after May 15. Microsoft explicitly separates the period in which this technique appeared from the wider ActiveCampaign-delivered SBA-themed campaign, which had been documented earlier and continued without necessarily using the same Unicode method. This is the telemetry discipline security teams need: a hunting signature measures matches to a defined condition in a defined data set. It does not automatically measure attacker intent, total delivery, or campaign lifetime.

The same caution applies to the roughly 96% share attributed to finance-themed campaign domains and the measured sending infrastructure. A shared marketing platform, tracking domain, or IP range can be a useful corroboration and scoping signal. It is not, by itself, proof that every tenant or every message using that infrastructure is malicious. Blocking shared infrastructure without context can damage legitimate senders while leaving the lure logic untouched.

Build controls around the blind spot, not only the character range

A Unicode-range rule is a sensible hunting pivot because the characters are uncommon in ordinary business mail. It is not a complete verdict. The first layer should make the text comparable: decode the relevant content, record the original form, and apply an explicitly tested normalization and format-character policy before keyword and token analysis. The second layer should look for context: finance-themed disposable domains, unusual sender alignment, tracking-domain chains, bulk patterns, suspicious links, and mismatches between visible labels and destinations.

The third layer is behavioral and operational. Rate limits, reputation history, authentication results, sandboxing, safe-link rewriting, user-report feedback, and mailbox-level anomaly detection can still catch a message when one lexical feature defeats one classifier. Quarantine policy should be proportional to confidence. A rare tag character in an authenticated internal message may deserve investigation; the same character inserted into a loan lure from a newly observed domain deserves a very different response.

Do not make OCR the default answer. Screenshot-based extraction can add a useful rendered-text comparison for image-heavy messages, but it is expensive, lossy, and unable to recover intent from every design. The stronger baseline is to make machine-readable message text robust first, then use visual inspection where the rendered presentation itself is part of the attack.

For a concrete but hypothetical control review, imagine a 30-person company receiving a sudden weekday burst of “business funding” mail. The team could quarantine messages containing tag-block characters, retain the raw MIME, normalize a separate analysis copy, compare decoded links with visible anchors, and review sender-domain age and authentication together. It would then sample false positives, including flag emojis and security test messages, before widening the block. That sequence creates evidence and a rollback path instead of turning one surprising indicator into an irreversible deny list.

Netics’ reading of the security signal

The news is not that phishing has discovered invisible text. Zero-width spaces, soft hyphens, no-break spaces, and homoglyphs have long been used to fracture words or substitute look-alikes. The new combination is the choice of the Unicode Tags block, its recent visibility through AI prompt-injection research, and the reported scale of the observed activity.

The practical message for defenders is architectural. Text security begins before classification: what representation does each component see, what gets removed, and what evidence survives? Detection quality improves when the pipeline treats normalization as a declared boundary and keeps the raw message available for investigation. Coverage improves when lexical anomalies are joined to sender, link, infrastructure, and behavior signals. Trust improves when telemetry claims stay inside their measurement window.

For more grounded analysis of security controls and AI-era infrastructure, visit the Netics homepage.

Sources

• Microsoft Security Blog — ASCII smuggling crosses over from AI prompt injection to phishing evasion, published September 3, 2026; primary source for the campaign observations and telemetry discussed here.
• Unicode Standard Annex #45 — Tags, background on the U+E0000-U+E007F block.
• MITRE ATLAS — LLM Prompt Obfuscation, context for the AI-security technique discussed by the source.

Source: Microsoft Security Blog, 3 September 2026 — https://www.microsoft.com/en-us/security/blog/2026/09/03/ascii-smuggling-crosses-over-from-ai-prompt-injection-to-phishing-evasion