Detecting and Removing Malicious Inbox Rules: Step-by-Step Workflow

Before You Start: Get the Order Right

Malicious inbox rules are the most common persistence mechanism in business email compromise. For a deeper breakdown of why attackers use them and the abuse patterns to watch for, see our companion guide on Microsoft 365 mailbox rule abuse. This article is the hands-on runbook: the precise sequence of actions to take once you suspect a rule is malicious.

The workflow below assumes you are connected to Exchange Online PowerShell (Connect-ExchangeOnline) with an account that holds the appropriate eDiscovery or security-admin role, or that you are calling the Microsoft Graph API with MailboxSettings.ReadWrite permission.

Every investigation starts with a trigger — a Defender Suspicious inbox forwarding alert, a New-InboxRule event in the Unified Audit Log, or a user report. Before touching rules, confirm the mailbox is actually compromised by correlating the rule activity with sign-in telemetry.

# Microsoft Graph PowerShell
Get-MgAuditLogSignIn -Filter "userPrincipalName eq 'user@domain.com'" |
  Select-Object CreatedDateTime, IpAddress, `
    @{n='Risk';e={$_.RiskLevelDuringSignIn}}, `
    @{n='City';e={$_.Location.City}} |
  Sort-Object CreatedDateTime -Descending | Select-Object -First 20

Note the timestamp of the suspicious sign-in. Any inbox rule created or modified shortly after a risky or impossible-travel login is your prime suspect. Record the affected UPN, the attacker IP, and the rule creation time — you will need these for the audit trail in Step 7.

Capture a full copy of every inbox rule on the mailbox before making any changes. Export the complete definition so the forwarding address, keyword filters, and actions are preserved for forensics.

# Exchange Online PowerShell
$mbx = "user@domain.com"
Get-InboxRule -Mailbox $mbx |
  Select-Object Name, Enabled, Priority, From, SubjectContainsWords,
    BodyContainsWords, ForwardTo, RedirectTo, ForwardAsAttachmentTo,
    MoveToFolder, DeleteMessage, MarkAsRead, StopProcessingRules |
  Export-Clixml "./evidence/$($mbx)_inboxrules_$(Get-Date -f yyyyMMdd_HHmm).xml"

Use Export-Clixml (not CSV) so nested action objects are preserved exactly. Store the file in a controlled evidence location. This snapshot is what makes every subsequent action reversible — if you remove a legitimate rule by mistake, you can recreate it precisely from this export.

With the snapshot safe, inspect each rule. Score it against the high-confidence indicators below — the more that match, the more certain the rule is malicious.

Preserve legitimate rules. A user forwarding newsletters to a personal folder is not an incident. The goal is to action high-confidence malicious rules while leaving normal business rules intact — blanket deletion causes its own outage.

Disabling stops the rule from running instantly while keeping it intact for any final review. Do this the moment you confirm intent — every minute a forwarding rule stays active is more data leaving your tenant.

# Exchange Online PowerShell
Disable-InboxRule -Mailbox "user@domain.com" -Identity "RuleName"

# Confirm it is now disabled
Get-InboxRule -Mailbox "user@domain.com" -Identity "RuleName" |
  Select-Object Name, Enabled

In parallel, contain the account itself — revoke sessions and reset credentials — so the attacker cannot simply recreate the rule. See our Entra ID account takeover playbook for the full containment sequence.

Once contained and captured, remove the rule. Then check for the forwarding attackers set at the mailbox level, which inbox-rule enumeration alone will miss.

# Remove the malicious inbox rule
Remove-InboxRule -Mailbox "user@domain.com" -Identity "RuleName" -Confirm:$false

# Clear mailbox-level forwarding (a separate attacker technique)
Set-Mailbox -Identity "user@domain.com" `
  -ForwardingSMTPAddress $null -ForwardingAddress $null `
  -DeliverToMailboxAndForward $false

DELETE https://graph.microsoft.com/v1.0/users/{id}/mailFolders/inbox/messageRules/{ruleId}
Authorization: Bearer <token>   # requires MailboxSettings.ReadWrite

Attackers frequently set both an inbox rule and mailbox-level forwarding so that removing one leaves the other running. Always clear both.

Never close the ticket on assumption. Confirm the rule is gone, the removal committed to the audit log, and no forwarding remains anywhere in the tenant.

# 1. Confirm the rule is gone for the mailbox
Get-InboxRule -Mailbox "user@domain.com"

# 2. Confirm the removal committed in the Unified Audit Log
Search-UnifiedAuditLog -Operations "Remove-InboxRule" `
  -StartDate (Get-Date).AddDays(-1) -EndDate (Get-Date)

# 3. Hunt every mailbox for remaining external forwarding
Get-EXOMailbox -ResultSize Unlimited |
  ForEach-Object {
    Get-InboxRule -Mailbox $_.PrimarySmtpAddress |
      Where-Object { $_.ForwardTo -or $_.RedirectTo -or $_.ForwardAsAttachmentTo } |
      Select-Object @{n='Mailbox';e={$_.MailboxOwnerId}}, Name, ForwardTo, RedirectTo
  }

The tenant-wide sweep in step 3 above catches the common case where the same attacker planted rules in multiple mailboxes. If you find others, run this same workflow for each one.

Close the loop with a record and a hardening action so the same rule cannot reappear:

• Document the rule definition, external address, creation time, attacker IP, and every action taken — pulled from your Step 2 snapshot and Step 1 telemetry.
• Notify anyone whose data may have been exfiltrated through the forwarding rule, and flag any in-flight financial threads for verification.
• Harden by blocking automatic external forwarding tenant-wide in the Defender outbound spam policy, enforcing phishing-resistant MFA, and enabling continuous inbox-rule monitoring against a known-good baseline.

For the full set of preventive controls, see our guide on detecting and fixing risky Microsoft 365 settings automatically.

Frequently Asked Questions