Security teams should treat newly created mail rules as a strong post-compromise signal and investigate immediately. The priority is to determine whether the rule forwards, deletes, or hides messages that expose attacker activity, then disable or remove it and review mailbox access, consented apps, and forwarding paths. Mail rules often survive password resets and MFA changes, so they must be checked during containment.
Why malicious mail rules matter during containment
Mail rules are not just inbox clutter, they are an active attacker control path. A rule that forwards, deletes, archives, or marks messages as read can hide evidence of the compromise, preserve access to sensitive mail, and keep the attacker informed after the initial login has been disrupted. Treat the rule as part of the intrusion chain, not as a housekeeping issue.
The key judgement is whether the rule changes message visibility or message flow in a way that gives the attacker a durable advantage. If it does, it should be handled with the same urgency as other persistence mechanisms, especially when the mailbox also shows suspicious sign-ins, consent grants, or forwarding changes. That is why mailbox rule review belongs in both triage and containment workflows.
Teams should also remember that mail rules can be created by the attacker after password compromise, by a malicious app with mailbox permissions, or by someone with delegated access. The operational question is not only “what does the rule do?”, but “what access path allowed it to exist?” That drives whether the response is limited to the mailbox or expands to identity and application review.
How to investigate rule behavior without missing the attacker’s intent
Start by enumerating all inbox, transport, and forwarding rules, then compare them against user expectations and historical mailbox behavior. Rules that target messages from security tools, finance, external senders, or executives are especially important because they often indicate the attacker is trying to suppress alerts, intercept approvals, or redirect replies.
Look for rules that create low-visibility conditions: automatic deletion, moving messages to obscure folders, hiding read receipts, setting messages as read, forwarding to external addresses, or triggering conditions based on sender, keywords, or domain. Those behaviours are often more important than the exact syntax of the rule because they reveal intent to reduce detection or control the victim’s view of the mailbox.
Evidence collection should preserve the rule definition, creation time, creator context if available, mailbox audit events, and any related forwarding or application-consent records. If the mailbox supports it, capture recent message traces to see whether the rule altered what the user saw versus what actually arrived. That distinction often reveals whether the attacker used the mailbox as a covert relay.
Containment priorities for compromised mailboxes
Once a malicious rule is confirmed or strongly suspected, disable it first and then assess adjacent persistence paths. In many compromises, attackers combine rules with forwarding settings, delegated access, OAuth consent, or reauthentication abuse, so removing only the visible rule can leave the compromise functionally intact. The practical goal is to remove the attacker’s ability to observe, divert, or suppress mail.
After rule removal, review mailbox access history, recent sign-ins, session status, and any connected applications that can read or modify mail. If the environment uses centralized mail security controls, check whether transport rules, automatic forwarding policies, or shared mailbox permissions also need to be adjusted. Where the mailbox is high value, reset credentials and revoke active sessions after the rule investigation so the containment action matches the suspected access path.
For organisations handling frequent email compromise cases, standardise a rule review checklist that includes external forwarding, hidden-folder routing, message deletion, read-state manipulation, and sender-based filtering. A repeatable review pattern reduces the chance that a subtle rule survives because it looks like ordinary user automation.
Risk and Threat Considerations
Malicious mail rules create both visibility loss and persistence risk. They can hide the symptoms that would otherwise alert the user or defenders, while continuing to route sensitive messages to the attacker after initial access is interrupted.
Failure mechanism: The attacker abuses mailbox automation to suppress inbound warnings, capture business-critical messages, or keep the victim unaware that mail is being diverted or removed.
Impact: Investigations can stall, compromise duration can extend, and follow-on fraud or data theft becomes more likely because the attacker retains a low-friction observation channel.
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 CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.AE — Anomalies and Events | Malicious mail rules are anomalous mailbox events that signal possible compromise. |
| RS.AN — Analysis | Mailbox rule behavior must be analyzed to determine attacker intent and impact. | |
| RS.MI — Mitigation | Containment requires disabling malicious rules and removing attacker persistence. | |
| Recommendation — Alert on suspicious mailbox rule changes and correlate them with other compromise indicators. Analyze rule actions, forwarding paths, and audit traces before closing the incident. Remove malicious rules, revoke related access, and close adjacent persistence paths. | ||
| CIS Controls v8 | 6.3 — Access to Electronic Content and Services | Mailbox rules often depend on unauthorized access to email content and services. |
| 8.2 — Audit Log Management | Rule creation and mailbox actions should be traceable in audit logs. | |
| Recommendation — Review and revoke unauthorized mailbox access paths that enabled rule creation. Preserve mailbox audit logs and use them to reconstruct rule creation and use. | ||
| MITRE ATT&CK | T1114.003 — Email Collection: Email Forwarding Rule | The question directly concerns malicious inbox forwarding and hiding rules used in email compromise. |
| T1098 — Account Manipulation | Attackers modify mailbox settings and access paths to maintain control after compromise. | |
| Recommendation — Hunt for forwarding-rule abuse and treat it as a post-compromise persistence technique. Inspect mailbox setting changes as account manipulation and remove unauthorized modifications. | ||
| OWASP Non-Human Identity Top 10 | NHI-07 — Access Governance | Compromised mailboxes often involve overbroad access and delegated mailbox permissions. |
| Recommendation — Review mailbox permissions and revoke unnecessary access that allowed rule abuse. | ||
Practitioner Guidance
What to prioritise: Treat the rule as evidence of active control over the mailbox, not a secondary artefact. The first decision is whether the rule changes message visibility or delivery in a way that affects containment urgency.
What to verify: Confirm whether any forwarding destination, hidden folder, or “mark as read” logic is still active elsewhere in the mailbox or in a connected application. If the mailbox has multiple automation paths, removing one rule is not sufficient to declare containment.
Common mistake: Teams often delete the visible rule and stop there. In practice, that can leave the attacker’s access path intact through consented apps, alternate forwarding, or stale sessions, which means the mailbox is still compromised even though the obvious indicator is gone.
Practitioner takeaway: A malicious mail rule is valuable to the attacker because it changes what defenders can see, so the response should focus on restoring mail integrity and proving the attacker no longer has a hidden delivery or visibility channel.
Related resources from NHI Mgmt Group
- How should security teams handle email compromise as an identity risk?
- What breaks when security teams treat email compromise as a mail problem only?
- How should security teams handle vendor email compromise in enterprise environments?
- How should security teams handle untrusted email payloads when a mail library supports raw message input and sandbox flags?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
