Email Forwarding Rule (T1114.003) is a sub-technique of Email Collection, in the collection tactic. MITRE lists Linux, macOS, Office suite and Windows.
This one deserves attention because it survives cleanup. Reset the compromised password and the rule keeps running. Many incident responders have to remember to check for it, because the account looks clean once the credentials change.
How attackers use it
MITRE describes adversaries setting up forwarding rules to monitor a victim's activity, steal information and gather intelligence for further operations. Most email clients let users create inbox rules, including rules that forward messages to another recipient. Rules can be created in a local email application, in a web interface or from the command line. Messages can go to internal or external recipients, and there is no limit on the extent of a rule.
Key points from MITRE:
- Any user, administrator or adversary holding valid credentials can create a rule that forwards all received messages to another recipient, or forwards by sender, and more.
- Forwarding rules can give persistent access to a victim's email even after compromised credentials are reset by administrators.
- Adversaries may hide a rule by using the Microsoft Messaging API (MAPI) to modify the rule's properties, making it hidden and not visible from Outlook, OWA or most Exchange administration tools.
- In some environments, administrators can enable rules that operate organization-wide. Microsoft Exchange supports transport rules that evaluate all mail an organization receives against specified conditions and then take a specified action. Abuse of such a feature affects far more mail than a single inbox.
How to detect it
MITRE's strategy is Email Forwarding Rule Abuse Detection Across Platforms. Analytics describe:
- Creation of inbox rules through PowerShell (New-InboxRule) or of transport rules through Exchange cmdlets, correlated with user behavior, cmdlet use and rule properties.
- Creation or modification of Apple Mail rules by changes to plist files or GUI automation such as AppleScript.
- Creation of forwarding or redirect rules in Exchange Online through New-InboxRule or transport rule cmdlets, including use of the forwarding address field.
- Changes to the Thunderbird message filters file, or use of command line tools such as formail or procmail that alter .forward behavior.
Operationally, you want:
- Audit events for rule creation and modification in your mail platform.
- A regular export of all forwarding settings for comparison with the last export.
- Alerts for any rule that forwards or redirects to an external address.
- Alerts for rules created from a new location or user agent, or soon after a suspicious sign-in.
- A check for hidden rules, since normal tools may not list them.
How to reduce the risk
MITRE lists four mitigations:
- Audit. Review auto-forwarding rules regularly. In Exchange, use Get-InboxRule and Remove-InboxRule, and Get-TransportRule and Remove-TransportRule, to find and remove malicious rules. A MAPI editor can examine the underlying database structure to find tampering with rule properties.
- Disable or remove a feature. Consider disabling external email forwarding.
- Encrypt sensitive information with public key encryption.
- Out-of-band communications. Verify critical actions requested by email through a separate channel, set up out-of-band alerts for mass forwarding or large attachments, and prepare a secure incident channel that does not depend on the in-network mail server.
If you do one thing, block automatic forwarding to external domains by policy and allow exceptions case by case. That removes the technique for most users.
Check your own environment
- Is automatic external forwarding blocked at the tenant or server level?
- Do you export and compare inbox and transport rules on a schedule?
- Does your incident runbook include a forwarding rule check after every account compromise?
- Can your tools show hidden rules?
- Who can create transport rules, and are those changes alerted?
# Exchange Online or Exchange (PowerShell): list inbox rules for one mailbox, including hidden ones
Get-InboxRule -Mailbox user@example.com -IncludeHidden | Select-Object Name, Enabled, ForwardTo, RedirectTo, ForwardAsAttachmentTo
# Exchange Online or Exchange (PowerShell): list organization-wide transport rules
Get-TransportRule | Select-Object Name, State, RedirectMessageTo, BlindCopyTo
# Exchange Online or Exchange (PowerShell): find mailboxes with a mailbox-level forwarding address
Get-Mailbox -ResultSize Unlimited | Where-Object { $_.ForwardingSmtpAddress -or $_.ForwardingAddress } | Select-Object DisplayName, ForwardingSmtpAddress, ForwardingAddress
Any rule you cannot explain, particularly one pointing outside the organization, should be reviewed with the mailbox owner.
Quick check
Why does a forwarding rule survive a password reset?
The rule is stored on the mailbox, not tied to the stolen credential. MITRE notes it can give persistent access even after administrators reset compromised credentials.
How can a rule be hidden?
By modifying the rule's properties through the Microsoft Messaging API (MAPI), which can make it invisible in Outlook, OWA and most Exchange administration tools.
What simple policy removes most of the risk?
Disabling external email forwarding, as MITRE suggests, with exceptions handled case by case.
Sources
- MITRE ATT&CK, Email Collection: Email Forwarding Rule (T1114.003)
