Hunting Mailbox Rules After Credential Compromise in M365

After a credential compromise in M365, one of the first things an attacker does is create a mailbox rule.

Not because it is sophisticated. Because it works, and most security teams don’t monitor it.

The attacker forwards all incoming mail to an external address — a disposable Gmail, Protonmail, or Outlook.com account. Or they move emails matching specific keywords to a folder like RSS Subscriptions where nobody looks. Or they auto-delete security notifications so the user never sees the “new sign-in from Lagos” warning that would blow the operation.

In the AiTM campaigns targeting M365 environments right now, the inbox rule is typically created within 3-5 minutes of the initial session hijack. The attacker has a script. They authenticate with the stolen token, create the rule, register a new MFA method, consent to an OAuth app, and start downloading files. Four persistence mechanisms in under 10 minutes. The inbox rule is the one doing the most damage because it operates silently in the background, forwarding financial emails to the attacker for weeks after you think you have contained the incident.

Where to find it

The KQL table depends on where you are hunting.

In Sentinel, the table is OfficeActivity. Filter on Operation == "New-InboxRule" or Operation == "Set-InboxRule". This is the most reliable source — it captures Exchange Online admin audit events and is available with the standard Office 365 connector.

In Defender XDR Advanced Hunting, the table is CloudAppEvents. Same operations, different schema. This works if you have the Defender for Cloud Apps connector enabled and Exchange as a connected app.

Both return the same underlying Exchange audit data. Use whichever matches your primary hunting workspace.

What to hunt for

Not every inbox rule is malicious. Users create rules constantly — move newsletters to a folder, flag emails from their manager, sort project updates. The signal is in the rule’s configuration, not its existence.

Hunt for rules that forward to external addresses. Any rule with a ForwardTo or RedirectTo action pointing outside your domain. Protonmail, Gmail, Outlook.com, Yahoo, Tutanota — any external destination. Legitimate external forwarding exists but it should be rare and documented.

Hunt for rules targeting financial keywords. Rules filtering on subjects or body text containing “invoice,” “payment,” “wire transfer,” “bank details,” or “remittance.” The attacker is intercepting financial communications for BEC.

Hunt for rules moving mail to obscure folders. RSS Subscriptions, Conversation History, and Junk Email are common destinations. The attacker creates a rule that moves matching emails into a folder the user never checks, then reads them via API access.

Hunt for rules deleting security notifications. Rules that delete emails containing “password reset,” “sign-in,” “MFA,” “security alert,” or “unusual activity.” The attacker is suppressing the warnings that would alert the user to the compromise.

Hunt for rules with deliberately vague names. Rule names like “…” (three dots), “.” (single dot), or blank names. Legitimate users name their rules descriptively. Attackers name them to be invisible.

The query

Here is the Sentinel version that catches the high-fidelity patterns:

OfficeActivity
| where TimeGenerated > ago(30d)
| where Operation in ("New-InboxRule", "Set-InboxRule")
| where Parameters has_any ("ForwardTo", "RedirectTo",
    "DeleteMessage", "MoveToFolder")
| extend RuleDetails = tostring(Parameters)
| where RuleDetails has_any (
    "gmail", "protonmail", "outlook.com", "yahoo",
    "tutanota", "pm.me",
    "RSS Subscriptions", "Conversation History",
    "invoice", "payment", "wire",
    "security", "password", "MFA")
| project TimeGenerated, UserId, Operation,
    RuleDetails, ClientIP
| sort by TimeGenerated desc

For a broader hunt, pull all inbox rule operations and review them manually:

OfficeActivity
| where TimeGenerated > ago(30d)
| where Operation in ("New-InboxRule", "Set-InboxRule")
| project TimeGenerated, UserId, Operation,
    Parameters, ClientIP
| sort by TimeGenerated desc

Then filter the ClientIP column. Rules created from IPs outside your corporate range are worth investigating regardless of the rule content.

What about the built-in Sentinel template?

Sentinel does have a “Suspicious inbox manipulation rule” template in the Content Hub. The problem is that in most environments it is either never been enabled, or it was enabled, fired on every legitimate rule creation, generated 40 alerts a day, and got disabled within a week.

A working detection for inbox rules requires tuning. Exclude known legitimate forwarding — the CEO’s EA who forwards to a shared mailbox, the finance team’s automated invoice routing. Filter by rule characteristics — external forwarding and keyword-based deletion are high-fidelity indicators, while generic “move to folder” rules are noisy. Correlate with sign-in risk — an inbox rule created from a high-risk sign-in is a confirmed indicator; the same rule from a corporate IP during business hours is probably legitimate.

The template gives you a starting point. The tuning is where the actual detection engineering happens.

What to do when you find one

When you find a suspicious inbox rule, the rule itself is not the incident. It is a symptom. The attacker already has access. Your response sequence matters.

First, check the sign-in logs for that user. When was the account compromised? Look for mfaSatisfiedByClaimInTheToken (AiTM indicator), sign-ins from unusual locations, or non-interactive token replays from unfamiliar IPs.

Second, check what else happened. The inbox rule was created at minute 3. What happened at minutes 4, 5, and 6? MFA method registration? OAuth app consent? Mailbox delegation? File downloads? These all appear in the same OfficeActivity and AuditLogs tables.

Third, revoke sessions first. Revoke-MgUserSignInSession. The attacker may still be active. Every minute you spend investigating with the session live is a minute the attacker is accessing data.

Fourth, remove the rule. Remove-InboxRule -Mailbox [user] -Identity [rule]. But only after you have documented it — the rule configuration tells you what the attacker was targeting.

Fifth, check for the other persistence mechanisms. If they created an inbox rule, they almost certainly registered an MFA method and consented to an OAuth app. Reset the password, remove the attacker’s MFA method, and revoke any OAuth consent to unverified publishers. If you only remove the inbox rule and reset the password, the OAuth app continues reading email via API indefinitely.

The audit question

How many mailboxes in your environment have forwarding rules pointing to external addresses right now? Not rules created this week — rules that have been running for months.

Run the query with a 90-day lookback. Then run Get-InboxRule across all mailboxes via Exchange Online PowerShell for rules that predate your logging window.

If you find rules you cannot account for, you may have a compromise that was never detected. That is the point of hunting — finding what your detections missed.

This technique is from Practical Threat Hunting in M365 — 17 modules covering identity compromise, cloud persistence, endpoint threats, data exfiltration, and pre-ransomware hunting with 70+ deployable KQL queries. The first two modules are free, no account required.