Investigating Suspicious Exchange Inbox Rules

The CFO swears the vendor never emailed her. The vendor swears they did. Meanwhile, the message was quietly redirected by Exchange Inbox Rules at 2:13 a.m. from a browser session nobody recognizes. That is how a lot of nasty mailbox incidents start: not with ransomware theatrics, but with one boring little rule doing exactly what the attacker wants.

In real cases, this is where Business Email Compromise gets dangerous. The user keeps working, the attacker keeps watching, and the mailbox starts lying by omission. No explosions, no movie soundtrack, just missing threads, “read” messages nobody read, and a finance team one bad approval away from a very long afternoon.

If you only check Outlook and call it done, you are basically investigating with one eye closed. Attackers know that. Sadly, they also know admins are busy.

What Are Exchange Inbox Rules?

Exchange Inbox Rules are server-side mailbox actions in Exchange Online that automatically move, delete, mark as read, or forward incoming mail. In an investigation, they matter because attackers use them as quiet automation after account compromise, especially when they want persistence without sitting in the mailbox all day.

Most rules are completely normal. Move newsletters, flag VIP mail, toss noisy alerts into a folder, sure. The problem is that the exact same feature is perfect for hiding evidence. A malicious rule can forward finance mail to an outside address, dump security warnings into RSS Feeds, or mark replies as read so the victim never realizes a thread is active.

What usually makes a rule suspicious is not the existence of the rule. It is the context around it:

• An external recipient nobody can explain
• Keywords tied to finance, invoices, payroll, wire changes, MFA, or password resets
• Actions that delete, soft-delete, move, or mark as read
• Rules targeting low-visibility folders like RSS Feeds or Archive
• A creation time that matches odd sign-in activity
• A rule the user cannot see in their normal Outlook view

A common mistake is treating this as a “mailbox settings” issue instead of an incident. It is usually both.

Concept Overview

Attackers abuse mailbox rules because they are persistent, quiet, and annoyingly effective. Once a mailbox is compromised, a rule can keep feeding the attacker high-value mail even if the victim goes back to answering messages like nothing happened. That is classic Mailbox Rules Abuse, and it works because it blends into normal admin clutter.

A very typical flow looks like this:

1. A user approves a fake sign-in prompt, reuses a phished password, or hands over a session in some other painfully ordinary way.
2. The attacker signs in to Exchange Online or Outlook on the web.
3. They create one or more Email Forwarding Rules or inbox rules that watch for invoice, payment, banking, payroll, legal, or executive keywords.
4. The rule forwards matching mail, moves the original to a quiet folder, and often marks it as read.
5. The attacker monitors the conversation and waits for the right moment to impersonate a vendor, executive, or partner.
6. The victim never sees the warning signs because the mailbox is being curated against them.

Why this matters in practice: if you investigate only inbox rules, you can miss mailbox-level forwarding or transport rules. If you investigate only the audit trail, you can miss the rule that still exists right now. If you investigate only the rule, you can miss the compromised sign-in that created it. You need all three.

Prerequisites & Requirements

A solid investigation needs more than Exchange admin access and a hunch. You need the current rule state, the change history, the sign-in context, and enough mail-flow evidence to tell whether the rule actually moved data or just attempted to. Without that, you are guessing in a nicer font.

• Data sources: Current inbox rules, mailbox forwarding settings, Microsoft Purview audit logs, mailbox audit logs, Microsoft Entra sign-in logs, message trace, and any Defender alerts tied to the user.
• Infrastructure: Exchange Online PowerShell access, Exchange admin center access, Microsoft Purview Audit access, and a reliable way to work in UTC when reviewing timestamps.
• Security tools: Microsoft Defender XDR or Defender for Office 365 if you have it, SIEM correlation if available, and sign-in risk telemetry for the affected user.
• Team roles: Exchange admin, identity admin, SOC or incident responder, and a business owner who can confirm whether a forwarding target or rule is actually legitimate.

Before you start, verify the boring fundamentals:

Connect-ExchangeOnline Get-OrganizationConfig | Format-List AuditDisabled Get-AdminAuditLogConfig | Format-List UnifiedAuditLogIngestionEnabled

You also need the right permissions. Microsoft currently expects the Audit Logs or View-Only Audit Logs roles for audit searches in Purview, and Exchange-side audit roles for the cmdlets. One annoying edge case: Get-InboxRule does not work for members of View-Only Organization Management in Exchange Online or the Global Reader role in Microsoft Entra ID. So if the command fails, it may be your role, not your syntax.

