Phishing Detection Evasion Using Invisible Unicode Characters to Split Financial Terms

1. Basic Information

• Article Title: ASCII smuggling crosses over from AI prompt injection to phishing evasion
• Publisher: Microsoft Security Research
• Publication Date: 2026-09-03
• Source: Microsoft Security Blog
• Related Information Sources: BleepingComputer
• Related Malware, Threat Groups, CVEs, Products: ASCII Smuggling, Unicode Tags block, Microsoft Defender for Office 365, ActiveCampaign
• Severity: High (evaluated in this report)
• Evaluation Reason: This report assigns a high severity due to high-volume distribution and the impact on pre-detection processing. More than 99% of the target emails are detected in Microsoft environments; this rating does not indicate a successful compromise rate.

2. Executive Summary

Financial phishing emails used a technique on a large scale to bypass keyword detection by inserting non-display characters into words such as funding. Microsoft observed a peak of 2.37 million emails in a single day, but Defender for Office 365 detected over 99% of the target emails through other detection layers.

3. Attack Flow

Unicode Tags block covers the character code range U+E0000 to U+E007F. Most tag characters in this range are not visible on standard screens. U+E0020, used in this campaign, is one of them.

1. Attackers use multiple sender domains combining words that suggest loans or business funding.
2. The invisible Unicode tag character U+E0020 (TAG SPACE) is inserted into words such as funding in the email body. This results in funding becoming fun〈U+E0020〉ding, but it appears as funding to the recipient. Angle brackets indicate the positions of invisible characters for explanation purposes.
3. Emails are delivered from the infrastructure of ActiveCampaign, a legitimate email marketing service, and the links in the email body pass through the service's click-tracking domain.
4. Detections that match without processing inserted characters fail to match the continuous string funding. This may also affect tokenization for machine learning (the process of splitting text into processing units such as words or parts of words).

4. Attacker Position and Execution Location

• Attackers contact recipients as email senders and manipulate text strings in the email body that are subject to detection.
• Microsoft identified 148 finance-related sender domains on February 9, 2026. The shared infrastructure of ActiveCampaign was used for delivery, but this does not indicate a compromise of the service itself.
• The investigated emails used invisible characters as word boundaries and did not encode hidden instructions for AI.

5. Victim and Administrator Perspectives

Victims

• The email body offering funding or loans looks like normal text, making it difficult to identify invisible characters within words by visual inspection alone.
• Links use the click-tracking domain of a legitimate service, so the domain alone does not reveal the final destination.

Administrators

• Decoding the email body to visualize character codes reveals U+E0020 within words. Displaying raw data normally may cause invisible characters to be overlooked.
• The P1 sender is the delivery sender specified by SMTP MAIL FROM, while the P2 sender is the display sender in the email From header. Distinguish between both senders, the sender IP, and the click-tracking domain. The difference between P1 and P2 can occur even in legitimate delivery.
• Because the EmailEvents table used in Microsoft's public hunting examples does not contain a body column, queries use characteristics such as senders and URLs.

6. Success and Failure Conditions

Success Conditions

• To bypass keyword detection, the inserted characters must remain until the matching phase, and the detection mechanism must not account for character insertion. The impact on machine learning depends on preprocessing and the model.
• For email delivery, other defense layers such as sender and URL evaluation must not quarantine or block the message. Delivery or link interaction alone does not indicate successful information theft or endpoint compromise.

Failure Conditions and Risk Mitigation

• Preserve the original email, record the positions of invisible characters, and explicitly remove the target Unicode tag characters from the subject and body used for detection. Standard Unicode normalization such as NFC and NFKC does not remove U+E0020.
• When detecting anomalous tag characters, exclude valid character sequences such as flag emojis for England, Scotland, and Wales. Do not exclude entire emails containing flag emojis from detection targets.
• Combine evaluations of senders, delivery source IPs, URLs, authentication results, and OCR (reading text from displayed images).
• Target characters can also be removed before AI input, but this only mitigates the risk of concealment using these characters. It is not a countermeasure against general indirect prompt injection.

7. What Happens Upon Success

• In strings containing invisible characters, simple keyword matching fails, and tokenization results may change.
• Microsoft detected over 99% of the target emails using other detection layers. This figure alone does not indicate whether the remainder reached the inbox or resulted in a successful compromise.

8. Observable Logs

• Email: Invisible characters can be verified in the subject and body of the original email. Delivery logs can confirm P1/P2 senders, sender IPs, authentication results, and delivery or quarantine verdicts, but do not guarantee that the email body is retained.
• Proxy/SWG/DNS: Inference: Proxy/SWG logs can confirm destination URLs depending on acquisition settings and HTTPS visibility. HTTP responses and browser records can track redirect relationships. DNS logs show queried domains and responses, but do not reveal URL paths or HTTP redirects. acemlnd[.]com and activehosted[.]com are shared domains of legitimate services, and access alone does not indicate maliciousness.
• Endpoint/EDR: Inference: If user activity is suspected, cross-reference acquired browser history, file creation, and process execution records. File acquisition and execution are distinct pieces of evidence.
• Identity/IdP: Inference: If information entry is suspected, cross-reference sign-in results and session records. The source information does not indicate successful credential theft.
• SaaS/Cloud: Inference: On the receiving side, investigate email delivery, quarantine, and user reports. Sender accounts and campaign records on the delivery service side are not logs normally accessible by receiving-side administrators.
• Network: Inference: Depending on the capture environment, confirm destination IPs and timestamps for SMTP and Web traffic. Email bodies or HTTP transfer destinations in encrypted traffic cannot be confirmed through standard connection logs alone. Do not use shared infrastructure IP ranges as the sole basis for blocking.

