Invisible Unicode Characters Are the Latest Trick to Slip Phishing Emails Past Filters

On 4 September 2026, security researchers at Microsoft published the analysis of a phishing campaign that should worry anyone who assumes their email filtering is a solved problem. Between February and at least mid-June 2026, attackers pushed millions of financial-lure phishing messages past keyword and signature-based filters using nothing more sophisticated than characters that cannot be seen. At its peak, on 26 February 2026, the campaign moved more than 2.37 million messages in a single day. The messages looked entirely normal to the human eye. To the filter, the words the filter was hunting for simply were not there.

The technique is called ASCII smuggling, and Microsoft’s researchers Noam Kochavi and Sarah Wolstencroft documented it in detail. Attackers inserted invisible Unicode tag characters - code points such as U+E0020, which occupy space in the byte stream but render as nothing at all - between the letters of the words most likely to trip a security rule. A message about funding was written as fun[invisible character]ding. A recipient reads “funding”. A literal keyword match, a regular expression, or a signature built to spot financial-lure language reads two meaningless fragments and lets the message through. There is no exploit here, no vulnerability, no CVE to patch. The attackers found the gap between what a filter compares and what a person sees, and walked several million messages through it.

What makes this campaign significant beyond its volume is where the technique came from. ASCII smuggling has been discussed for the past two years almost entirely as an AI security problem - a way to bury hidden instructions inside a webpage, a document or a support ticket so that a large language model reading the content obeys commands the human operator never sees. This campaign used the same primitive for something far more mundane and far more widely damaging: getting ordinary phishing email into ordinary inboxes. As Microsoft’s researchers put it, “as AI-era attack methods become better understood, threat actors may adapt them for use in more traditional threats such as phishing and spam”. For UK organisations running Microsoft 365 with default or lightly tuned mail protection, the practical lesson is that a technique invented to fool a chatbot has already been repurposed to fool the email gateway you have been relying on since 2019.

What Microsoft’s researchers actually found

Microsoft first detected the ASCII-smuggling signature on 8 February 2026, when roughly 21,000 messages matched it. That is a small number by the standards of global email telemetry - the sort of figure that could easily be a test run, a misconfiguration or noise. It was a test run. The following day, 9 February, the same signature matched more than 1.3 million messages. The campaign had gone from a rounding error to industrial scale in twenty-four hours, which tells you the infrastructure was already built, already provisioned and simply waiting for the operator to confirm that the evasion worked.

The mechanism is worth being precise about, because the imprecise version of it invites the wrong fix. Unicode reserves a block of code points known as tag characters, running from U+E0000 to U+E007F. They were originally introduced to carry language tags inside plain text and have been effectively deprecated for that purpose for decades. They are not control characters in the classic sense, they are not whitespace, and critically they have no visible glyph. Most text renderers - including the ones in Outlook, in webmail clients and in mobile mail apps - draw nothing at all when they encounter one. But they are still real code points, still present in the message body, and still counted by any process that compares strings byte for byte or character for character.

So when an attacker writes the word funding with a U+E0020 dropped between the third and fourth characters, three things happen simultaneously. The recipient sees the word funding, unbroken and unremarkable. The filter, if it is matching on the literal string funding, sees no match, because the string in the message is fun + invisible code point + ding. And any downstream regular expression built around the same term - the sort of rule that has accumulated in mail hygiene configurations over years of tuning - also fails to fire. Multiply that across every high-signal financial term in the lure vocabulary (invoice, payment, remittance, transfer, account, wire, funding, settlement) and a message that should light up half a dozen detections arrives looking, to the rules engine, like unremarkable prose.

The senders themselves were not especially clever. Microsoft attributes the bulk of the traffic to around 150 finance-themed sender domains - a domain pool chosen to look plausible against the lure content rather than to be individually hard to attribute. And the campaign kept office hours. Microsoft observed a distinctive weekday-on, weekend-off sending pattern, which the researchers explicitly flag as a behavioural indicator defenders can watch for. That detail matters more than it sounds. It means the operation was run by people working shifts, and it means that a defender who cannot detect the content can still detect the rhythm - a sender domain that transmits heavily Monday to Friday and goes silent every Saturday and Sunday is behaving like a business, and if it is not one of your suppliers, that is a signal in itself.

