A mail forwarding rule is persistence that survives a password reset
The standard response to a compromised account is to change the password and revoke the sessions. That response restores control of the account and leaves intact any configuration that the intruder added inside it. A forwarding rule is exactly that kind of configuration: it is a setting, it does not require the password, and it continues to operate after the credentials are replaced.
MITRE ATT&CK catalogues the technique under email collection. It appears in intrusion reports often enough that it should be a standard step in the response checklist rather than a specialist finding.
How the rule operates
Mail forwarding is a legitimate feature. A user configures the mailbox to send a copy of arriving messages to another address, and the mail system delivers to both locations. Nothing about that arrangement is unusual, and on many systems it is invisible in the recipient's view because the original message remains in the inbox.
An intruder who has temporary access to a mailbox creates a rule and then stops using the account. Subsequent mail is copied to an address the intruder controls, and the account owner sees no change because the messages are still arriving. The rule can be filtered to specific senders or keywords, which reduces the volume and keeps the forwarded traffic inside ordinary mail patterns.
Two variations matter for investigation. A rule that moves matching messages to a rarely opened folder keeps the content inside the organisation, where it is harder to detect as exfiltration and easier for the intruder to retrieve later if they retain access. A rule that forwards externally creates a copy on a system outside the organisation's control, which is a data breach regardless of whether the intruder reads it.
Why the reset does not remove it
The rule belongs to the mailbox, not to a session. Resetting the password invalidates the credentials and terminates active sessions, and the rule remains attached to the mailbox configuration. It will apply to the next message delivered, and it will keep applying until somebody deletes it.
Revoking tokens helps with a related class of persistence, where an application holds a refresh token and can re-authenticate without the password. Forwarding rules sit beside that mechanism rather than inside it, and a response that addresses only tokens leaves the rules in place.
Where to look
The rule inventory is per mailbox, and the administration interface exposes it centrally on hosted platforms. The checks worth automating are a forwarding address outside the organisation's domains, a rule that deletes or hides messages, and a rule that was created outside business hours or by a session whose source is unusual.
Some platforms require the destination address to be verified before a forward becomes active, which limits the attacker's ability to add an arbitrary address and is a reason to read the platform documentation for the specific service rather than assume uniform behaviour.
Detection improves when configuration changes are logged and forwarded to the same system that handles sign-in events. A rule creation then appears as an event beside the suspicious sign-in that preceded it, and the two together describe a sequence rather than two unrelated alerts.
Response steps
After a suspected mailbox compromise, the response should enumerate and remove forwarding rules, external delegates and any other automatic processing configured on the mailbox. Checking whether the destination address has received mail is part of scope assessment, because it determines whether the incident involves data leaving the organisation.
Where the mailbox had access to shared drives or applications, the same enumeration applies to those services, because temporary access is often used to configure persistence in more than one place. The general lesson is that credential rotation restores access control while configuration review restores the account to the state the owner expects.
Limitations
This article describes a documented technique and standard response practice. It reports no incidents, no measurements and no experiments. Platform behaviour for forwarding verification differs between providers, so the specific configuration should be confirmed in the documentation for the service in use.
References
- MITRE ATT&CK T1114.003: Email Collection - Email Forwarding Rule: https://attack.mitre.org/techniques/T1114/003/
- RFC 5321: Simple Mail Transfer Protocol: https://www.rfc-editor.org/rfc/rfc5321
- Google Workspace: Automatically forward Gmail messages: https://support.google.com/mail/answer/10957
Top comments (1)
The config-outlives-the-credential insight generalizes further than security: in email, a forwarding rule also changes what the mail is. When a mailbox forwards, the envelope sender changes at the relay, SPF now evaluates a different domain, and DMARC alignment can fail on a message that was perfectly valid at the first hop — which is exactly the gap ARC was built to patch. So the same invisible rule that exfiltrates mail for an intruder also silently breaks authentication for a legitimate user, and neither side sees an error. I hit this shape building email pipelines: the dangerous state is never the password, it's the configuration nobody re-audits. Do incident response checklists you see in the wild actually include a mailbox-rules audit, or is it still password-reset-plus-session-revoke?