Mailbox rules are a stealth persistence layer in Microsoft 365

At a glance

What this is: This analysis shows how attackers use Microsoft 365 mailbox rules to quietly exfiltrate mail, suppress warnings, and maintain post-compromise control.

Why it matters: It matters because mailbox-rule abuse sits at the intersection of NHI, IAM, and incident response, where standing access, OAuth abuse, and hidden automation can outlast a password reset.

By the numbers:

• 10% of compromised accounts in Q4 2025 had
• Attackers attempt access within an average of 17 minutes when AWS credentials are exposed publicly.

👉 Read Proofpoint's analysis of malicious mailbox rules and email hijacking

Context

Mailbox rules are a built-in email feature that automatically delete, move, forward, or mark messages. In identity terms, they become dangerous when an attacker turns them into a post-exploitation control plane that manipulates communications under a compromised user account. For IAM teams, the issue is not email hygiene alone, but whether account activity can be inspected after an attacker has already altered the message flow.

In Microsoft 365 environments, attackers often arrive through credential phishing, password spraying, brute force, or OAuth consent abuse, then immediately use the mailbox itself to hide evidence and extend access. That makes mailbox rules part of the access lifecycle, not a cosmetic mailbox setting. The starting position in this article is typical of modern business email compromise, not an edge case.

Key questions

Q: What breaks when malicious mailbox rules are not monitored?

A: When mailbox rules are not monitored, attackers can hide security alerts, suppress password resets, redirect vendor mail, and preserve covert access after the initial compromise. The mailbox still looks functional to the user, but the attacker controls what evidence and responses are visible. That turns a normal email account into a persistence and fraud channel.

Q: Why do mailbox rules remain dangerous after a password reset?

A: Mailbox rules persist inside the email platform, so changing the password does not remove the rule itself. If forwarding or suppression rules remain active, the attacker can still intercept messages or hide warnings. Organisations need lifecycle revocation for the mailbox, not only authentication changes.

Q: How can security teams detect mailbox-rule abuse early?

A: Watch for new rules that forward externally, delete messages, or route mail into obscure folders, especially when they appear within minutes of account compromise. Correlate those changes with risky sign-ins, OAuth consent events, and unusual user agents. Early detection depends on linking mailbox behaviour to identity telemetry.

Q: Who is accountable when a compromised mailbox is used for fraud?

A: Accountability is shared across identity operations, email administrators, and the business owner of the mailbox. If the account was not offboarded, not protected with the right authentication, or not monitored for anomalous use, the gap is a governance failure as much as a security one.

Technical breakdown

How malicious inbox rules create hidden persistence

Mailbox rules are evaluated by the email platform after messages arrive, which means they can alter visibility without changing authentication state. A rule can forward, delete, suppress, or reroute messages into low-visibility folders such as Archive or RSS Subscriptions. That gives an attacker a persistence layer inside the mailbox itself. Unlike malware, the behaviour stays inside native platform functions, which makes it harder to spot through endpoint-only telemetry. Because the rule operates after login, it can continue working even when the original password changes, as long as the rule remains in place.

Practical implication: monitor mailbox-rule creation as a post-compromise signal, not as a benign configuration change.

Why mailbox rules enable thread hijacking and business email compromise

Mailbox rules do more than hide mail. They let an attacker control which replies, alerts, and vendor communications the victim sees, which creates a communication blind spot inside existing business threads. In the article’s examples, attackers used rules to suppress payment and security-related messages, then leveraged the compromised mailbox to support fraud or impersonation. This is application-layer manipulation, not network interception. The attacker does not need to sit between mail servers if they can silently control message flow within the account that recipients already trust.

Practical implication: treat message-flow manipulation as a fraud and identity problem, not just an email-filtering problem.

How automation lowers the barrier to large-scale mailbox-rule abuse

Once an attacker has valid tokens or credentials, mailbox-rule creation can be automated through Microsoft Graph API, Exchange Online PowerShell, or direct API calls. That means the same pattern that starts as one compromised account can scale into dozens or hundreds of accounts with little effort. Proofpoint’s sample tooling shows how quickly a session token can become immediate access for post-exploitation actions. The relevant security question is not whether the attacker can write malware, but whether the environment makes native platform automation indistinguishable from legitimate administration.

Practical implication: build detections for rule creation at scale, not only for obvious malware or impossible travel.

Threat narrative

Attacker objective: The attacker aims to maintain covert access to email communications long enough to exfiltrate data, suppress detection, and support fraud or impersonation.

1. Entry occurs through credential phishing, password spraying, brute force, or OAuth consent abuse against Microsoft 365 accounts.
2. Escalation happens when the attacker creates malicious mailbox rules that suppress alerts, hide vendor mail, or forward selected messages to attacker-controlled destinations.
3. Impact follows through exfiltration, thread hijacking, and fraudulent communication that can persist even after password changes and user awareness improves.

Breaches seen in the wild

• MITRE ATT&CK Enterprise Matrix — MITRE ATT&CK Enterprise — adversary tactics and techniques, threat detection, attack chain mapping, credential access, lateral movement, privilege escalation.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Mailbox-rule abuse is a governance failure, not a mailbox feature problem. The attacker is using a legitimate identity control surface to create covert persistence, exfiltration, and communication suppression. That places inbox rules inside the IAM and incident-response boundary, not at the edge of email administration. The practitioner conclusion is that message-flow changes must be governed as identity events.

