Microsoft threat researchers have documented a phishing campaign, first seen on 9 February 2026, that hid invisible Unicode characters inside finance keywords to break keyword-based email filtering.

The technique is ASCII smuggling. Characters from Unicode's Tags block, the range U+E0000 to U+E007F, are inserted inside a word to fragment it. The word "funding" becomes "fun", an invisible character, then "ding" — identical on screen, and no longer the string a filter is matching on.

That block was originally intended for language tagging, was deprecated, and renders as nothing. Which is precisely why it works: it is text that is not text.

The volume

At peak in late February the campaign pushed up to 2.37 million messages a day, declining gradually and dropping off sharply after 15 May 2026.

A cluster of 148 finance-themed sender domains accounted for about 96% of flagged messages, using words like funding, capital, loan, advance and credit, promoting business funding, loans and credit services.

Delivery ran through ActiveCampaign, a legitimate email-marketing platform — which is the part that matters more than the Unicode trick, because sending from a real ESP with real infrastructure is what gets you past reputation checks in the first place.

ActiveCampaign says its moderation systems "detect invisible Unicode characters the same way they detect unobfuscated text and treat heavy use as suspicious."

The number the coverage is burying

Microsoft Defender caught over 99% of these messages.

Not because it stripped the Tags characters, but because the content was never the only signal. Sender reputation, IP analysis and domain checks did the work, and they do not care what the subject line spells.

So the honest description of this campaign is not "attackers defeated email filtering". It is: a technique that defeats exactly one layer, deployed at enormous volume against a defence that has not depended on that layer alone for years.

Which makes the interesting question not "how do I stop ASCII smuggling" but "am I still running keyword and signature matching as a primary control?" If you are — and plenty of smaller gateways, DLP rules and homegrown filters are — this campaign was aimed at you specifically, and 2.37 million messages a day is what aimed looks like.

The same characters point somewhere else

Worth flagging carefully, because it is adjacent rather than observed.

Invisible characters that a human cannot see and a keyword filter cannot parse are the same primitive used for prompt injection against language models that read email. An assistant summarising an inbox, triaging tickets or drafting replies is reading the raw text, Tags block included, and the user reviewing its output sees nothing there.

Nothing in Microsoft's reporting says this campaign targeted AI systems. It did not. But we have already covered a case where the instruction was hidden in a place the human reviewer would not look, and the Tags block is a better hiding place than a comment. Anyone building email automation on top of a model should be stripping this range before the text reaches it, and most are not.

What to do

  • Strip the Tags block on ingest. U+E0000 to U+E007F has no legitimate use in email body text. Removing it is a few lines and closes this technique completely.
  • Normalise before you match. Any keyword rule that runs on raw input is matching a string the attacker controls the encoding of.
  • Check whether you have a layer that is doing this alone. Defender's 99% came from signals other than content; if your only signal is content, you do not have that margin.
  • Alert on heavy use of invisible characters rather than blocking on it. ActiveCampaign's approach is the right one — volume of zero-width and Tags characters is itself the anomaly.
  • If a model reads your mail, sanitise before the model, not after. The output looks clean either way.

What is not established

  • What the payload was. The reporting describes the lure and the evasion, not the ultimate objective.
  • Who ran it. No attribution has been published.
  • Whether it succeeded. No success rate has been reported.
  • Whether other vendors' filters were bypassed. Only Microsoft's telemetry has been described, and it reports catching it.
  • Why it stopped in May. The sharp decline after 15 May is unexplained.