Hidden inbox rules are mail-flow rules that exist within a mailbox but do not appear in the places administrators and users typically look — the Outlook desktop client, Outlook Web App (OWA), or the Exchange admin center. They operate silently on the server, processing every incoming message against their conditions, and can forward, redirect, delete, or move emails without the mailbox owner's knowledge. They represent one of the most effective persistence mechanisms available to attackers who have compromised a Microsoft 365 or Exchange environment.
How hidden rules are created
The most common method involves MAPI (Messaging Application Programming Interface) operations. MAPI is the low-level protocol that Outlook uses to communicate with Exchange. By interacting directly with the mailbox rules table through MAPI, an attacker can create rules that bypass the standard validation and display logic used by OWA and the admin center.
Tools like Ruler and MailSniper have automated this process, allowing an attacker with valid credentials to create hidden rules in seconds. The attacker connects to the Exchange server using the target's credentials, writes a rule directly to the PR_RULES_TABLE property of the Inbox folder, and disconnects. No admin privileges are required — any user with mailbox access can create these rules on their own mailbox.
In some cases, rules created through legacy Outlook clients (pre-2016) or through Exchange Web Services (EWS) with specific flag combinations can also result in rules that fail to render properly in newer interfaces, making them effectively hidden.
Why they don't appear in standard tools
The Exchange admin center, OWA, and modern Outlook clients render inbox rules by querying the rules table and interpreting each rule's properties through a defined schema. When a rule is created via MAPI with non-standard property tags, missing display names, or binary conditions that the rendering engine does not recognize, the interface simply skips the rule. It still exists in the rules table and the Exchange transport engine still executes it on every incoming message, but the UI acts as if it is not there.
This is not a bug in the traditional sense — it is an architectural gap between the rule execution engine (which processes all rules in the table regardless of their format) and the rule display logic (which only renders rules it can fully interpret).
The persistence problem
Hidden inbox rules are especially dangerous as a persistence mechanism because they survive the standard incident response playbook:
- •Password reset: The rule is stored in the mailbox, not tied to the session. Changing the password has no effect on existing rules.
- •Session revocation: Revoking OAuth tokens or active sessions does not modify mailbox configuration.
- •MFA enforcement: Adding multi-factor authentication prevents future unauthorized logins but does not remove rules created during a previous compromise.
- •Account re-provisioning: Unless the mailbox is fully recreated (not just the user account), the rules table persists.
An attacker who creates a hidden forwarding rule during a brief window of access retains the ability to exfiltrate email indefinitely, even after the organization believes the incident has been fully remediated.
Detection methods
Detecting hidden inbox rules requires direct inspection of the mailbox rules table, bypassing the same display logic that hides them from administrators.
- •Graph API enumeration: The Microsoft Graph API's mailbox rules endpoint returns all rules, including those not visible in OWA. Querying GET /users/{id}/mailFolders/inbox/messageRules for every mailbox in the tenant provides a comprehensive inventory.
- •PowerShell (Get-InboxRule): The Exchange Online Management Shell's Get-InboxRule cmdlet can surface rules that OWA hides, though it may still miss certain MAPI-level rules with malformed properties.
- •MAPI-level scanning: Tools that read the PR_RULES_TABLE property directly from the Inbox folder provide the most complete view. This is the only method guaranteed to detect all rule types, including those created by attacker tools like Ruler.
- •Audit log correlation: Monitor the Unified Audit Log for UpdateInboxRules events and correlate them with sign-in logs. Rules created from suspicious sessions should be investigated immediately.
- •Baseline comparison: Maintain a known-good snapshot of all mailbox rules. Any rule that appears between snapshots without a corresponding change request should be treated as suspicious.
Why continuous scanning matters
One-time audits are insufficient. Attackers who retain any form of access — a compromised OAuth app, a stolen refresh token, a secondary mailbox with delegate access — can re-create hidden rules within minutes of their removal. Only continuous, automated scanning that runs on a scheduled cadence can ensure that hidden rules are detected promptly after creation, reducing the dwell time from months to hours.