Another practical detail: audit retention is not infinite. As of March 29, 2026, Audit (Standard) generally keeps records for 180 days by default, while users with E5 or Audit Premium entitlements get longer default retention for supported workloads. That date window matters a lot once somebody says, “I think this started a few months ago.”

Step-by-Step Guide

The fastest investigation path is simple: scope the mailbox and timeline, enumerate visible and hidden rules, check other forwarding paths, pull the audit records, correlate them with sign-ins and message trace, then contain the issue without deleting your evidence first. Fancy dashboards are nice. Sequence matters more.

Step 1: Scope the mailbox and timeline

Goal: Define what “suspicious” means for this case before you drown in logs.

Checklist:

• Identify the affected mailbox or shared mailbox
• Collect examples of missing, moved, or unexpectedly read messages
• Pin down the earliest known bad time and the last known good time
• List the people, vendors, or finance threads most likely affected
• Convert everything to UTC up front

Common mistakes: Starting with a giant tenant-wide search, trusting a user’s local time math, or assuming the mailbox owner is the actor who changed the rule.

Example: A controller reports that invoice replies vanished sometime between Tuesday afternoon and Thursday morning. That is good enough to build an initial window. You do not need the perfect minute yet. You do need a defensible range.

Step 2: Enumerate current rules, including hidden ones

Goal: See the rule set as Exchange sees it, not just as Outlook chooses to show it.

Checklist:

• Pull the mailbox’s current rules with Get-InboxRule
• Use -IncludeHidden so you do not miss Hidden Inbox Rules
• Review actions like redirect, forward, delete, soft-delete, move, and mark as read
• Note rule priority, whether it is enabled, and whether it stops later processing
• Export or screenshot the output before you change anything

Common mistakes: Checking only classic Outlook, assuming “not visible in Outlook” automatically means malicious, or forgetting that some rules created in Outlook on the web or the new Outlook do not appear in classic Outlook by design while still running normally.

Get-InboxRule -Mailbox [email protected] -IncludeHidden | Format-List Name,Enabled,Priority,Description,RedirectTo,ForwardTo,ForwardAsAttachmentTo,MoveToFolder,DeleteMessage,SoftDeleteMessage,MarkAsRead,StopProcessingRules

Example: You find a rule called RSS Sync created three days ago. It forwards messages containing “invoice” or “payment” to an outside address, moves the original into RSS Feeds, and marks it as read. Nobody in finance created that. That is not subtle. It is just annoyingly common.

Step 3: Check mailbox forwarding and transport rules too

Goal: Confirm the attacker did not use a different forwarding mechanism entirely.

Checklist:

• Check mailbox-level forwarding with Get-Mailbox
• Review EAC mail-flow settings for the mailbox
• Review transport rules if the behavior looks broader than one user
• Check whether outbound spam policy or remote domain settings would block external forwarding
• Document whether the forward actually succeeded or was merely attempted

Common mistakes: Stopping after one suspicious inbox rule, ignoring shared mailboxes, or treating a blocked external forward as harmless. A blocked exfiltration attempt is still compromise evidence.

Get-Mailbox [email protected] | Format-List ForwardingAddress,ForwardingSmtpAddress,DeliverToMailboxAndForward

Example: The inbox rules look clean, but ForwardingSmtpAddress points to a webmail account. That tells you this is not just a user-rule problem. It is mailbox-level forwarding, likely set through admin-style mail-flow settings or by an attacker with broader access.

One useful Microsoft nuance here: the default outbound spam policy setting Automatic - System-controlled now behaves like Off for external forwarding. So if a rule exists but the mail never left, do not pat yourself on the back too quickly. Someone still tried.

Step 4: Find who created, changed, or removed the rule

Goal: Attribute the change to an account, time, IP, and client path.

Checklist:

• Search Microsoft Purview Audit with the exact operation names
• Use New-InboxRule, Set-InboxRule, and Remove-InboxRule
• Remember that mailbox audit logging records rule changes as UpdateInboxRules
• Capture actor, IP address, client, and raw parameters
• Expand the date range if necessary, but stay inside retention boundaries