How the campaign unfolded

The chronology below is drawn from Microsoft’s telemetry as reported on 4 September 2026. It is a useful shape to understand, because it is the shape of a campaign that was tested, scaled, sustained, throttled and then kept warm - not one that was launched and abandoned.

The shape of the traffic

Understanding the volume profile matters because it determines what your own logs would have looked like at each stage. The bars below express the campaign’s reported daily volumes as a proportion of its 2.37 million peak on 26 February 2026. Where Microsoft reported a range or a percentage step-down rather than an absolute figure, the bar reflects the midpoint of that range; the weekend figure is derived from the weekday-on/weekend-off pattern the researchers describe rather than a published number.

Two things jump out of that profile. The first is the distance between the bottom bar and the one above it. The gap between 21,000 messages and 1.3 million is the gap between an operator checking that a technique works and an operator committing to it. If your organisation had received a handful of these messages on 8 February, nothing in your reporting would have flagged them; by 9 February you were in the path of a campaign that had already been validated against production filters and found to work.

The second is that the campaign never actually ended. The bars for late March, mid-May and mid-June describe a technique that has been throttled rather than retired. Invisible-character insertion costs an attacker essentially nothing - it is a string manipulation applied at send time, requiring no new infrastructure, no zero-day and no purchased access. There is therefore no economic pressure to stop using it. It will sit in the toolkit and be reached for whenever a lure needs to clear a keyword-based control, which for most UK organisations means it is a permanent feature of the threat landscape from now on rather than an incident with an end date.

The number that decides whether these messages reach your staff

Almost every discussion of this campaign gravitates towards the 2.37 million figure. That is the wrong number to plan against, because it describes the attacker’s capacity rather than your exposure. The number that determines whether any of those messages land in front of your finance team is much less glamorous: whether your mail-processing chain normalises Unicode before it evaluates content. Based on the tenant configurations we see across UK SMEs - organisations typically running Microsoft 365 Business Premium or an equivalent, with mail hygiene tuned incrementally over several years and often by more than one supplier - that number is low.

Eighteen per cent is low, and the reason is structural rather than negligent. Custom transport rules, keyword blocks and content filters are written by people solving a specific problem on a specific afternoon - a supplier being spoofed, a wave of invoice fraud, a compliance requirement to flag certain terms. They get written, they work, and they are never revisited, because nothing about them fails visibly. A rule that stops matching does not raise an alert. It simply stops contributing, silently, and the tenant carries on looking configured. ASCII smuggling exploits precisely that silence: every rule that was ever written against a literal financial term is, against this technique, already switched off, and no dashboard anywhere is telling you so.

The other contributor is layering. A typical UK SME mail path is not one product. It may be a third-party gateway in front of Exchange Online Protection, plus Defender for Office 365, plus a handful of tenant-level transport rules, plus an archiving or data-loss-prevention product tapping the same stream. Each of those layers does its own parsing. Normalisation applied at one layer does not propagate to the others, so it is entirely possible - common, in fact - for the modern reputation-and-behaviour layer to be doing sensible things with Unicode while the custom rules sitting behind it are still comparing raw strings. The question to ask your IT provider is not “are we protected against ASCII smuggling” but “at which layer is text normalised, and which of our controls run before that point”.

Where the gaps usually sit

The assessment below reflects what we most commonly find when we review mail protection for a UK organisation of between ten and two hundred staff. It is not a scoring of Microsoft’s platform, which handles this technique well in its modern detection layers - it is a scoring of the configuration around the platform, which is where the exposure to invisible-character evasion actually lives.

