Inbox forwarding rules can extend a phishing incident by copying incoming mail to an attacker-controlled address, which preserves access to replies, password resets, and business conversations. Security teams should review and remove unexpected forwarding rules, then check for mailbox delegation, OAuth consent, and suspicious sign-in activity.
How forwarding rules turn a mailbox compromise into a longer incident
Inbox forwarding rules matter because they convert a one-time phishing hit into persistent surveillance. Once an attacker has a rule that silently copies mail elsewhere, they can keep watching replies, reset links, invoice threads, and follow-on conversations even after the victim notices the phish. That makes the mailbox a continuing access path, not just an initial compromise.
Forwarding is especially useful to an attacker because email carries both communication and authentication workflows. The same inbox may receive password reset messages, account alerts, approval requests, and business decisions, so a hidden rule can preserve access to multiple downstream processes without needing the original phishing lure to stay active.
In practice, forwarding rules are often paired with other mailbox abuse, which is why a review should include delegated access and connected application consent as part of the same investigation. The goal is to find every route by which the attacker can still read or act on mail, not just the rule that was easiest to spot.
Why forwarded mail is so valuable to an attacker
A forwarding rule gives the attacker continuity. Even if the victim changes passwords or stops replying to the phishing message, the attacker may still receive later correspondence that reveals security codes, reset workflows, vendor payment instructions, and internal escalation messages. That is how a phishing incident becomes a broader business email compromise path.
Forwarded mail also creates a low-noise collection channel. It can blend into normal traffic, especially when the rule is hidden in a crowded mailbox or set to copy only specific messages. That makes it useful for long-running credential theft, invoice fraud, and conversation hijacking, where the attacker benefits more from patience than from immediate disruption.
Rule abuse is common enough that defenders should treat unexpected forwarding as evidence of mailbox collection rather than a harmless convenience setting. T1114 Email Collection Defensive Guide is useful here because it ties forwarding-rule abuse to detection and blocking approaches that limit an attacker’s ability to keep collecting mail.
What to look for after you remove the rule
Removing the rule is necessary, but it is not sufficient if the mailbox has already been used for follow-on access. Review sign-in history, OAuth consents, and mailbox delegation, then look for evidence that the attacker accessed mail directly before or after the rule was created. If the mailbox was used for resets or approvals, assume the attacker may have already touched additional systems.
It is also worth checking whether the forwarding destination belongs to an external personal account, a temporary inbox, or a cloud mailbox under attacker control. Those destinations can preserve the incident even after the original account is recovered, because the copied messages may contain links, attachments, or business context that support further abuse.
For operational response, the question is not only whether the forwarding rule existed, but how long it persisted and what it exposed. The more time the rule remained active, the more likely it is that the attacker saw sensitive conversations or used the mailbox to maintain trust with partners and colleagues. Phishing Incident Response Playbook is a good companion because it covers triage, scoping, and the downstream actions that follow mailbox compromise.
Risk and Threat Considerations
Unexpected forwarding rules create a durable collection channel that can outlive the initial phishing event. The main risk is not just mail theft, but sustained visibility into resets, approvals, invoices, and business threads that lets an attacker extend the compromise into fraud or account takeover.
Failure mechanism: The attacker adds or hides a rule that copies inbound mail to an external address, then uses the copied content to keep pace with replies, password resets, and sensitive correspondence even after the victim changes credentials.
Impact: The incident can expand from a single phish into ongoing surveillance, credential recovery abuse, business email compromise, and potentially fraudulent actions taken with information learned from the mailbox.
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 API Security Top 10 address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1114.003 — Email Collection: Email Forwarding Rule | Forwarding rules are the core collection mechanism in this incident pattern. |
| Recommendation — Detect and block malicious forwarding rules, then hunt for related mailbox collection activity. | ||
| CIS Controls v8 | CIS-5 — Account Management | Unexpected forwarding and delegation are account-abuse conditions that need review and removal. |
| Recommendation — Review and remove unauthorized mailbox forwarding and delegated access paths promptly. | ||
| NIST CSF 2.0 | DE.CM-09 — Monitoring for Unauthorized Personnel, Connections, Devices, and Software | Mailbox forwarding abuse is a monitoring and detection problem requiring continuous review. |
| Recommendation — Monitor mailboxes for unauthorized forwarding, delegation, and suspicious access changes. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Mail forwarding and delegation can exceed what a user should be able to expose or redirect. |
| Recommendation — Limit mailbox and delegation privileges to the minimum needed for each role. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | The incident often persists by abusing stolen or replayed mailbox access and consented sessions. |
| Recommendation — Investigate and revoke any compromised authentication paths alongside mailbox cleanup. | ||
Practitioner Guidance
What to verify: Confirm whether the forwarding rule was created intentionally, whether it is still active, and whether any mailbox delegation or OAuth grant provides the same or broader access path. If you find external forwarding plus unusual sign-in activity, treat the mailbox as actively compromised until proven otherwise.
Decision rule: If the mailbox has handled password resets, payment approvals, or executive correspondence, prioritise containment and credential reset before you spend time on message-by-message cleanup. The operational risk is often in the downstream use of the inbox, not the original phishing email.
Practitioner takeaway: The critical question is whether the mailbox still gives the attacker a live view of business and recovery traffic, because forwarding rules turn a recovered account into a continuing source of exposure.
Related resources from NHI Mgmt Group
- Guide: Business Email Compromise Awareness for Finance Teams Guide
- Why do mailbox rules make phishing incidents harder to contain?
- Why do inbox rules and external forwarding make Microsoft 365 BEC attacks harder to detect?
- How do you detect suspicious inbox forwarding and manipulation rules in Microsoft 365?
- How should security teams detect malicious inbox rules that use Unicode obfuscation?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org