Common mistakes: Using the wrong operation names, forgetting that audit search timestamps are UTC, filtering too narrowly on the user field, or searching only one audit source. This naming mismatch is one of the main reasons people miss rule abuse during a BEC Investigation.

Search-UnifiedAuditLog -StartDate "2026-03-20 00:00:00Z" ` -EndDate "2026-03-29 23:59:59Z" ` -Operations New-InboxRule,Set-InboxRule,Remove-InboxRule ` -ResultSize 1000

Example: You find a Set-InboxRule event at 02:13 UTC from an IP the user has never touched before, using a browser session that also generated failed sign-ins earlier that night. That is the moment your “weird mailbox behavior” becomes an identity incident with a mailbox symptom.

Step 5: Correlate with sign-ins, alerts, and message trace

Goal: Decide whether the rule was malicious, whether data left the tenant, and whether other accounts are involved.

Checklist:

• Compare rule-change time with Microsoft Entra sign-ins
• Look for new geography, ISP, user agent, token use, or failed sign-in bursts
• Review Defender alerts for suspicious inbox forwarding rules or inbox manipulation
• Use message trace to confirm mail flow and identify affected threads
• Check whether other users forwarded to the same destination

Common mistakes: Treating the bad rule as the whole incident, skipping sign-in correlation, or assuming the forwarding target is harmless because it uses a personal-sounding mailbox name. Attackers love boring names.

Get-MessageTraceV2 -SenderAddress [email protected] ` -RecipientAddress [email protected] ` -StartDate "2026-03-25" ` -EndDate "2026-03-29"

Example: The rule targets messages with “wire” and “invoice” in the subject. Message trace shows matching vendor threads delivered to the mailbox. Defender shows a suspicious forwarding alert. Sign-in logs show an unusual country five minutes earlier. At that point, call it what it is: malicious, not mysterious.

As of March 29, 2026, Get-MessageTraceV2 can search the last 90 days, but only 10 days per query. That detail matters when someone wants “everything for the last month” in one shot and PowerShell politely refuses.

Step 6: Contain and remediate without destroying the story

Goal: Stop the abuse, preserve evidence, and reduce the chance of immediate re-entry.

Checklist:

• Preserve the current rule output and audit results first
• Disable the malicious rule, then remove it once evidence is secured
• Reset credentials, revoke active sessions, and investigate token or app abuse
• Review sent mail, deleted items, delegates, forwarding settings, and related admin changes
• Notify finance, legal, or affected partners if exposed conversations matter

Common mistakes: Deleting the rule before documenting it, resetting the password but leaving sessions alive, or editing rules in PowerShell without realizing Microsoft warns that PowerShell changes can remove Outlook client-side rules. That last one surprises people every single time.

Disable-InboxRule -Mailbox [email protected] -Identity "RSS Sync"

Example: You disable the rule, revoke sessions, reset the account, confirm the attacker no longer has sign-in activity, and notify the finance lead that vendor conversations from the last 72 hours should be treated as potentially exposed. That is containment with context, not checkbox theater.

Workflow Explanation

A clean investigation workflow moves from signal to proof to containment. The trick is not to jump straight to deletion because the rule is upsetting. First prove what changed, then prove who changed it, then prove what mail was affected, and only then clean up.

1. Start with the signal: missing email, unexpected reads, odd forwarding alert, or user complaint.
2. Capture the mailbox, timeframe, and business context.
3. Enumerate inbox rules with IncludeHidden and check mailbox forwarding.
4. Pull audit records and line them up in UTC.
5. Correlate with sign-ins, Defender alerts, and message trace.
6. Contain the mailbox, then hunt for blast radius across other users and the same forwarding target.

Good Email Attack Detection in Microsoft 365 is not one console. It is stitching together identity, audit, and mail flow fast enough that the attacker does not get a second quiet week.

Troubleshooting

When mailbox rule investigations go sideways, it is usually because the data sources disagree for boring reasons: wrong operation names, wrong time zone, wrong admin scope, or the wrong place to look. Troubleshooting this is less glamorous than threat hunting, but it saves hours.

Problem → Cause → Fix

Search-UnifiedAuditLog returns no rule changes → You used the wrong operation names, searched the wrong time range, or the event has not fully landed yet → Use the exact values New-InboxRule, Set-InboxRule, and Remove-InboxRule, search in UTC, expand the range, and remember Microsoft says core audit records are typically available within about 60 to 90 minutes rather than instantly.

