They should review the rule text, the effective action, the target folder or forwarding destination, and the surrounding audit trail together. If the rule contains Unicode obfuscation or abnormal normalization, investigators should treat the mailbox as potentially manipulated and rebuild the sequence from logs rather than trusting one snapshot.
What to examine first in a suspicious inbox rule
Start by treating the rule as evidence, not as truth. Read the rule text, then verify what it actually does when the mailbox receives a message: move, delete, mark as read, forward, redirect, or hide. A rule that looks harmless in the client can still be operationally dangerous if its effect is to suppress security alerts or divert mail out of the owner’s view.
The target folder or forwarding destination matters as much as the rule text. Investigators should confirm whether the destination is a normal user folder, a delegated mailbox, an external address, or a folder created to blend in with legitimate activity. If the rule is part of a broader mailbox compromise, the rule often exists to create quiet persistence rather than immediate loss.
Unicode obfuscation, unusual whitespace, and abnormal normalization are strong signs that the displayed text may not match the underlying action. Reconstruct the timeline from logs, message traces, and mailbox audit events instead of trusting a single administrative snapshot. In practice, the “one screen” view is often the least reliable view when a rule has been intentionally disguised.
How to reconstruct the sequence without missing the attacker’s intent
Use the surrounding audit trail to answer four questions in order: when the rule appeared, what changed, who or what made the change, and whether the rule was modified again after creation. That sequence tells you whether you are looking at user misconfiguration, post-compromise persistence, or an attacker trying to alter evidence after the fact.
Correlate the inbox rule with sign-in events, mailbox access events, and message delivery evidence. If the rule forwards mail externally, check whether the forwarding path predates the rule or was added at the same time. If the rule moves mail into a nested folder, confirm whether that folder is new, hidden from normal workflow, or used to bury invoices, password resets, or security notifications.
For difficult cases, preserve the original artifacts and work from exported logs rather than repeatedly editing the live mailbox view. That reduces the chance of overwriting contextual evidence, and it helps investigators separate the displayed rule name from the actual condition-action structure that Exchange evaluated.
What good containment looks like after you confirm abuse
Once a suspicious rule is validated, containment should focus on stopping mail diversion and denying the attacker continued mailbox control. That usually means disabling or removing the rule, checking for related forwarding settings, reviewing mailbox delegation, and confirming whether any OAuth-consented application, session token, or reused credential was also involved.
Do not stop at the rule itself. Inbox rules are often a symptom of broader mailbox compromise, and the same actor may have added transport rules, alternate forwarding, or deletion behavior elsewhere in the tenant. A clean-looking inbox is not proof of recovery if mail is still being intercepted before the user sees it.
When the mailbox is business-critical, preserve the investigative record before remediation so you can explain what was hidden, where it went, and how long it remained active. That evidence is often what turns a suspicious rule from a nuisance into a defensible incident with a clear scope and timeline.
Risk and Threat Considerations
Suspicious inbox rules are risky because they can create silent persistence, conceal alerts, and redirect sensitive mail without changing the mailbox owner’s normal login experience. They are especially dangerous when they target invoices, password resets, or approval workflows, because the attacker can keep receiving high-value messages while the victim sees nothing unusual.
Failure mechanism: The attacker abuses mailbox rule logic, forwarding, or message filtering to manipulate delivery paths, then relies on superficial admin views or cached client state to hide the true effect.
Impact: Mail diversion can enable account takeover follow-on activity, invoice fraud, missed security notifications, and prolonged compromise even after the initial access vector is closed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1114 — Email Collection | Inbox rules can silently divert and suppress mail for attacker access. |
| Recommendation — Map mail diversion to T1114 and hunt for related mailbox abuse and collection activity. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and Systems Are Monitored to Detect Anomalous Events | Investigating suspicious rules depends on monitoring mailbox changes and abnormal delivery behavior. |
| Recommendation — Monitor mailbox rule changes and forwarding events for anomalies. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Rule reconstruction depends on preserving and reviewing mailbox and sign-in audit trails. |
| Recommendation — Centralize and review mailbox audit logs to reconstruct rule activity. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Analysts must review audit records to establish who created or altered the rule. |
| AC-6 — Least Privilege | Containment requires limiting mailbox and forwarding privileges that enable hidden diversion. | |
| Recommendation — Review audit records to confirm rule creation, modification, and access context. Restrict mailbox and forwarding privileges to the minimum required. | ||
Practitioner Guidance
What to verify: Verify the rule action, the destination, and the creator or last editor before you trust any screenshot or portal view. If the rule contains obfuscated characters or odd normalization, treat the live mailbox rendering as untrusted and validate against backend evidence.
Decision rule: If the rule can forward, delete, or suppress messages that the business depends on, prioritise containment and mailbox access review before debating whether the rule was “probably benign.” The operational risk is in the effect, not the appearance.
Practitioner takeaway: The key judgement is to reconstruct mailbox behavior from evidence that survives client deception, because suspicious rules are often designed to hide the attacker’s real control path rather than to look obviously malicious.
Related resources from NHI Mgmt Group
- How should security teams detect malicious inbox rules that use Unicode obfuscation?
- Why do inbox rules create persistence risk in Microsoft Exchange?
- How should security teams investigate suspicious email attachments without losing context?
- How should security teams investigate suspicious login alerts without drowning in false positives?