9. Determining Attack Success

The following distinguishes between observed results and conditions for evaluating unconfirmed stages.

• Attack Attempt Observed (Success Unconfirmed): Microsoft observed finance-related phishing emails containing invisible tag characters and detected over 99% of the target emails using other detection layers. The number of user interactions and successful compromises has not been published.
• User Interaction Confirmed: Unconfirmed in this source information. Evaluation requires cross-referencing browser records and timelines, ensuring that automated access by email inspection services is not confused with clicks by the user.
• Initial Execution Confirmed: Unconfirmed in this source information. File acquisition alone does not confirm execution. Determining execution requires process records showing the execution of acquired files or scripts, along with evidence tied to the email.

10. Investigation Playbook

Inference: This is an investigation proposal based on observed emails and detection evasion techniques.

• Trigger: Initiate based on the detection of invisible tag characters or a combination of finance-related senders and delivery infrastructure characteristics.
• Initial Verification: Preserve the original email and check the body character code, P1/P2 senders, message identifier, authentication results, URLs, and delivery verdict.
• Endpoint: If there is link access, differentiate between automated inspection and user interaction. If files are downloaded, separately confirm evidence of file acquisition and execution.
• Authentication/Cloud: If credential entry is suspected, investigate sign-ins and sessions. If unauthorized access occurs, expand the investigation to mailbox operations.
• Subsequent Activity: Investigate subsequent damage based on evidence of information entry, execution, and unauthorized access. Do not infer malware execution or lateral movement based solely on email detection.
• Containment: Search for and quarantine confirmed malicious emails, and block malicious final destinations. If credential entry or unauthorized sign-ins are confirmed, reset passwords and invalidate sessions.
• Verdict Classification: Record email delivery, user link interaction, information entry, file acquisition, code execution, and unauthorized access separately.

11. Defense and Detection Ideas

Inference: The following are application proposals for operations.

• Single Event: Exclude valid flag emoji character sequences and record Unicode tag characters in the body as anomalies.
• Time-Series Correlation: Combine invisible characters, finance-related sender domains, P1 senders, and tracking URLs. Do not judge maliciousness based solely on delivery infrastructure characteristics.
• Threat Hunting: Narrow down emails within the retention period using P1 sender subdomains in the format em-\d+\., shared infrastructure in the format acems<N> or emsd<N>, and finance-related sender names. N represents a number. Differentiate between the invisible character usage period starting February 9, 2026, and broader campaigns before and after.
• Log Gaps: Link delivery logs that do not retain email bodies to preserved original emails. Maintain separate data for recording invisible characters and matching data with characters removed.
• Priority Mitigations: Do not rely solely on applying NFC and NFKC normalization; confirm whether funding can be matched after explicitly removing U+E0020. Combine preprocessing with multiple detection layers.

12. Facts / Inference / Hypothesis

Facts

• Microsoft observed finance-related phishing emails that insert invisible Unicode tag characters into words. In the investigated emails, U+E0020 was used as word separators.
• Detection signature counts increased from approximately 21,000 on February 8, 2026, to over 1.3 million on February 9. The peak count for the tracked activity was 2.37 million on February 26.
• 148 finance-related sender domains were identified on February 9. Microsoft stated that finance-related sending patterns accounted for approximately 96% of hunting detection volume.
• High-volume mailing using these invisible characters dropped sharply after May 15, with small-scale activity persisting through mid-June. This does not signify the end of the broader campaign.
• Defender for Office 365 detected over 99% of the target emails through detection layers that do not rely on direct detection of invisible characters.

Inference

• Email detection and AI input processing can share the removal of target invisible characters. However, this does not prevent general indirect prompt injection against AI.
• Combining characteristics of the email body, sender, and URL minimizes the impact on legitimate use compared to a blanket block of shared delivery infrastructure.

Hypothesis

No additional hypotheses. Unconfirmed items are listed in "Unknowns and Further Investigation."

13. MITRE ATT&CK Mapping

• T1566.002 Phishing: Spearphishing Link (High): Emails containing finance-related lures and links are delivered.
• T1027 Obfuscated Files or Information (High): Invisible Unicode characters are inserted into words to obfuscate text strings handled by detection processing.

14. Unknowns and Further Investigation

• Specific landing content of links and actual damage.
• Number of receiving organizations, user link interactions, and successful information entries or compromises.
• How attackers obtained ActiveCampaign accounts and sending capabilities.
• Processing and detection status of invisible tag characters in various email products.
• Detailed activity volume and technique changes after mid-June.

15. Impact on SOCs and Organizations

When text containing invisible characters is matched without removal, words with identical visual appearances fail to match keyword detection. For organizations operating custom rules or email parsing, it is important to verify not only whether standard Unicode normalization is applied, but also whether U+E0020 can be explicitly removed prior to matching. Preserving originals and invisible character positions also aids in investigating attack characteristics that disappear after preprocessing.

Countermeasures against concealment using these characters can also be applied to AI models that summarize and classify emails. However, email detection evasion measures and the reliability assessment of AI instructions must be verified independently.

Microsoft detected over 99% of target emails through other detection layers. Evaluating body manipulation alongside sender and URL characteristics—and proceeding to endpoint and authentication investigations when user link interaction or information entry is confirmed—is a practical operational approach.

16. Summary by Role

• For SOCs: Correlate invisible characters with delivery and URL characteristics; separate evidence for email delivery, user interaction, and compromise.
• For Administrators: Preserve originals, implement and verify anomaly detection for target tag characters, and explicitly remove them from detection copies.
• For Users: Do not trust loan or funding notices based on appearance alone; report suspicious messages without opening links.