# When Password Changes Aren't Enough: The Hidden Threat of Malicious Mailbox Rules


When a business email compromise is discovered, the instinctive first response is almost always the same: change the password, enable multi-factor authentication, and breathe a sigh of relief. But newly surfaced research into Microsoft 365 intrusions suggests that this reflex, while necessary, is dangerously incomplete. Attackers who gain even brief access to a corporate mailbox are increasingly installing persistent, silent mechanisms that survive credential resets — and the most popular of those mechanisms is hiding in plain sight inside the very feature Microsoft built to help users organize their inbox.


## Background and Context


Mailbox rules, sometimes called inbox rules, are a legitimate productivity feature baked into Exchange Online, Outlook, and virtually every modern email client. They let a user automate how incoming messages are handled: move invoices to a folder, forward newsletters to a personal account, mark messages from the boss as important. For years, security teams have treated these rules as benign — an IT convenience, not a security control.


Threat actors have quietly exploited that blind spot. Investigations into business email compromise (BEC) cases over the past several years have consistently shown that once an attacker gets a foothold in a Microsoft 365 mailbox, one of their first moves is to plant one or more malicious inbox rules. These rules act as a beacon, a filter, and a cover-up all at once. And crucially, they persist independently of the account password. When the victim discovers the breach and rotates credentials, the rules remain in place, still routing mail, still hiding replies, still enabling the attacker to operate.


Newly released research reinforces what incident responders have been warning about: mailbox rule abuse is no longer a niche tactic. It is a mainstream, scalable, and often automated component of the modern email compromise playbook.


## Technical Details


The mechanics are straightforward, which is part of what makes this vector so effective. Exchange supports client-side and server-side rules. Server-side rules — configured through Outlook on the web, the Microsoft 365 admin center, or programmatically through the Exchange Web Services (EWS) and Microsoft Graph APIs — execute at the mailbox level regardless of whether the user's desktop client is open. Attackers favor server-side rules for exactly this reason.


Common malicious rule patterns observed in the wild include:


  • Auto-forwarding rules that silently copy incoming messages to an attacker-controlled external address, typically a lookalike Gmail, Proton, or disposable domain account.
  • Auto-deletion or move-to-RSS-Feeds rules that intercept security-related messages — emails containing keywords such as "invoice," "wire," "phishing," "fraud," "suspicious," or the victim's own domain — and move them to obscure folders the user is unlikely to check.
  • Reply suppression rules that delete bounce messages or out-of-band replies from finance teams, banks, or counterparties, preventing the victim from noticing that their identity has been used to redirect payments.
  • Conditional selective rules that only activate on messages from specific high-value senders, making the malicious behavior far harder to spot during routine review.

    • The rules are often created through Graph API calls using stolen OAuth tokens, adversary-in-the-middle (AiTM) session cookies harvested via phishing kits such as EvilProxy or Tycoon, or application consent grants that bypass MFA entirely. That last detail matters: if an attacker tricked the user into granting permissions to a malicious OAuth application, rotating the password does nothing. The application token remains valid until explicitly revoked.


    ## Real-World Impact


    For organizations, the cascading consequences of an overlooked mailbox rule can be severe and prolonged.


    Finance teams are the most frequent casualties. In a classic wire-fraud scenario, an attacker plants a rule that intercepts replies from a specific vendor or CFO. The attacker then impersonates the executive, alters banking details on a pending invoice, and watches the money move — while the legitimate user's inbox shows nothing amiss because all incriminating replies were silently filtered into a hidden folder.


    Legal and HR departments face similar exposure. Confidential negotiations, employment disputes, and M&A discussions can be quietly exfiltrated for weeks or months. Because auto-forwarding happens at the server level, traditional endpoint detection tools never see the traffic.


    And the persistence problem compounds breach costs. According to multiple incident response firms, mailbox rule abuse is a leading reason why BEC cases are reopened: the organization believes the intrusion is contained, only to discover months later that the attacker has been quietly reading executive correspondence the entire time.


    ## Threat Actor Context


    The financially motivated clusters behind BEC campaigns — tracked under labels including Storm-1167, TA4903, and a long tail of loosely affiliated affiliate groups — have industrialized this workflow. Many operate from phishing-as-a-service infrastructure that automatically provisions malicious inbox rules within seconds of harvesting credentials. Some kits ship with preconfigured rule templates tuned for specific industries: real estate closings, escrow firms, title companies, and professional services.


    State-aligned groups have also adopted the technique for espionage. Microsoft and Mandiant have each reported campaigns in which advanced actors, after obtaining access through password spraying or token theft, installed forwarding rules on the mailboxes of diplomats, defense contractor executives, and journalists. The same tactic that steals wire transfers steals policy drafts.


    ## Defensive Recommendations


    Security teams responding to any suspected mailbox compromise should treat rule enumeration as a non-negotiable part of the playbook, not an optional follow-up.


  • Audit all inbox rules after any credential incident. Use Get-InboxRule in PowerShell or query the Graph API's /users/{id}/mailFolders/inbox/messageRules endpoint across every affected account. Pay special attention to rules that forward externally, delete based on keywords, or move messages to rarely used folders such as RSS Feeds, Archive, or Conversation History.
  • Revoke active sessions and OAuth grants. Resetting a password does not terminate existing tokens. Use Revoke-AzureADUserAllRefreshToken or the equivalent Graph call, and review consented applications for anything unfamiliar.
  • Disable automatic external forwarding at the tenant level. Microsoft's default anti-forwarding outbound spam policy should be enforced, with explicit exceptions only where a business case exists.
  • Enable mailbox auditing and alert on rule creation. Defender for Office 365 and Microsoft Purview can flag new rules matching suspicious patterns. The New-InboxRule and Set-InboxRule events are high-signal indicators.
  • Deploy phishing-resistant MFA. FIDO2 security keys and certificate-based authentication defeat the AiTM attacks that enable most modern mailbox takeovers in the first place.
  • Educate end users. Prompting employees to periodically review their own rules — under Settings → Mail → Rules in Outlook on the web — catches quieter compromises that never trip enterprise alerting.

    • ## Industry Response


    Microsoft has incrementally tightened the ecosystem in recent releases: external forwarding is disabled by default for new tenants, the Unified Audit Log captures rule modifications, and Defender for Office 365 surfaces anomalous rule creation in its alerts queue. Third-party vendors including Abnormal, Proofpoint, and Vade have added dedicated inbox-rule analytics to their email security suites.


    Still, adoption lags. Industry surveys continue to find that a substantial share of Microsoft 365 tenants permit external forwarding and lack alerting on rule modifications. The research community's message is unambiguous: in an era of token theft and session hijacking, the password is no longer the perimeter. The mailbox configuration itself is.


    Until security teams treat inbox rules as a first-class audit target, attackers will keep using them — because a rule, once planted, outlives every password change the victim can think to make.


    ---


    **