Notifications
Clear all
Topic starter
25/06/2026 12:51 am
TL;DR: Unicode-based inbox rule obfuscation in Microsoft Exchange can hide malicious forwarding, deletion, and suppression rules from traditional monitoring, according to Permiso Security. The deeper problem is that mailbox-rule governance assumes readable syntax and stable detection patterns, assumptions that fail when rules are visually deceptive or functionally normalized.
NHIMG editorial — based on content published by Permiso Security: Inboxfuscation, because rules are meant to be broken
Questions worth separating out
Q: How should security teams detect malicious inbox rules that use Unicode obfuscation?
A: Security teams should inspect rule content for suspicious Unicode categories, correlate rule creation with mailbox activity, and analyse normalized backend values rather than relying on visible text alone.
Q: Why do inbox rules create persistence risk in Microsoft Exchange?
A: Inbox rules can persist because they are legitimate mailbox behaviors that continue to run after creation.
Q: What breaks when Exchange monitoring only looks for obvious rule keywords?
A: Obvious keyword monitoring fails when attackers substitute Unicode lookalikes, zero-width characters, or backend-normalised values that preserve malicious behavior while defeating pattern matching.
Practitioner guidance
- Add character-category inspection to mailbox-rule monitoring Detect mathematical symbols, zero-width characters, bidirectional controls, and enclosed alphanumerics in inbox rule conditions and actions.
- Correlate rule creation with rule execution evidence Group audit, runtime, and export data by rule ID so you can reconstruct multi-step rule generation and sanitisation.
- Flag mailbox rules that move mail into unusual folders Treat destination folders such as Calendar or oddly named Inbox variants as high-risk when combined with forwarding, delete, or stop-processing actions.
What's in the full article
Permiso Security's full technical post covers the operational detail this analysis intentionally leaves for the source:
- Exact Unicode character classes and examples used to evade inbox rule detection
- PowerShell and Exchange command examples for reproducing obfuscated rule behavior in a lab
- Detection framework output fields and SIEM integration details for mailbox-rule hunting
- Specific alert IDs and rule patterns used to spot suspicious forwarding, deletion, and folder misuse
👉 Read Permiso Security's analysis of Unicode obfuscation in Exchange inbox rules →
Unicode inbox rule obfuscation in Exchange: what teams are missing?
Explore further
25/06/2026 9:54 am
Inbox rule review fails when systems assume syntax will remain human-readable. This analysis shows that Unicode obfuscation breaks the governance premise behind mailbox-rule inspection: if the rule can be rendered one way and executed another, review is no longer a reliable control. That is a detection and audit failure, not just a parsing problem. The implication is that mailbox governance has to treat text normalization as a security boundary, because the control breaks at the point of interpretation.
A few things that frame the scale:
- 67% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
A question worth separating out:
Q: How do mailbox rules differ from normal email filtering from a governance perspective?
A: Normal email filtering is usually controlled and observable at the platform level, while mailbox rules can be created inside a user or administrative context and become part of the account's behavior. That makes them a governance issue because they can redirect or conceal messages without appearing as a separate attack primitive.
👉 Read our full editorial: Inboxfuscation exposes how Unicode hides malicious Exchange rules
