Invisible Unicode Phishing: Detecting and Blocking ASCII Smuggling Lures in Your Email Security Stack

Threat actors are now embedding invisible Unicode characters into phishing emails — a technique known as ASCII smuggling — to conceal malicious lures from email security filters while remaining fully invisible to the human recipient. Recent reporting from BleepingComputer confirms this technique has moved from academic curiosity into active social engineering campaigns.

This matters because the entire detection philosophy of most secure email gateways (SEGs), spam filters, and even many ML-based classifiers rests on inspecting visible and machine-readable content: keywords, URLs, brand impersonation strings, and attachment hashes. ASCII smuggling breaks that assumption. An attacker can spell out "Microsoft account suspended" or embed URL fragments using characters that render as nothing on screen but fragment every keyword signature your filter relies on. Worse, the same invisible payloads can act as prompt injection against any LLM-assisted tooling in your mail flow — summarization assistants, AI triage copilots, and automated response platforms can read instructions your analysts never see.

If your SOC's phishing detection assumes that what the user sees is what the filter scanned, you have a gap. This post breaks down the technique, gives you production-ready detections, and lays out hardening steps you can implement this week.

Technical Analysis

What ASCII Smuggling Actually Is

ASCII smuggling exploits two families of Unicode code points that carry zero visual weight in standard rendering:

1. The Unicode Tags block (U+E0000 – U+E007F) — originally defined for language tagging (e.g., U+E0041 is a tag version of "A"). These characters are deprecated for general use, render as nothing in virtually all fonts, but map predictably to ASCII. An attacker can encode an entire sentence — a phishing lure, a credential-harvesting URL, or an LLM instruction — as a string of tag characters appended to an otherwise clean-looking email.
2. Zero-width and formatting characters — U+200B (zero-width space), U+200C (zero-width non-joiner), U+200D (zero-width joiner), U+2060 (word joiner), and U+FEFF (byte order mark / zero-width no-break space). Inserted between every letter of a keyword — p​a​s​s​w​o​r​d — they defeat naive substring and token-based matching while remaining visually identical to the clean string.

