Proofpoint flags mailbox rule abuse in Microsoft 365

Proofpoint has identified growing abuse of Microsoft 365 mailbox rules after cloud account takeovers. The cyber security company found the tactic in about 10% of the compromised accounts it analysed in the fourth quarter of 2025.

The findings highlight a form of post-compromise activity that relies on built-in Microsoft 365 features rather than malware or separate command-and-control systems. Once inside an account, attackers can create rules that forward messages to external addresses, delete incoming emails, or move them into folders users rarely check, such as Archive and RSS Subscriptions.

This helps attackers hide their presence while continuing to monitor communications. It can also suppress security notifications, including alerts tied to account activity or multi-factor authentication, and in some cases preserve access to useful information even after passwords are changed.

Proofpoint's analysis found that malicious rules were often created very soon after initial access. Some appeared within five seconds of compromise, suggesting a high degree of automation in at least some attacks.

The naming patterns were also notably consistent. The most common rule names were short symbols or punctuation marks, including a single full stop, multiple full stops, and semicolons. Researchers linked this to template reuse across phishing kits and phishing-as-a-service operations.

Fraud tactics

One incident involved the compromise of an Accounting Specialist's mailbox. An attacker created a rule named ... that archived emails with the subject line "FW: Payment Receipt" and then used the account to send an internal phishing campaign to 45 colleagues.

The campaign led to the compromise of a second account belonging to the Chief Executive Officer's Assistant. The attacker then created another rule to suppress emails about payroll enrolment and sent a fraudulent payroll request from the compromised mailbox.

By hiding both replies and security alerts, the mailbox rules helped the attacker maintain control of the conversation. The case shows how rule abuse can support internal impersonation and payment fraud without changing infrastructure outside the victim's Microsoft 365 environment.

Thread hijacking

Another case involved email thread manipulation. After gaining access to a mailbox, an attacker created a rule that moved all emails from Zoho into the RSS Subscriptions folder, preventing the user from seeing verification messages.

The attacker then registered a spoofed domain using a homoglyph trick, such as replacing the letter O with a zero, and created lookalike email addresses through Zoho. Those addresses were inserted into an ongoing payment discussion between the victim and a third-party supplier.

The apparent goal was to claim that funds had not arrived and persuade the other party to make a duplicate payment into an account controlled by the attacker. Even after the original compromised mailbox was suspended, the external spoofed infrastructure remained in place.

Higher education

University environments showed a different pattern from business email compromise cases. In these incidents, attackers often set up unconditional rules that archived or deleted all incoming mail, effectively cutting off the legitimate account holder while using the mailbox for spam or phishing campaigns.

These campaigns included fake job adverts, scholarship scams, and fraudulent marketplace listings. The report found that dormant accounts linked to former students or retired staff were frequently targeted because they often predated current multi-factor authentication and conditional access policies and were less likely to be closely monitored.

The use of APIs and administrative tools adds to the scale of the issue. Attackers can use Microsoft Graph API and Exchange Online PowerShell to create rules across large numbers of compromised accounts, turning what may begin as individual account breaches into broader campaigns.

Detection gap

For defenders, the broader concern is that mailbox rule abuse can be easy to miss because it takes place entirely within the application layer. There is no need for network interception, and the activity may resemble legitimate account behaviour unless organisations inspect rule creation, forwarding settings, and OAuth permissions.

Recommended safeguards include disabling external auto-forwarding by default in Exchange Online, enforcing conditional access and multi-factor authentication, and monitoring OAuth consent grants that request Mail.Read or Mail.ReadWrite access. When malicious rules are discovered, response measures should include removing unauthorised rules, revoking active sessions and refresh tokens, checking Entra ID sign-in logs, and reviewing OAuth applications with mailbox access.

The data suggests the technique has become a regular feature of account takeover operations rather than an edge case, with mailbox rules serving as a quiet but effective way to support fraud, deception, and data theft inside Microsoft 365.