Attackers use Email Hiding Rules to conceal malicious messages from users by creating inbox rules that move, archive, forward, or delete mail. Defenders should monitor for new or changed rules, especially after suspicious sign-in activity, and review whether rules target security alerts, invoice threads, or messages from executives.
How attackers turn email rules into stealth
email hiding rules are not about breaking into mail systems through technical exploitation, they are about persistence and concealment after access is already gained. Once an attacker can create or change mailbox rules, they can make malicious mail disappear from the victim’s normal view while still collecting notifications, invoice traffic, or executive correspondence.
The practical danger is that the mailbox still appears to work. Messages may be delivered, but they are silently moved, archived, forwarded, or deleted before the user notices. That makes rule abuse especially effective in business email compromise, account takeover, and follow-on fraud because the victim keeps trusting a mailbox that has already been partially controlled.
Rule abuse often pairs with other mailbox abuse techniques. If an attacker can also alter forwarding settings, suppress warning messages, or create rules that target security alerts, they can reduce the chance that the owner notices login alerts, password resets, or finance-related messages. The rule itself is simple, but its value comes from how it supports stealth, time, and control.
What to look for in a compromised mailbox
The clearest sign is a new or unfamiliar rule that the user did not create, especially one that hides messages containing terms like “invoice,” “payment,” “security alert,” or an executive’s name. A rule that auto-deletes alerts from the identity provider, finance system, or security team is more suspicious than a harmless sorting rule because it directly supports attacker concealment.
Review both the rule action and the rule scope. Attackers often prefer broad conditions that catch many messages, such as sender domains, subject keywords, or messages that mention attachments. They may also use very narrow conditions to target just the mail they need, which makes the rule harder to spot during a quick review. The right question is not just whether a rule exists, but whether it materially changes what the user can see.
Mailbox rule checks should be read alongside sign-in activity and recent consent or password changes. A suspicious sign-in followed by a newly created rule is a strong indicator that the mailbox was used as a hiding place, not merely as a communication tool. That is why mailbox review is most useful when it is time-linked to account activity rather than treated as a standalone hygiene task. See the broader email impersonation and mailbox abuse patterns in the Email Identity and BEC Guide.
How defenders contain the abuse path
The immediate containment step is to remove the malicious rule and then determine whether the attacker used the mailbox to forward mail, steal replies, or delete evidence. If the rule was present long enough to process sensitive mail, assume the attacker may have seen information that enabled payment diversion, phishing, or deeper account abuse.
Defenders should also look for related mailbox changes, not just the rule itself. A stolen account is often modified in multiple ways, so the same actor may have added forwarding destinations, OAuth mail permissions, or alternate inbox settings. For that reason, the most effective response treats rule abuse as part of a wider mailbox compromise review rather than a single isolated setting.
Where the mailbox belongs to an executive, finance user, or shared operations account, the bar for escalation is higher because hidden mail can enable fraud before anyone notices. In those cases, check whether messages were suppressed from security, banking, payroll, or vendor approval threads. A malicious rule is most dangerous when it changes the human review loop, not just the mailbox layout.
Risk and Threat Considerations
Email Hiding Rules create a low-noise persistence channel because they exploit ordinary mailbox features instead of malware. That means they can survive longer than an obvious phishing page or suspicious attachment, especially when users rarely inspect rules or message filters.
Failure mechanism: An attacker with mailbox access creates a rule that diverts or suppresses high-value messages, which reduces user visibility and can hide alerts, approvals, and recovery notices during the compromise window.
Impact: The mailbox remains operational from the user’s perspective, but critical mail is no longer trustworthy, which can extend compromise, delay detection, and support fraud or lateral abuse.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1114 — Email Collection | Email rules hide and redirect messages during mailbox abuse. |
| Recommendation — Hunt for mailbox rule abuse as part of email collection and review related forwarding activity. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Mailbox rule changes and suspicious sign-ins need reviewable audit evidence. |
| Recommendation — Review mailbox and sign-in logs for rule creation, modification, and mail-forwarding changes. | ||
| NIST CSF 2.0 | DE.CM-01 — Anomalies and Events Are Monitored | Detection depends on monitoring unusual mailbox behaviour and rule changes. |
| Recommendation — Monitor mailbox configuration changes and alert on unexpected inbox-rule activity. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Mailbox abuse often follows compromise of credentials or tokens that enable rule changes. |
| NHI-05 — Overprivileged NHI | Mailbox automation and app permissions can allow excessive rule or mail access. | |
| Recommendation — Rotate exposed credentials or tokens when mailbox rule abuse indicates account compromise. Limit mailbox and mail-access permissions to the minimum required for the account's role. | ||
Practitioner Guidance
What to prioritise: Treat any newly created or recently modified rule as higher priority when it appears after suspicious sign-in activity, a password reset, or a new consent grant. Rules that target alerts, payment mail, or executive correspondence deserve immediate review because they indicate the attacker is shaping what the victim can and cannot see.
What to verify: Confirm whether the rule was created from the user’s normal device, whether it matches the user’s usual mail habits, and whether mail was also forwarded, auto-deleted, or hidden from the inbox. If the answer is unclear, assume the rule is part of a broader mailbox compromise until proven otherwise.
Practitioner takeaway: The key judgement is to treat mailbox rules as a visibility-control issue, not a housekeeping issue, because attacker-created rules are often the mechanism that keeps the compromise quiet long enough to matter.