Notifications
Clear all
Topic starter
14/07/2026 4:26 pm
TL;DR: Attackers are abusing native Microsoft 365 mailbox rules to exfiltrate data, suppress alerts, and sustain access after password resets, with Proofpoint observing malicious rules on about 10% of compromised accounts in Q4 2025. Mailbox rules are no longer a user convenience feature in identity terms, they are a persistence control boundary that many programmes still do not monitor.
NHIMG editorial — based on content published by Proofpoint: LLMjacking and mailbox-rule abuse in Microsoft 365 environments
By the numbers:
- 10% of compromised accounts in Q4 2025 had, in Q4 2025 had malicious mailbox rules created shortly after initial access.
- Attackers attempt access within an average of 17 minutes when AWS credentials are exposed publicly.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- Revoke sessions and reset tokens before closing the case Treat password changes as insufficient if malicious rules or OAuth abuse are present.
- 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.
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.
👉 Read Proofpoint's analysis of malicious mailbox rules and email hijacking →
Mailbox rules in Microsoft 365: what IAM teams are missing?
Explore further
14/07/2026 5:07 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Mailbox rules are a stealth persistence layer in Microsoft 365
