What this check looks at
Finds enabled inbox rules that take mail out of the inbox and either mark it read first, or pick out mail about invoices, bank details, wire transfers, remittances or payments. Rules hidden through MAPI are not visible to Graph, so this check cannot see them.
An inbox rule can move mail to another folder, mark it as read or delete it the moment it arrives, before its owner sees it. People use rules like this to file newsletters. An attacker who gets into a mailbox uses the same feature to hide the replies that would give them away: a supplier asking why their bank details changed, or the bank querying a payment. The rule moves those replies to a folder nobody opens, such as RSS Feeds or Conversation History, marks them read, or deletes them.
The check reads the inbox rules in each mailbox in scope through Graph, the same read as the forwarding check, and looks for enabled rules that take mail out of the inbox and either mark it read first, or pick out mail whose subject or body mentions an invoice, bank, wire, remittance or payment. A rule that picks out payment mail and marks it read or deletes it fails the check; a rule that only marks mail read and moves it, or only moves payment mail to another folder, is a warning, as people sometimes make those themselves to file newsletters or invoices. The evidence lists up to 25 rules, with what each does. Naming the folder a rule moves mail to would need a mail permission the read app does not ask for, so the check judges the rule by what it does instead.
Rules hidden through MAPI are not visible to Graph. An attacker with the right tools can make a rule Outlook and Graph never show, so a pass here does not rule one out: for a mailbox you suspect, run Get-InboxRule -IncludeHidden in Exchange Online PowerShell as well.
Why it matters
Hiding replies is how business email compromise goes unnoticed: the attacker moves a supplier’s or the bank’s answers out of sight while they change the payment details. A rule like this keeps working after the password is reset.
A typical case: an attacker phishes the credit controller at a 40-person wholesaler and adds a rule moving anything containing invoice or payment from the firm’s biggest customer to the RSS Feeds folder, marked as read. The attacker then emails the customer from the real mailbox with new bank details. When the customer replies to confirm, the reply is hidden, so nobody at the firm notices until the month’s payment never arrives.
The rule belongs to the mailbox, not to the attacker’s session, so it keeps working after the password is reset and the sessions are revoked. Finding it is often the first evidence of how long the attacker was there, which matters for deciding whether a personal data breach must be reported to the ICO within 72 hours under UK GDPR.
Detecting and responding to a compromised account is what ISO 27001 A.5.26 (response to information security incidents) and A.8.16 (monitoring activities), NIST CSF 2.0 DE.AE-02 and RS.MA-02, and NCSC CAF C1.d (identifying security incidents) ask for. Microsoft’s own guidance on Outlook rules attacks describes the same pattern.
How to fix it
Where: Exchange Online PowerShell (the Exchange admin centre does not list inbox rules)
Before you start
- Ask each mailbox owner, by phone rather than email, whether they made the listed rule; a rule nobody recognises means the mailbox is compromised.
- For a compromised mailbox, contain the account first: block sign-in, revoke sessions and reset the password.
Step by step
- Confirm each rule with its owner. Take the rules in the evidence (mailbox, rule name, what it does) and ask each owner, by phone rather than email, whether they made it. Treat any rule the owner does not recognise as a sign of compromise and deal with that first.
- Contain a compromised mailbox. For a mailbox whose rule nobody recognises: block sign-in, revoke sessions and reset the password (Contain the account does all three as one approved change and turns these rules off too). In the Microsoft Purview portal, search Solutions > Audit for New-InboxRule and Set-InboxRule activity on the mailbox to see when, and from where, the rule was made.
- Turn the rules off. Turn off each rule the owner did not make, with the approved change from this finding or Disable-InboxRule -Mailbox user@contoso.com -Identity "<rule name>" in Exchange Online PowerShell. Turning it off keeps its conditions, so you can see what the attacker was watching for; remove it with Remove-InboxRule once the incident is closed.
- Look for rules Graph cannot see. Run Get-InboxRule -Mailbox user@contoso.com -IncludeHidden | Format-List Name, Enabled, MarkAsRead, MoveToFolder, DeleteMessage, SubjectOrBodyContainsWords. Rules hidden through MAPI appear only here, not in Outlook or Graph. Check the folders the rules moved mail to, such as RSS Feeds, RSS Subscriptions, Conversation History and Archive, for replies the owner never saw.
- Confirm the rules are off. Run Get-InboxRule -Mailbox user@contoso.com again and check each rule shows Enabled False. The next assessment passes when no enabled inbox rule hides incoming mail.
With PowerShell
Get-InboxRule -Mailbox <user> -IncludeHidden | Format-List Name, Enabled, MarkAsRead, MoveToFolder, DeleteMessage, SubjectOrBodyContainsWords
What users will notice
Mail the rule was hiding stays in the inbox again. A rule turned off is kept, so the owner can switch a genuine one back on.
How to confirm it worked
The rule list in the evidence is empty at the next assessment, and Get-InboxRule -Mailbox <user> -IncludeHidden shows no rule that moves or deletes payment mail, including rules hidden through MAPI, which Graph does not return.
Frameworks and controls
This check maps to controls in 12 frameworks. Passing it is evidence that the setting is in place, not a certification against any of them.
| Framework | Control |
|---|---|
| NCSC CAF | C1.d Identifying security incidents |
| DSPT | Standard 6: Responding to incidents |
| NIS2 | Art. 21(2)(b) Incident handling |
| Microsoft Cloud Security Benchmark | IR-3 Detection and analysis: create incidents based on high-quality alerts |
| Zero Trust | Identities |
| SOC 2 | CC7.3 Evaluating security events |
| NIST SP 800-171 | 3.6.1 Establish an operational incident-handling capability |
| CMMC Level 2 | IR.L2-3.6.1 Incident Handling |
| ISO 27001:2022 | A.5.26 Response to information security incidentsA.8.16 Monitoring activities |
| CIS Controls v8.1 | 13.1 Centralize security event alerting (IG2) |
| NIST CSF 2.0 | DE.AE-02: Potentially adverse events are analyzed to better understand associated activitiesRS.MA-02: Incident reports are triaged and validated |
| NCSC 10 Steps | Incident managementLogging and monitoring |
The framework mappings were last checked against the published standards in October 2026.
Microsoft’s documentation
- Detect and remediate Outlook rules and custom forms injection attacks (Microsoft Learn)