The pattern in those badges is the argument of this article in miniature. The high-risk items are all things a human wrote, in a rules engine, against literal text - and every one of them is defeated by a code point that renders as nothing. The low-risk item is the layer that does not depend on matching words at all: reputation, sending behaviour, authentication posture, link detonation, and the sheer statistical weight of seeing the same infrastructure across a global estate. That is why Microsoft caught this campaign at all. It is also why a defence strategy weighted towards content rules and away from behavioural signal is exactly the wrong shape for 2026.

The middle band is where most organisations can make the fastest progress, because it does not require a platform change. Out-of-band verification of payment and bank-detail changes - a phone call to a known number, never a number supplied in the message - defeats a financial-lure phish regardless of how the message got through the filter. It is the single control that is entirely indifferent to the evasion technique used, and it costs nothing but a documented procedure and the organisational permission for a junior finance colleague to delay a payment while they check.

What proportionate protection costs

Figures below are indicative first-year costs for a UK organisation addressing this class of exposure properly - reviewing and rebuilding content rules on normalised text, adding behavioural detection where it is absent, and putting the process controls in place that make filter evasion irrelevant. They assume a Microsoft 365 tenant already in place and exclude the base licence cost.

The costs at the smaller end are deliberately modest because the highest-value action for a small organisation is subtractive rather than additive. Most SME tenants are carrying content rules that no longer match anything, that nobody remembers writing, and that create a false sense of coverage. Removing them, and replacing the genuine requirement with a control that operates on normalised text or on behaviour rather than vocabulary, is cheaper than buying another layer - and it removes the specific illusion that this campaign exploited.

Two postures towards filter evasion

The distinction between the two columns is not budget. Several of the proactive items cost nothing beyond the decision to do them and the discipline to keep doing them. The distinction is whether email protection is treated as a product you have bought or a configuration you maintain. This campaign is a clean demonstration of the difference: Microsoft’s platform detected and reported it at global scale, while individual tenants’ hand-written rules were being walked past silently, and both of those things were true inside the same product at the same time.

Thirty-eight is a mid-to-low score, and it is assembled from a consistent split. Organisations tend to score reasonably on the parts of the problem the platform solves for them - modern cloud mail protection is genuinely good, and a tenant on Business Premium with Defender for Office 365 enabled inherits detection capability it did not have to configure. They score poorly on everything that depends on their own decisions: the rule estate nobody has audited, the architecture nobody has mapped, the DLP policy written in 2021 against a list of words, and the absence of any mechanism that would tell them a control had gone quiet.

The number moves quickly, though, which is the encouraging part. Of the eight items in the score grid above, four can be addressed inside a single engagement of a few days - an audit of the rule estate, documentation of the mail path, removal of controls that no longer serve a purpose, and a written out-of-band verification procedure. None of those requires a licence change, a migration, or downtime. They require somebody to open the configuration and look at it with this specific failure mode in mind.

At a glance

The pattern this fits into

This campaign is not an isolated curiosity. It belongs to a run of stories over the past few months in which the common thread is an attacker stepping around a control rather than breaking it, and a defender discovering after the fact that the control had a boundary nobody had written down. In August we covered the first UK conviction for operating an SMS Blaster, where a fake mobile mast delivered fraudulent texts directly to handsets and every operator-level filter in the country was simply not in the path - structurally the same failure as an invisible code point routing around a keyword rule. The debate over proposed UK AI kill-switch legislation is the policy end of the same question this campaign raises technically: what happens when techniques developed in AI security research escape into general cybercrime, and who is accountable for the gap.

On the infrastructure side, our reporting on accountability for UK business broadband faults and on continuity risk in the Gamma and Epiris buyout both come back to the same discipline that this story demands: knowing, in writing, which supplier owns which layer, and what each layer actually does. And the widening 5G and AI connectivity gap is the backdrop to all of it - organisations adopting capability faster than they are documenting the controls that surround it. If there is one operating principle running through the whole sequence, it is that undocumented assumptions are the most expensive things in an IT estate, and that they only ever bill you once something has already gone through them.

Frequently asked questions

CloudSwitched

London-based managed IT services provider offering support, cloud solutions and cybersecurity for SMEs.