Microsoft Tracked an ASCII Smuggling Phishing Campaign That Hid Lure Words From Signatures

Starting February 9, 2026, Microsoft's mail telemetry began logging as many as 2.37 million messages a day in which an invisible Unicode character had been spliced into the middle of a phishing lure word so that keyword detection would not see the word. The technique is called ASCII smuggling, and it was not invented for email. It was popularized by researchers attacking AI models, and Microsoft's write-up on September 3 is the first well-documented case of it being turned around and aimed at the pre-AI plumbing.

Start with the part most coverage will skip. More than 99% of these messages were flagged anyway, by Defender for Office 365 layers that never needed to read the tag characters at all: sender, IP, URL and domain reputation, machine-learning spam and phishing classification, brand-impersonation detection and authentication checks. This is not a story about mail sailing into inboxes. It is a story about one matching layer being reliably defeated for three months while the layers around it carried the load, which is a different and more useful thing to know.

The research is bylined to Microsoft Security Research with Noam Kochavi and Sarah Wolstencroft, and it came out of work on Defender for Office 365's prompt-injection protection. Defensive AI tooling went looking for AI attacks and found a classic phishing campaign instead.

What the Attacker Actually Did

The campaign spliced U+E0020, the Unicode TAG SPACE character, into finance-themed lure words. Microsoft's example is the word funding, transmitted as fun + U+E0020 + ding. The character renders as nothing, so the recipient reads an ordinary word. A detector matching the literal string does not, because the byte sequence no longer contains the contiguous keyword. Microsoft puts the asymmetry plainly: "To a recipient, and to parsing pipelines that drop or normalize these characters, the word still reads as funding."

The volume curve is the most concrete thing in the report. On February 8 the hunting signature fired on roughly 21,000 messages. On February 9 it fired on more than 1.3 million. Weekday volumes then ran between 1 and 2.37 million, peaking on February 26, with a sharp dip on Sunday February 15 before rebounding, a weekday rhythm Microsoft describes as typical of scheduled bulk-sending infrastructure. By late March the numbers had stepped down to roughly 80% less per weekday, and high-volume use of the technique dropped off sharply after May 15. Most of the mail clusters into roughly 150 finance-themed sender domains.

Only the figures Microsoft published are plotted here, positioned by date and scaled against the 2.37 million peak. Microsoft did not publish a daily series, so this is not one. Source: Microsoft Security Blog, September 3, 2026.

Two limits on those numbers, and they matter. They are counts of a Microsoft signature firing inside Microsoft's own visibility, not a measurement of global email. And Microsoft says its analysis covers only the period and the messages in which this method was present, not the whole life of the campaign behind it. No actor has been named, and no other mail-security vendor has published comparable telemetry.

Why This Is Harder Than a Signature Update

The obvious fix is to add the tag block to a deny list, and that is not the interesting part. Microsoft says the real target was never the regex: "The bigger prize for the attacker, though, is not preventing the literal string matches; it is the ML- and NLP-based models that increasingly drive modern spam and phishing classification." A classifier trained on tokens is reading the same broken byte sequence a string matcher is.

Which turns this into a question about normalization, a step almost nobody reviews. Every control that matches text, whether by regex, token or embedding, is only as reliable as the pass that folds the input into a canonical form first. Microsoft is explicit that this varies by product: "Implementations vary, so defenders should test how these characters are handled in their own pipelines."

My read, and this is assessment rather than reported fact: the durable finding here is not about email at all. It is that normalization is a security control, and it is almost never owned, tested or monitored as one. The same gap is what makes homoglyph domains and Unicode-confusable usernames work. Attackers found it in the AI stack first because AI systems ingest raw text with almost no preprocessing, and they have now walked it back down into infrastructure that has existed for thirty years. Expect more traffic in that direction, not less.

Does Your Mail Filter Normalize Before It Matches?

That sentence is a support ticket you can file today, and it has a binary answer. Does your secure email gateway strip or fold characters in the U+E0000 to U+E007F tags block before it runs content signatures, or does it match against the raw body? Most teams have never asked. The answer determines whether this technique works against them, and no amount of general vigilance substitutes for knowing it.

Three follow-ons:

• Audit your own detection content the same way. Home-grown keyword rules, DLP patterns and SIEM string matches have exactly the weakness a commercial filter has, and no vendor is patching them for you. Any rule keying on literal financial-lure strings is a candidate.
• Hunt backwards. The elevated window ran from February 9 to roughly May 15, 2026. If your mail archive covers it, search subjects and bodies for tag-block code points. Microsoft notes that legitimate mail essentially never carries these characters, which makes their presence a high-fidelity signal rather than a noisy one, and it recommends treating tag-block characters as a strong anomaly on their own.
• Do not stop at email. Anywhere text arrives from outside and gets matched, scored or fed to a model is the same exposure. Ticketing systems, chat ingestion and document pipelines all qualify.

One Control, Two Problems

Microsoft's recommendation is a single step applied in two places, and that is what makes this story worth more than its news value. Strip or normalize Unicode tag characters, and other zero-width and invisible code points, from subject and body before applying spam and phishing signatures. Then "apply the same normalization upstream of AI ingestion," because, as Microsoft puts it, the control that defeats this evasion also reduces cross-prompt injection and ASCII-smuggling exposure for AI assistants that read email.

That closes the loop the headline opens. The technique came out of prompt injection research, where MITRE ATLAS catalogues it as LLM Prompt Obfuscation, and the fix for the email problem is the same fix as the AI problem. Teams that already built invisible-character stripping into their model input path have, without meaning to, built the mail-filter control too. Teams that did it for the mail gateway years ago have a head start on the assistant.

It is also a reminder of how quickly attacker tooling recycles. The same period has produced steady iteration in kit-based phishing, from the Kali365 kit's expansion into AWS and Okta flows onward. What is new is the direction of travel: a method built to fool a language model, retooled to fool a spam filter, defeated by the same normalization pass either way.

Primary Documents

• Microsoft Security Blog: ASCII smuggling crosses over from AI prompt injection to phishing evasion, Microsoft Security Research, Noam Kochavi and Sarah Wolstencroft, September 3, 2026
• MITRE ATLAS, which catalogues LLM Prompt Obfuscation, the technique's AI-security lineage
• The Register: ASCII smuggling isn't just an AI security risk, September 4, 2026