Hidden message routing creates an identity blast radius that most access reviews do not model. A mailbox rule can hide security notifications, financial approvals, and vendor responses from the account owner while leaving authentication untouched. That means the user can remain “signed in” while operational visibility has already been broken. The practitioner conclusion is that visibility into post-login actions matters as much as sign-in success.

Credential reset does not equal access reset when mailbox rules survive. The article shows that forwarding and suppression rules remain active after password changes, which means the access path can outlive the authentication event that created it. In governance terms, the control failure is persistence without lifecycle revocation. The practitioner conclusion is that offboarding and compromise response must include mailbox-rule teardown.

Native cloud features now behave like attacker infrastructure when left ungoverned. Exchange Online, Microsoft Graph, and OAuth-connected access give adversaries a low-friction path to automate post-exploitation behaviour without deploying traditional malware. That should push identity teams to classify mailbox configuration changes as high-signal events in the same way they treat privileged access changes. The practitioner conclusion is that cloud-native does not mean low-risk.

Mailbox-rule abuse shows why communication integrity is part of identity security. When an attacker can edit what a user sees, the compromise extends beyond account control into decision manipulation. That is especially relevant for finance, procurement, and vendor-facing workflows where trust is built through email continuity. The practitioner conclusion is that identity programmes need controls that protect both access and the integrity of the message stream.

From our research:

• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey.
• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.
• For a broader breach lens, The 52 NHI breaches Report shows how identity failures become operational incidents when governance trails execution.

What this signals

Mailbox-rule abuse is a warning that identity telemetry must extend beyond authentication events. When attackers can manipulate what users see after sign-in, the governance problem moves from access grant to access experience. Security teams should expect more post-login abuse patterns wherever native cloud controls can be scripted and hidden inside normal administration. The practical shift is to treat mailbox configuration drift as an identity signal, not a support ticket.

With 67% of organisations still relying heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey, the same governance weakness appears here: long-lived access artefacts outlast the moment of compromise. Teams that do not watch for post-login changes will miss the point at which identity becomes attacker infrastructure.

Identity blast radius: this is the point at which a single mailbox change can distort finance, procurement, and vendor trust at once. That is why teams should align email-rule monitoring with PAM, OAuth review, and incident response workflows rather than leaving it inside messaging operations. The next maturity step is to manage message integrity as part of the identity programme.

For practitioners

• Alert on suspicious inbox-rule creation patterns Flag new rules that delete messages, forward externally, or route mail into Archive, RSS Subscriptions, or other rarely checked folders. Prioritise minimal or nonsensical rule names such as punctuation-only strings, because the article shows those are common attacker choices.
• Revoke sessions and reset tokens before closing the case Treat password changes as insufficient if malicious rules or OAuth abuse are present. Invalidate active sessions, refresh tokens, and any mail-enabled app consent so the attacker cannot keep using the mailbox through existing access artefacts.
• Audit mailbox-rule changes alongside sign-in telemetry Correlate rule creation timestamps with suspicious IPs, unfamiliar user agents, risky authentication events, and recent OAuth grants. The goal is to identify the compromise window that preceded the rule, not just the rule itself.
• Disable external auto-forwarding by default Block automatic forwarding to external recipients unless there is a documented business need and explicit exception handling. This removes one of the simplest exfiltration paths used by attackers after mailbox compromise.
• Review finance and vendor threads for suppression effects Check whether payment, invoice, payroll, or vendor correspondence has been hidden, marked read, or moved out of the inbox. In high-risk business workflows, manipulations of message visibility can be as damaging as direct credential theft.

Key takeaways

• Mailbox rules give attackers a native persistence mechanism that survives the initial compromise and can hide both alerts and business-critical correspondence.
• Proofpoint’s observation that about 10% of compromised accounts received malicious rules shortly after access shows this is a recurring post-exploitation pattern, not an edge case.
• The control that matters is lifecycle revocation for mailbox behaviour, including session invalidation, token cleanup, and rule removal, not password reset alone.

Key terms

• Mailbox Rule Abuse: Mailbox rule abuse occurs when an attacker creates or changes email rules to redirect, hide, or preserve messages. It is an identity risk because the attacker is using legitimate platform behaviour to maintain visibility and persistence after access, often without triggering obvious authentication alerts.
• Communication Manipulation: Communication manipulation is the alteration of what a mailbox owner sees, misses, or believes inside an email workflow. It matters because attackers can suppress replies, hide alerts, and shape business decisions without needing network-level interception or malware on the endpoint.
• Session revocation: The ability to invalidate active sessions so access ends immediately instead of waiting for tokens or browser state to expire. For identity governance, this is the control that determines whether authentication still matters after a compromise is detected.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

What's in the full article

Proofpoint's full article covers the operational detail this post intentionally leaves for the source:

• Concrete examples of malicious mailbox-rule logic used for deletion, forwarding, and folder suppression.
• The Proofpoint-observed rule naming patterns and percentages that help security teams tune detections.
• Step-by-step incident response actions for removing rules, revoking sessions, and auditing OAuth applications.
• The ATOLS simulation workflow showing how session-token theft can be turned into automated post-exploitation actions.

👉 Proofpoint's full post covers the rule patterns, attacker workflows, and response steps in detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.