Invisible Unicode characters from AI research turned up in a phishing campaign of 2.3 million messages a day

A hunting signature written to catch prompt injection in email found something else. Microsoft Security Research reported on September 3, 2026 that the invisible Unicode characters it was watching for were being used by a bulk phishing operation, not by anyone trying to talk to a model. The same code points that hide an instruction from a reader while leaving it visible to an assistant also hide a keyword from a filter while leaving it readable to the person the message is aimed at.

What the campaign actually did

The Unicode Tags block, U+E0000 to U+E007F, holds an invisible shadow copy of printable ASCII. It was meant for language tagging and is now largely deprecated, and most fonts and interfaces render nothing for it. AI red teams spent the past year demonstrating that a model reading raw text does see those characters, which is where the name ASCII smuggling comes from.

This campaign inverted the purpose. Rather than encoding a message in the tag block, it dropped a single invisible U+E0020 inside high-value words, so that funding traveled as fun, an invisible separator, and ding. To the recipient the word still reads as funding. To a detector matching the literal string, the contiguous keyword is no longer there. Microsoft is explicit that this is invisible-character insertion for filter evasion, not instruction smuggling.

The shape of the traffic

Signature hits sat in the low thousands until February 8, 2026, when the signal fired on roughly 21,000 messages. On February 9, 2026 it fired on more than 1.3 million, and on February 11, 2026 it peaked at over 2.3 million. Weekday volumes then ran between one and 2.37 million, and by late March they had stepped down to roughly 80% less per weekday. The high-volume phase dropped sharply after May 15, 2026.

The messages clustered into roughly 150 finance-themed sender domains built by recombining the same small vocabulary of words such as capital, funding, guardian and boost. That cluster accounted for about 96% of the volume the signature flagged. The mail itself was relayed through the legitimate marketing platform ActiveCampaign, which rewrites every outbound link to its own tracking domains, so the sender domain the recipient reads is not where the click goes.

• The campaign ran on weekdays and went almost silent every weekend, which is the fingerprint of scheduled bulk-sending infrastructure.
• Lures were business loan, line-of-credit and advance-funding offers, the usual shape of a credential or fraud funnel.
• Microsoft shared the findings with ActiveCampaign before publishing, and quotes the platform's response in the post.
• For Defender for Office 365, over 99% of the messages were caught by layers that never looked at the tag characters at all.

Why an invisible character defeats a classifier

Literal string matching is the easy half of the problem. The harder half is that modern spam and phishing classification runs on models that split text into tokens before they reason about it. A clean lure word is a familiar token or a familiar sequence of sub-tokens. Insert one invisible code point in the middle and the tokenizer may emit rare or unknown pieces instead, so the classifier is no longer looking at the thing it was trained on.

Whether that happens at all depends on one step: normalization. If the pipeline strips the tag characters before analysis, the word is simply funding again and nothing was gained. If it does not, everything downstream is reading a different string than the recipient is. Microsoft also notes the defensive side of the same fact, which is that these code points are so rare in ordinary mail that their presence is a high-confidence anomaly signal on its own.

What to change in your own pipeline

The recommendation is to strip or fold invisible and non-rendering code points out of subject and body text before any keyword, signature or regex logic runs, and to apply the same normalization upstream of anything a model ingests. That second half is the part worth copying even if you do not filter mail: an assistant that summarizes a page, a ticket or an inbox is reading raw text with exactly the same blind spot.

There is one calibration detail worth stealing as well. Microsoft's first version of the signature flagged any code point in the tag range and kept firing on legitimate messages, because the flag emojis for England, Scotland and Wales are encoded with tag characters. A rule this narrow needs its known-good cases written down before the alerts mean anything.