Check Inbox Rules for a Hacker in Microsoft 365

TL;DR. The most common footprint of a Microsoft 365 BEC is an inbox rule the user did not create: forward to an outside address, delete, mark as read, or move to RSS Feeds, Archive or Conversation History, often filtered on "invoice", "payment" or "bank", often named ".". In the Unified Audit Log look for New-InboxRule, Set-InboxRule, Enable-InboxRule and UpdateInboxRules, plus Set-Mailbox with ForwardingSmtpAddress. Check the IP and session each rule came from. For the current state, run Get-InboxRule -Mailbox <user> -IncludeHidden.

Inbox rules are cheap, quiet and effective. The attacker who hijacks a supplier conversation needs the victim not to see the supplier's "did you really change your bank?" reply. One rule does that. Another sends a copy of every message about payments to an outside mailbox so the attacker keeps reading after the password reset. MITRE tracks the two as Email Hiding Rules (T1564.008) and Email Forwarding Rule (T1114.003).

What malicious rules look like

Microsoft's public reporting on AiTM-to-BEC campaigns describes rules that move mail from a given sender domain to the Archive folder and mark it as read, and rules that move all incoming mail to Archive and mark it read (July 2022, June 2023). Microsoft's compromised-account guidance lists rules that forward to unknown addresses and rules that move messages to Notes, Junk Email or RSS Subscriptions (Microsoft Learn).

No single trait proves anything. Users do forward mail to personal addresses, and some name rules badly. The combination, and above all the session that created the rule, is what matters.

Finding rule creation in the Unified Audit Log

A minimal PowerShell check on an export already loaded as $all (see the export guide):

$all | Where-Object { $_.Operations -in 'New-InboxRule','Set-InboxRule','UpdateInboxRules','Set-Mailbox' } |
  ForEach-Object {
    $d = $_.AuditData | ConvertFrom-Json
    [pscustomobject]@{
      Time   = $d.CreationTime; User = $d.UserId; Op = $d.Operation
      IP     = $d.ClientIP; Session = $d.AppAccessContext.AADSessionId
      Params = ($d.Parameters | ForEach-Object { "$($_.Name)=$($_.Value)" }) -join '; '
    }
  } | Sort-Object Time | Format-Table -Wrap

Then take each rule's ClientIP and session to the sign-in logs. A rule created from the IP and Session ID of a replayed session is not the user's rule; the session pivot explains how to prove it.

Checking the current state with Get-InboxRule

The audit log tells you what happened; the mailbox tells you what is still there. Microsoft's recommended checks (Microsoft Learn):

Get-Mailbox -Identity user@example.com | Format-List Forwarding*Address,DeliverTo*
Get-InboxRule -Mailbox user@example.com -IncludeHidden |
  Format-List Name,Enabled,RedirectTo,Forward*,Identity

ForwardingSmtpAddress non-empty means SMTP forwarding to an external recipient; ForwardingAddress to an internal one. -IncludeHidden returns rules that normal clients do not display. Compare the list with the audit history: a rule present now but with no creation event in the export was created before the export window (extend the search), or through a path the export did not cover.

Also check the hiding places: open RSS Feeds, Archive, Conversation History, Notes and Deleted Items in the victim's mailbox. The supplier's warning e-mail is often sitting there, unread.

Forwarding that bypasses rules: tenant controls

Outbound spam policies control automatic forwarding to external recipients with three settings: Automatic – System-controlled (the default, whose behaviour differs by organisation), On and Off. Microsoft recommends setting On or Off explicitly; when blocked, both inbox-rule forwarding and mailbox forwarding to external addresses are stopped with an NDR 5.7.520 (Microsoft Learn). A forwarding rule in the audit log does not prove mail actually left: check this policy, remote domain settings, and message trace.

How M365 Forensics scores inbox rules

The in-browser analyser has one rule per pattern, all visible in its rules.json:

"Internal" is inferred from the domains present in the tenant's own accounts. If the attacker created the rule from a suspicious session, the correlation finding ("actions performed from the attacker's session or IP") is added on top and the verdict becomes Compromised. In the built-in fictional sample, a legitimate "Newsletters" rule created from the office IP stays unflagged while the attacker's "." and ".." rules each trigger several findings (hiding, keywords or external forwarding, odd name, attacker session).

After you find one

Do not just delete the rule. It is proof that someone else used the account, and it may be one of several persistence mechanisms. Follow the first-hour response: revoke sessions, remove rules and forwarding, remove the attacker's MFA methods and consented apps, reset credentials, then establish what was forwarded, read and sent. Keep an export of the rule (and its audit record) before removing it.

Frequently asked questions

How do I see hidden inbox rules in Microsoft 365?

Run Get-InboxRule -Mailbox <user> -IncludeHidden in Exchange Online PowerShell. Outlook and the web settings do not show every rule; the audit log shows when each rule was created and from which IP.

What makes an inbox rule suspicious?

A rule the user did not create that forwards or redirects mail outside, deletes it, marks it read, or moves it to a folder nobody reads (RSS Feeds, Archive, Conversation History), often filtering on words like invoice, payment or bank, and often with a one-character name.

Is deleting the rule enough?

No. The rule shows the account was used by someone else. Revoke sessions, remove forwarding and the attacker's MFA methods and app consents, reset credentials, and check what was forwarded and sent.

Further reading

• Microsoft Learn: Detect and remediate Outlook rules and custom forms injection
• Glossary: inbox rule, business email compromise
• Gmail has filters and forwarding too: googleworkspaceforensics.com.