A forwarding rule is a policy that automatically routes an email, message, or network request from one destination to another. In identity and security operations, it can redirect alerts or traffic based on predefined conditions, creating control points that must be governed, logged, and reviewed to prevent misuse or blind spots.
What a forwarding rule does
A forwarding rule is a condition-based policy that automatically moves an email, message, or network request to another destination. It is useful for routing and continuity, but it also creates a decision point that can change where sensitive traffic is seen, stored, or acted on.
In security operations, forwarding rules are often used to redirect alerts, tickets, mail, or traffic to the right queue or system. That same convenience is what makes them sensitive: a rule can quietly alter visibility, bypass expected handling, or send information to an unintended endpoint if it is created or changed without oversight.
Why forwarding rules matter in security operations
Forwarding rules sit at the boundary between policy and movement. They can enforce normal workflow, but they can also become an unmonitored path for data exfiltration, message redirection, or control-plane manipulation when an attacker or insider can modify them. In email environments, a rule that forwards mail externally can conceal replies, invoices, or reset links from the real owner.
For network and messaging systems, the main security question is not only where data goes, but who can define the route and who can observe it after redirection. If the routing condition is broad, the rule may capture more traffic than intended. If the rule is hidden in a mailbox, gateway, or automation layer, defenders may miss the change until the downstream effect appears.
Business Email Compromise Response Playbook is useful here because forwarding-rule abuse is a common mailbox-compromise pattern and a frequent step in email fraud response.
Common failure modes and control implications
Forwarding rules fail when they are too permissive, too persistent, or too hard to see. Broad conditions can redirect the wrong messages, while long-lived rules can survive long after the original business need has passed. In identity and messaging workflows, the control problem is often less about the rule itself than about weak ownership, poor logging, and missing review of who created it and why.
Rules also create blind spots when they send data outside the normal review path. A forwarded alert may still “arrive” somewhere, but not where the intended responder expects it, which can delay incident response or let an attacker monitor communications without further interference. Where forwarding touches authentication resets, legal notices, or privileged operational traffic, the impact can extend beyond convenience into account takeover or business fraud.
Kimsuky Threat Actor Profile is a relevant reference because email forwarding rule abuse is one of the tradecraft patterns associated with phishing-led mailbox compromise.
How organisations should govern and review forwarding rules
Governance should focus on visibility, approval, and periodic review. Teams need to know which systems allow forwarding, who can create or change rules, what destinations are allowed, and how exceptions are recorded. Rules that redirect mail or requests outside the primary control plane should be treated as sensitive configuration, not routine convenience settings.
Practically, that means pairing forwarding-rule inventory with alerting, logging, and access review. If the rule can change delivery of security alerts, payment notices, or password resets, it deserves tighter change control than ordinary mailbox filters. Review should also include whether the rule still matches the intended business purpose and whether the destination is still trusted and monitored.
Use NIST SP 800-53 Rev 5 Security and Privacy Controls to ground logging, access restriction, and configuration-control expectations around rule creation and monitoring.
Detection and response after suspicious forwarding
Suspicious forwarding should trigger a search for related compromise, not just a configuration cleanup. Review recent rule creation and modification, confirm whether the destination is legitimate, and look for signs that the rule was used to hide replies, intercept reset messages, or divert operational traffic. If the rule is part of an email environment, also check for concurrent mailbox access, OAuth consent abuse, or other persistence mechanisms.
After removal, the follow-up question is whether the rule was the first symptom or only one layer of abuse. A clean rule does not prove a clean mailbox, and a deleted rule does not mean the attacker was not already reading or relaying content. The safest response is to verify the account, sessions, and downstream recipients that may have received redirected information.
OWASP Non-Human Identities Top 10 is helpful for thinking about secret leakage, overprivilege, and long-lived access paths when forwarding rules are tied to automation or service-driven workflows.
Risk and Threat Considerations
Forwarding rules are attractive to attackers because they can preserve access while reducing visibility. A malicious rule can silently reroute mail or alerts, making it easier to monitor conversations, intercept sensitive links, or delay response by sending critical information away from the intended owner.
Failure mechanism: The rule changes delivery without changing the sender’s expectations, so the compromise can remain hidden while information is diverted, duplicated, or lost.
Impact: Organisations can suffer mailbox compromise persistence, fraud, missed alerts, unauthorized disclosure, and delayed incident detection, especially when the redirected content includes resets, approvals, or financial instructions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 provides the primary governance reference for this term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-2 — Audit Events | Forwarding-rule changes need auditable events for review and investigation. |
| AC-6 — Least Privilege | Rule changes should be limited to authorized operators and owners only. | |
| CM-3 — Configuration Change Control | Forwarding rules are configuration changes that can alter security posture and routing. | |
| Recommendation — Log rule creation, modification, and deletion events for review and incident response. Restrict forwarding-rule administration to the minimum set of authorized accounts. Subject forwarding-rule changes to approval, tracking, and review before deployment. | ||
Practitioner Guidance
Why practitioners should care: Treat forwarding rules as a governed control surface, not a convenience feature. The important judgment is whether the rule changes who can see, act on, or respond to sensitive information, which makes it operationally significant even when it looks harmless.
What to watch for: Pay special attention to rules that forward externally, trigger on broad conditions, or appear soon after suspicious login activity. Those patterns often indicate that the rule is being used to preserve covert access or to bypass normal visibility.
Practitioner takeaway: If a forwarding rule can move sensitive traffic, it should be reviewable, attributable, and removable without guessing who owns it.