In February 2026, Microsoft threat researchers observed a phishing campaign that at its peak sent 2.37 million malicious emails per day. This was not a novel social engineering tactic or a sophisticated zero-day exploit that made it noteworthy. The attackers had weaponized an invisible string of characters — Unicode from the Tags block — to slip past keyword-based email security filters. The technique, known as ASCII smuggling, had previously been demonstrated in AI prompt injection attacks against large language models. Now it had crossed over into the criminal email ecosystem, and the scale of its deployment forced security vendors and email platform providers to reconsider how they parse text in message bodies.
What Is ASCII Smuggling and How Does It Work in Email Phishing?
ASCII smuggling refers to the practice of encoding text using Unicode characters from the Tags block, a range of code points (U+E0000–U+E007F) that are visually invisible in rendered content. These characters are not displayed by email clients or web browsers, but they remain present in the underlying source code. When a security filter scans an email body for suspicious keywords — like “funding,” “loan,” or “credit” — the presence of an invisible character inserted between letters breaks the string match. A word such as “funding” becomes “fun[invisible character]ding.” The filter sees a sequence it does not recognize as a keyword, while the human recipient sees the word intact.
This is distinct from traditional obfuscation methods, such as replacing letters with lookalike characters from other scripts (homoglyph attacks) or using HTML entities. In those cases, the visual appearance or the underlying structure can still be flagged by more advanced detection engines. ASCII smuggling with Tag block characters is harder to catch because the characters are truly invisible and non-printing. They are part of the Unicode standard originally intended for language tag markup in plain text, a feature rarely used in modern email communication. Their presence is itself anomalous, but many legacy detection systems did not account for them.
The technique was previously demonstrated in the context of AI prompt injection. Attackers could concatenate malicious instructions within text meant for a language model, concealing the attack vector from human review. Microsoft’s detection of the same method in live phishing campaigns represents a significant escalation. The adversary had adapted a theoretical bypass technique into a practical, high-volume evasion tool.
The Scale and Timeline of the Campaign
Microsoft’s telemetry data shows that the campaign’s high-volume phase began around February 9, 2026. For roughly three months, the volume of these specially crafted messages peaked at an average of 2.37 million daily. The technique was in continuous, active use until mid-May 2026, at which point the email volume dropped sharply. Microsoft notes that the campaign itself started earlier than February 9, and it persisted after May 15, but the use of Unicode Tag block characters was confined to that specific window. The attackers appear to have adopted the evasion technique for a sustained period, not as a one-off test.
The drop in volume after May 15 may be attributable to several factors: increased detection from Microsoft Defender for Office 365, ActiveCampaign’s moderation interventions, or the attackers simply rotating their infrastructure and obfuscation methods. The high volume is itself noteworthy. Sending millions of messages per day requires either a large botnet or access to a legitimate email marketing platform. In this case, the attackers used the latter, routing their messages through infrastructure associated with ActiveCampaign, a well-known email marketing service.
Abusing a Legitimate Email Marketing Platform
The campaign did not rely on compromised SMTP servers or spam-sending botnets. Instead, the phishing messages were delivered through ActiveCampaign’s platform. The attackers had established legitimate or fraudulently obtained accounts and used the platform’s native sending infrastructure to distribute their lures. This approach has several advantages: messages sent from reputable marketing platforms have higher deliverability rates, are less likely to be flagged by reputation-based filters, and benefit from established IP warm-up and domain authentication records. For a campaign operating at the scale of millions of messages daily, this infrastructure is critical.
ActiveCampaign was informed of the abuse. According to Microsoft’s report, ActiveCampaign stated that its moderation systems already detect invisible Unicode characters in the same way they detect ordinary text, and that heavy use of such characters is treated as suspicious. It remains unclear precisely when ActiveCampaign’s moderation kicked in relative to the campaign’s peak, or what proportion of the millions of daily messages were blocked at the platform level versus downstream by Defender filters. The incident highlights a persistent vulnerability in the email ecosystem: services designed for legitimate marketing can be weaponized at scale, and reactive abuse reporting from security vendors is often the trigger for action rather than proactive detection.
Source Domains and Lure Themes
Microsoft identified a cluster of 148 sender domains that were powering the campaign on February 9, 2026. These domains accounted for approximately 96% of all messages that Defender flagged for the Unicode Tag block signature. The domains shared a common theme: they incorporated finance-related words such as “funding,” “capital,” “loan,” “advance,” and “credit.” The email messages themselves promoted business funding opportunities, loan offers, and credit services. The alignment between domain name, message content, and the evasive technique suggests a coordinated, well-organized operation.
The use of finance-themed lures is a standard phishing tactic. Financial urgency and the promise of capital are effective psychological triggers for business recipients, particularly in small and medium enterprises where decision-makers may process their own email. By splitting these trigger words with invisible characters, the attackers ensured that simple word-list-based detection — a common first-pass filter in many email security gateways — would not catch the message. The bait was still exposed in the email body for the human reader to see, because their email client rendered the text without the invisible codes.
How Effective Was the Evasion Technique?
Microsoft reports that the method worked as intended for bypassing keyword-based detection. However, the company also states that Microsoft Defender for Office 365 still caught over 99% of these messages by relying on other signals. These signals include sender reputation, IP address analysis, domain age and registration patterns, and behavioral heuristics that do not depend on body text alone. The evasion technique increased the difficulty of detection at the signature level, but it did not defeat a layered defense approach.
This is an important nuance. A headline focused on “invisible Unicode in phishing” might suggest a catastrophic blind spot in email security. In practice, the technique forced security teams to improve their detection logic, but it did not result in widespread compromise. The campaign’s volume, not its per-message effectiveness, was the more striking element. Sending millions of emails means that even a low success rate yields a substantial number of victims. The 1% that bypassed primary defenses could still represent tens of thousands of delivered malicious messages per day at the campaign’s peak.
Why Unicode Tag Block Characters Are a Detection Blind Spot
The Unicode standard includes several blocks of invisible or zero-width characters. The Tag block (U+E0000 to U+E007F) is designed for embedding language tags in plain text, a feature that was part of the Unicode 3.1 specification but is rarely used in practice. Most email security products were not designed to strip or normalize these characters before running keyword, regex, or signature-based detection. The characters are valid Unicode, and they do not visually distort the text. For a detection engine that operates on the plaintext representation of the email body, the invisible characters create a sequence mismatch.
This is not a vulnerability in the Unicode standard itself. It is an implementation gap in the parsing pipeline of security tools. Many products first extract text from the email body, then apply detection rules. If the extraction step does not filter out Tag block characters, every keyword-based rule becomes trivially bypassable. The fix is straightforward: strip or normalize Unicode Tag characters and other invisible code points as part of the preprocessing step. Microsoft explicitly recommends this approach. Normalization should apply to Tag block characters, zero-width joiners, zero-width non-joiners, and other non-printing code points that have no semantic role in standard email communication.
Implications for AI Prompt Injection Detection
The crossover of ASCII smuggling from AI prompt injection to email phishing is not merely a curiosity — it is a signal that the technique is spreading across different attack surfaces. In the context of AI assistants and large language models, attackers can append invisible instructions to user-visible text. If the AI system does not strip invisible characters before processing the prompt, the embedded instructions are executed. The same normalization approach recommended for email filters applies here: strip or normalize Tag block characters before passing any content to an AI model, whether for classification, summarization, or direct response generation.
Security teams that implement normalization for email security should apply the same logic to data pipelines feeding AI systems. Otherwise, an attacker could submit a document, email, or chat message that contains invisible instructions, achieving a prompt injection without leaving visible traces in the original content. The convergence of these two attack vectors makes normalization a cross-domain best practice.
Practical Recommendations for Defenders
Microsoft’s recommendation is unambiguous: strip or normalize Unicode tag characters before applying keyword, regex, or signature-based detection. Organizations should treat unexpected Tag block characters as a strong anomaly indicator, regardless of whether they appear in email bodies, web forms, file uploads, or API inputs. The presence of such characters in an otherwise plain email is almost certainly malicious, as there is no legitimate use case for them in routine business correspondence.
The implementation can occur at several layers:
- Email security gateways: Preprocess message body text to remove or normalize Unicode Tag block characters (U+E0000–U+E007F) and other invisible code points before applying detection rules.
- Web application firewalls and input validation: Apply the same normalization to forms, chat fields, and any other text input channels to prevent injected content from bypassing sanitization filters.
- AI and LLM pipelines: Strip non-printing characters from input text before it reaches the model to prevent prompt injection via invisible instructions.
- Monitoring and alerting: Log instances where Tag block characters are detected as a separate telemetry signal for campaign analysis and threat hunting.
Organizations using Microsoft Defender for Office 365 already have baseline protection because the service uses multiple detection layers. However, the campaign demonstrates that even a 99% catch rate still allows a meaningful volume of malicious messages to reach inboxes when attackers operate at scale. Fine-tuning detection logic at the normalization layer closes one more gap in the defense chain.
What Is the Future of Unicode-Based Evasion in Email Threats?
The use of ASCII smuggling in this campaign marks a clear evolution in phishing obfuscation. Attackers are borrowing techniques from the AI security research community and adapting them to email, which remains the predominant initial access vector for cyberattacks. The technique is not difficult to implement, and the detection gap — improper text normalization — exists in many products. As security vendors patch this gap, attackers will likely rotate to other invisible or visually confusing Unicode blocks, such as variation selectors, zero-width spaces, or combining marks. The lesson is structural: text preprocessing for security applications must account for the full Unicode standard, not just printable ASCII or basic Latin characters.
For defenders, the campaign serves as a case study in the value of layered detection. The attackers successfully bypassed one layer — keyword filters — but were caught by others. The future of email security depends not on any single breakthrough but on the resilience of a multi-signal approach that combines normalization, reputation analysis, behavioral modeling, and threat intelligence. As the tooling available to attackers improves, the margin for error in defense narrows. Invisible characters are just one example of a wider trend: the exploitation of legitimate technical standards to evade detection at scale.