How the Attack Chain Works (Defender's View)

The observed campaign pattern follows a consistent chain:

1. Delivery: The victim receives an email that passes SPF/DKIM/DMARC (frequently sent from compromised legitimate infrastructure or reputable ESPs). The visible body is benign or minimally suspicious.
2. Filter evasion: Invisible characters are interleaved into lure text (brand names, urgency keywords like "verify", "suspended", "invoice") or used to smuggle entire encoded instructions in the Tags block. Keyword-based SEG rules, Bayesian filters, and URL-reputation extraction logic fail to tokenize the obfuscated content.
3. Optional LLM exploitation: Where organizations use AI assistants to summarize or triage email, the invisible tag-encoded text is faithfully read by the model. Researchers originally demonstrated this as a prompt-injection vector — the model can be silently instructed to include attacker-controlled links in summaries or misrepresent the email's risk.
4. Execution: The user clicks a link that either appeared clean to the filter or was reconstructed at render time, landing on a credential harvester or a malware staging page.

Affected Products and Platforms

This is a technique, not a CVE — no patch exists because no single product is "vulnerable" in the traditional sense. The exposure surface includes:

• Secure email gateways and spam filters that do not normalize or strip non-rendering Unicode before content inspection (the majority of keyword/signature-driven engines).
• Cloud email platforms (Microsoft 365, Google Workspace) where default anti-phishing policies may not flag zero-width obfuscation.
• LLM-integrated email tooling — AI summarizers, triage copilots, and automated response agents that process raw message bodies.
• DLP and CASB content inspection performing keyword matching on unnormalized text.

Exploitation Status

Per the BleepingComputer report, this technique is observed in active social engineering campaigns — it is not theoretical and not confined to research demonstrations. There is no CISA KEV entry and no CVE (correctly so — this is protocol/parser ambiguity abuse, similar in spirit to homoglyph attacks and HTML comment obfuscation that preceded it). Expect adoption to accelerate because the cost to the attacker is near zero and the bypass is broadly effective against legacy filtering.

Detection & Response

The defensive principle is simple: detect the presence of non-rendering Unicode where it has no legitimate business existing. Zero-width joiners are legitimate in some Indic and Arabic-script text, and U+FEFF appears at the start of UTF-8 files — but the Unicode Tags block has essentially zero legitimate use in email, command lines, or documents in 2026. High-confidence detection is achievable.

Sigma Rules

---
title: Invisible Unicode Characters in Process Command Line
description: Detects zero-width or Unicode Tags block characters in process command lines, consistent with ASCII smuggling / obfuscated payloads executed after phishing delivery.
references:
  - https://www.bleepingcomputer.com/news/security/attackers-conceal-phishing-lures-using-invisible-unicode-characters/
  - https://attack.mitre.org/techniques/T1027/
author: Security Arsenal
id: 3f8a2c71-9d4b-4e6a-b1c5-7a2e9f0d4b8c
status: experimental
date: 2026/02/13
tags:
  - attack.defense_evasion
  - attack.t1027
  - attack.t1027.010
logsource:
  category: process_creation
  product: windows
detection:
  selection_tags_block:
    CommandLine|contains:
      - "\u{e0001}"
      - "\u{e0020}"
      - "\u{e0041}"
      - "\u{e007f}"
  selection_zero_width:
    CommandLine|contains:
      - "\u{200b}"
      - "\u{2060}"
      - "\u{feff}"
  condition: 1 of selection_*
falsepositives:
  - Rare; zero-width joiners may appear in command lines referencing files with Indic or Arabic script names. U+200D is excluded from this rule for that reason.
level: high
---
title: Invisible Unicode Obfuscation in PowerShell Script Block
description: Detects PowerShell script blocks containing Unicode Tags block or zero-width characters, indicating obfuscated script content potentially decoded from smuggled payloads.
references:
  - https://www.bleepingcomputer.com/news/security/attackers-conceal-phishing-lures-using-invisible-unicode-characters/
  - https://attack.mitre.org/techniques/T1059/001/
author: Security Arsenal
id: 8c1e5b04-2a7f-4d39-9e61-0b3c6f8a2d47
status: experimental
date: 2026/02/13
tags:
  - attack.execution
  - attack.t1059.001
  - attack.defense_evasion
  - attack.t1027
logsource:
  product: windows
  service: powershell
detection:
  selection:
    ScriptBlockText|contains:
      - "\u{e0001}"
      - "\u{e0041}"
      - "\u{200b}"
      - "\u{2060}"
      - "\u{feff}"
  condition: selection
falsepositives:
  - Legitimate scripts handling multilingual data with zero-width joiners (U+200D excluded here). The Tags block range (U+E0000-U+E007F) has no legitimate use in scripts.
level: high

Analyst note on tuning: The Unicode Tags block detection is near-zero false positive in Western enterprise environments — treat any hit as investigation-worthy. For the zero-width selections, baseline hosts servicing multilingual content (localization teams, translation workflows) before deploying at high severity globally.

KQL — Microsoft Sentinel / Defender

This query hunts inbound email in Defender for Office 365 where the subject or sender display fields contain invisible Unicode, and correlates with gateway-ingested logs in Sentinel for body-level detection. Tag-block characters in any email field are a strong malicious signal.

// Hunt 1: Invisible Unicode in email metadata (Defender Advanced Hunting)
// Tag block U+E0000-U+E007F has NO legitimate use in email — high confidence.
// Zero-width chars in Subject are suspicious outside multilingual orgs.
EmailEvents
| where TimeGenerated > ago(7d)
| where Subject matches regex @"[\x{200B}\x{200C}\x{2060}\x{FEFF}\x{E0001}-\x{E007F}]"
   or SenderDisplayName matches regex @"[\x{200B}\x{200C}\x{2060}\x{FEFF}\x{E0001}-\x{E007F}]"
| extend DetectionType = case(
    Subject matches regex @"[\x{E0001}-\x{E007F}]", "UnicodeTagsBlock-HighConfidence",
    Subject matches regex @"[\x{200B}\x{200C}\x{2060}\x{FEFF}]", "ZeroWidth-MediumConfidence",
    "SenderField")
| project TimeGenerated, NetworkMessageId, Subject, SenderFromAddress, SenderDisplayName,
          RecipientEmailAddress, DetectionMethod, DetectionType, UrlCount, AttachmentCount
| order by TimeGenerated desc;

// Hunt 2: Gateway/Syslog-ingested mail logs in Sentinel — body-level tag block detection
// Use when your SEG forwards message metadata/content snippets via CEF/Syslog.
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where DeviceVendor contains "email" or DeviceProduct contains "gateway" or DeviceProduct contains "SEG"
| where Message matches regex @"[\x{E0001}-\x{E007F}]"
| extend InvisibleCharCount = countof(Message, "\x{E0001}")
| project TimeGenerated, SourceIP, DeviceProduct, Message, InvisibleCharCount
| order by TimeGenerated desc;

// Hunt 3: Post-delivery — endpoints where a mail client spawned a script interpreter
// shortly after email arrival (behavioral corroboration of lure success)
DeviceProcessEvents
| where TimeGenerated > ago(24h)
| where InitiatingProcessFileName in~ ("OUTLOOK.EXE", "msedgewebview2.exe", "chrome.exe", "firefox.exe")
| where FileName in~ ("powershell.exe", "pwsh.exe", "wscript.exe", "cscript.exe", "mshta.exe", "cmd.exe")
| project TimeGenerated, DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine, AccountName
| order by TimeGenerated desc

Velociraptor VQL

When you identify a suspected smuggled message, pull the raw .eml from quarantine or the mail store onto an analysis host and sweep it with Velociraptor. This artifact hunts .eml files containing non-rendering Unicode and reports hit density — a single U+FEFF at byte offset 0 is normal (UTF-8 BOM); a dozen U+E0041 characters is a smuggled payload.

-- Hunt exported .eml / .msg-exported mail files for invisible Unicode (ASCII smuggling)
-- Deploy against a quarantine export directory or mail archive mount.

LET files = SELECT FullPath, Size, Mtime
  FROM glob(globs='/**/*.eml', root='D:/mail_quarantine_export')
  WHERE Size < 5000000

SELECT FullPath, Size, Mtime,
       count(string=read_file(filename=FullPath) =~ '\x{e0001}') AS TagBlock_SOHits,
       length(list=parse_regex(
           file=FullPath,
           regex='[\x{e0000}-\x{e007f}]')) AS TagBlockChars,
       length(list=parse_regex(
           file=FullPath,
           regex='[\x{200b}\x{2060}\x{feff}]')) AS ZeroWidthChars
FROM files
WHERE TagBlockChars > 0 OR ZeroWidthChars > 2

Note: ZeroWidthChars > 2 is deliberately tolerant — occasional U+FEFF/ BOM artifacts are normal. The Tags block range (\x{e0000}-\x{e007f}) is the high-fidelity signal; any hit warrants decoding the content by subtracting 0xE0000 from each code point to recover the smuggled ASCII string.

Verification & Hardening Script

Use this PowerShell script to (a) scan exported .eml files for invisible Unicode, (b) decode any Tags-block payload for analyst review, and (c) verify whether your Exchange Online transport stack has a rule stripping or flagging these characters.

# ============================================================
# ASCII Smuggling Detector & Exchange Online Hardening Check
# Security Arsenal - run on an analysis host or Exchange admin box
# ============================================================

$ScanPath   = "C:\MailQuarantine\Export"   # adjust to your export path
$ReportPath = "C:\Temp\AsciiSmugglingReport_$(Get-Date -Format yyyyMMdd_HHmm).csv"

# --- Define invisible character sets ---
$zeroWidth  = [char]0x200B, [char]0x200C, [char]0x2060, [char]0xFEFF
$tagStart   = 0xE0000; $tagEnd = 0xE007F

function Test-InvisibleUnicode {
    param([string]$Content)
    $zwHits  = 0
    foreach ($c in $zeroWidth) { $zwHits += ([regex]::Matches($Content, [regex]::Escape([string]$c))).Count }
    $tagChars = [regex]::Matches($Content, '[\uE000-\uE07F]')   # BMP view; tag block appears as surrogates
    [pscustomobject]@{ ZeroWidthHits = $zwHits; TagBlockHits = $tagChars.Count; TagChars = $tagChars }
}

function Decode-TagBlock {
    param([string]$Content)
    $sb = New-Object System.Text.StringBuilder
    foreach ($m in [regex]::Matches($Content, '[\uE000-\uE07F]')) {
        $code = [char]::ConvertToUtf32($Content, $m.Index)
        if ($code -ge 0xE0001 -and $code -le 0xE007F) {
            [void]$sb.Append([char]($code - 0xE0000))
        }
    }
    $sb.ToString()
}

# --- 1. Sweep exported .eml files ---
$results = foreach ($f in Get-ChildItem $ScanPath -Filter *.eml -Recurse -ErrorAction SilentlyContinue) {
    $raw  = Get-Content $f.FullName -Raw -Encoding UTF8
    $test = Test-InvisibleUnicode -Content $raw
    if ($test.TagBlockHits -gt 0 -or $test.ZeroWidthHits -gt 2) {
        [pscustomobject]@{
            File           = $f.FullName
            ZeroWidthHits  = $test.ZeroWidthHits
            TagBlockHits   = $test.TagBlockHits
            DecodedPayload = if ($test.TagBlockHits -gt 0) { Decode-TagBlock -Content $raw } else { "" }
            Verdict        = if ($test.TagBlockHits -gt 0) { "HIGH-CONFIDENCE SMUGGLING" } else { "SUSPECT" }
        }
    }
}
$results | Export-Csv $ReportPath -NoTypeInformation
$results | Format-Table -AutoSize

# --- 2. Verify Exchange Online transport rule coverage ---
# Requires ExchangeOnlineManagement module and an established EXO session.
# Look for a rule that blocks/quarantines messages with zero-width characters.
try {
    $rules = Get-TransportRule | Where-Object {
        $_.SubjectOrBodyMatchesPatterns -match 'u200B|u200C|u2060|uFEFF|E0001' -or
        $_.ContentMatchesPatterns       -match 'u200B|u200C|u2060|uFEFF|E0001'
    }
    if ($rules) {
        Write-Host "[OK] Found transport rule(s) addressing invisible Unicode:" -ForegroundColor Green
        $rules | Select-Object Name, State, SubjectOrBodyMatchesPatterns | Format-List
    } else {
        Write-Host "[GAP] No transport rule detected filtering invisible Unicode." -ForegroundColor Red
        Write-Host "      Create a mail flow rule: apply regex '[^\x00-\x7F]' inspection on body for" -ForegroundColor Yellow
        Write-Host "      zero-width chars (\u200B \u200C \u2060 \uFEFF) -> quarantine or prepend warning." -ForegroundColor Yellow
    }
} catch {
    Write-Host "[SKIP] Exchange Online check failed - connect first: Connect-ExchangeOnline" -ForegroundColor Yellow
}

# --- 3. Quick self-test: does YOUR mail client render these invisibly? ---
$demo = "H$([char]0x200B)e$([char]0x200B)l$([char]0x200B)lo"
Write-Host "`nSelf-test string (should render as 'Hello' with hidden chars): $demo"
Write-Host "Length check (should be 8, not 5): $($demo.Length)"

Remediation

There is no patch for a technique — remediation is architectural. Prioritize in this order:

1. Normalize before inspection. Work with your SEG/vendor to confirm that message content is Unicode-normalized (NFKC) and that non-rendering code points (U+200B–U+200D, U+2060, U+FEFF, and the entire Tags block U+E0000–U+E007F) are stripped or flagged before keyword, URL, and ML-classifier inspection. If your vendor cannot confirm this, escalate — this is now a demonstrated bypass.
2. Add transport-level controls. In Exchange Online, create mail flow rules quarantining messages whose body matches zero-width regex patterns; in Google Workspace, use compliance content rules. The Tags block specifically should be a hard quarantine — it has no legitimate business use in email.
3. Gate LLM email tooling. Any AI assistant processing inbound mail must operate on sanitized content (invisible characters stripped, rendered-text-only view) and must never be able to take autonomous action (send, forward, click) based on email-derived instructions. Treat every inbound message as untrusted prompt input.
4. Update phishing simulations and awareness training. Include a zero-width-obfuscated sample in your next simulation cycle. Teach users the tell: copy-pasting suspicious email text into a plain-text editor or Word with formatting marks visible will expose odd spacing and invisible glyph boundaries.
5. Deploy the detections above. The KQL subject-field hunt can go live today against Defender for Office 365 data. Add the Sigma process/script-block rules to catch post-click execution of decoded payloads.
6. Tune DMARC/DKIM enforcement to reject, not quarantine, and enable first-time-sender and external-sender banners — smuggled lures disproportionately arrive via compromised-but-authenticated infrastructure, so authentication alone won't save you.

Final Assessment

ASCII smuggling is the latest iteration of a truth defenders keep re-learning: parsers and humans see different documents. Homoglyphs, HTML comment stuffing, base64-split URLs, and now invisible Unicode all exploit the same seam. The organizations that weather this class of attack are the ones that normalize aggressively, inspect what the user actually sees, and assume every downstream consumer of email content — human or LLM — is a target. The detections in this post are production-ready; the transport rule gap check takes ten minutes. Do both this week.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub