When a Microsoft 365 account is compromised, most security teams focus on resetting the password and revoking active sessions. That response is necessary — but it leaves a critical gap. An attacker who accessed a mailbox for even a few hours may have planted an Exchange Online persistence mechanism that keeps working long after the account is supposedly secured: transport rules and inbox redirection rules.
How these rules function as a persistence mechanism
Exchange Online operates on two distinct rule layers that are often conflated. Transport rules, or Mail Flow Rules, are configured at the tenant level by an Exchange administrator or any account holding the appropriate role. They intercept messages in transit before delivery. Inbox rules, on the other hand, operate at the individual mailbox level — they can be created through Outlook, OWA, or directly via the Microsoft Graph API and PowerShell — and they process messages after they land in the inbox.
An attacker with temporary access to a standard user account can create an inbox rule that automatically forwards every email containing sensitive keywords like "invoice", "contract" or "wire transfer" to an external address under their control. If they compromised an Exchange admin account, they can go further: build a transport rule that silently copies messages from multiple users into an external collection mailbox, without ever touching individual accounts again.
Why these rules go undetected
The stealth of this technique comes from structural blind spots. Inbox rules are treated as a mundane, legitimate feature — every user creates them to organize their mail. IT teams have no habit of auditing them proactively. Outbound forwarding generates no native alert in Exchange Online by default: the user receives no notification, no visible banner appears, and no log entry surfaces that a human would spontaneously check.
Consider a typical scenario: an attacker compromises an account through a targeted phishing email on a Friday evening. Using the Graph API, they create a forwarding rule in seconds, then disconnect. The security team detects the suspicious login on Monday morning and resets the password — but the rule is still active. Every email received over the weekend and the days that follow has been copied to the attacker's address. Without auditing rules as part of the incident response, no one will know.
Detecting rules through Microsoft Purview and the Unified Audit Log
The Unified Audit Log (UAL), accessible via the Microsoft Purview Compliance Portal or via PowerShell, records creation, modification, and deletion events for Exchange Online rules. The operations to prioritize are straightforward once you know what to look for.
For inbox rules, the relevant events are New-InboxRule, Set-InboxRule, and UpdateInboxRules. That last one is generated when a user creates a rule through Outlook's graphical interface, which makes it distinct from New-InboxRule — a rule created via API or PowerShell without any corresponding Outlook event is a strong signal of automated, potentially attacker-controlled activity.
A basic PowerShell query to extract these events from the UAL:
- Connect via
Connect-ExchangeOnlineandConnect-IPPSSession - Run
Search-UnifiedAuditLog -StartDate <date> -EndDate <date> -Operations New-InboxRule,Set-InboxRule,UpdateInboxRules -ResultSize 5000 - Filter results for rules containing
ForwardTo,ForwardAsAttachmentTo, orRedirectToparameters pointing to external domains - Cross-reference with
New-TransportRuleandSet-TransportRulefor tenant-level rules
Microsoft Defender for Office 365 includes preconfigured alerts for external forwarding rule creation. Confirm that the "Email forwarding rule" alert policy is enabled in your tenant and that the trigger threshold is properly configured — many organizations leave this at its default state and never verify it.
What audit data analysis actually reveals
During a post-compromise investigation, several fields in the audit logs deserve close attention. The ClientIPAddress value associated with the rule creation: if it differs from the user's usual IP or originates from a country inconsistent with their profile, that alone is a strong indicator. The UserId field clarifies whether the rule was created by the account owner or by a different account — relevant if an admin account was separately compromised. Timestamps matter too: a rule created at 2 AM on a Sunday, minutes after a login from an unknown IP, tells its own story.
SOC teams looking to operationalize this detection at scale will find that the Exchange and M365 lab catalog on the platform includes reproducible attack scenarios covering exactly this class of post-compromise persistence technique.
Remediation: password reset is just the start
Incident response on a compromised M365 account must systematically include a full audit of active rules, both at the mailbox and tenant level. In practice, that means running Get-InboxRule -Mailbox <UPN> for each suspicious mailbox, and Get-TransportRule at the tenant level. Any rule containing a forward to an unapproved external domain should be treated as malicious until proven otherwise.
Don't stop there. Also audit outbound SMTP connectors and mailbox delegation permissions — two vectors that are routinely overlooked during M365 investigations. If your SOC's detection coverage for M365 attack scenarios hasn't been formally assessed, an cyber maturity diagnostic can surface the blind spots before an attacker does.
Frequently asked questions
Does a forwarding rule created by an attacker survive a password reset?
Yes, and that's the core danger. Resetting a password revokes active sessions but does not delete inbox rules or transport rules that have already been created. These rules persist in Exchange Online configuration until explicitly removed, regardless of the account's authentication state.
What is the difference between New-InboxRule and UpdateInboxRules in the Unified Audit Log?
New-InboxRule is logged when a rule is created via PowerShell or the Microsoft Graph API. UpdateInboxRules is the event generated by the classic Outlook client when a user creates or modifies a rule through the graphical interface. A rule creation event that appears in the UAL as New-InboxRule without any associated Outlook client event suggests programmatic creation — a common pattern in attacker-controlled automation.
Do transport rules require administrator privileges to create?
Yes. Unlike inbox rules, which any user can configure for their own mailbox, Mail Flow Rules require the Exchange Administrator role or an equivalent delegated role. If a suspicious transport rule is discovered, compromising an Exchange admin account should be the first hypothesis to investigate.
Can external forwarding rules be blocked proactively?
Yes. It is possible to create a transport rule that blocks all automatic forwarding to external domains, using the AutoForwardEnabled condition or by targeting the X-MS-Exchange-Inbox-Rules-Loop header. Microsoft also provides an anti-forward transport policy that can be enabled at the tenant level — one that a large number of organizations leave disabled by default without realizing the exposure it creates.