The mailbox is still acting weird, but current rules look normal → You checked only visible rules, or the abuse is actually mailbox forwarding or a transport rule → Re-run Get-InboxRule with -IncludeHidden, check Get-Mailbox forwarding settings, and review transport rules if the pattern is broader than one mailbox.

You see a suspicious rule, but the messages were never forwarded externally → External auto-forwarding may be blocked by policy, remote domain controls, or mail flow rules → Treat it as attempted compromise anyway. Microsoft’s current default system-controlled forwarding behavior blocks many external forwards by default, which is helpful but not the same thing as no attack.

You cannot find Set-Mailbox audit events → Your admin account may be scoped by administrative units and therefore restricted → Microsoft currently notes that some operations, including Exchange Set-Mailbox, are visible only to unrestricted admins in certain audit searches. Escalate to the right admin scope before assuming the trail is gone.

Classic Outlook shows no suspicious rule, but mail keeps moving → Some rules created in Outlook on the web or the new Outlook do not appear in classic Outlook by design → Validate in Outlook on the web or Exchange PowerShell before labeling it malicious. Not every invisible rule is evil. Some are just Microsoft being Microsoft.

The cleanup breaks legitimate user behavior → PowerShell changes to inbox rules can remove Outlook client-side rules → Export the current rule state first, warn the user, and prefer disable-before-delete if you need a quick containment step without immediately losing context.

If you are chasing Suspicious Email Behavior and your evidence keeps disappearing between tools, the problem is usually not that the attacker is brilliant. It is usually that the investigation path is fragmented.

Security Best Practices

The best defense is boring operational discipline: block what should never be allowed, alert on changes that matter, and review high-risk mailboxes before finance learns about the incident from the bank. For M365 Security teams, this is one of those areas where process beats shiny dashboards.

• Block external automatic forwarding by default unless there is a documented exception.
• Alert on new rules that forward, redirect, delete, soft-delete, or mark messages as read.
• Review VIP, finance, legal, HR, and shared mailboxes on a schedule.
• Hunt for the same external destination across multiple users when one case turns malicious.
• Use message trace and sign-in context to validate impact, not just configuration.

One underrated trick: if you need to spot auto-forwarding behavior in mail flow, Microsoft documents the X-MS-Exchange-Inbox-Rules-Loop header as a useful signal for tracking automatically redirected or forwarded mail. Most articles skip that detail. They should not.

Related Reading

• Microsoft 365 Account Takeover Response
• How to Use Message Trace for BEC Investigations
• OAuth Consent Phishing in Microsoft 365

Wrap-up

Investigating suspicious mailbox rules in Exchange Online is not really about rules. It is about proving whether a mailbox was quietly turned against its owner. If you do this well, you can catch an incident while it still looks like a weird foldering issue instead of a wire-fraud story for next quarter’s board deck.

Check the current rules, check the hidden rules, check forwarding outside the inbox-rule layer, then line everything up against audit and sign-in evidence in UTC. That sequence will save you from a lot of false confidence.

If you want the raw Microsoft references behind this workflow, start with Get-InboxRule, Identify who modified mailbox rules, Manage mailbox auditing, Get-MessageTraceV2, and external forwarding controls.

Frequently Asked Questions (FAQ)

Can an attacker create a rule the user never sees in Outlook?

Yes. Some rules are genuinely hidden, and some are simply not displayed in classic Outlook even though they still run. That is why PowerShell with -IncludeHidden and a check in Outlook on the web matter more than trusting one client view.

How far back can I investigate this in Microsoft 365?

As of March 29, 2026, Audit (Standard) commonly gives you 180 days of retention by default, while E5 or Audit Premium coverage can extend that for supported data. Message trace via Get-MessageTraceV2 can search the last 90 days, but only in 10-day query windows.

Is deleting the malicious rule enough to close the incident?

No. The rule is usually the symptom, not the whole compromise. You still need to reset credentials, revoke sessions, review sign-ins, check for malicious app consent or broader abuse, and assess what mail was exposed or forwarded before containment.

Why would a forwarding rule exist if no mail actually left the tenant?

Because policy can block the forwarding action even when the attacker successfully creates the rule. External auto-forwarding controls, remote domain restrictions, or transport logic may stop delivery. That is good news operationally, but it is still evidence of attempted compromise.