Detecting suspicious email forwarding rules on Office 365

Despite costing companies untold billions of dollars every year, email account compromise (EAC), business email compromise (BEC), and other email-based scams garner less attention—from defenders and media alike—than costly and often high-profile ransomware attacks. In today’s blog, we’re going to discuss the scope of email-based threats and offer guidance on what security teams can do about it.

Specifically, we’re going to talk about how Office 365 telemetry can help you detect email-based threats—and even more specifically about how we’re developing detection analytics that use Microsoft Unified Audit Logs to catch adversaries who attempt to forward email messages, a behavior associated with all variety of email-based threats and a wide variety of other attack techniques. Additionally, we’re going to explain how you can leverage this telemetry source in your own environment, and we’ll also include some tests you can run to validate your detection coverage.

The problem, quantified as best we can

According to the FBI Internet Crime Complaint Center (IC3), BEC alone cost victims more than $43B between June 2016 and December 2021—a figure that only increases when you combine it with other email-based threats. Cost estimates for ransomware, on the other hand, are all over the place, with the IC3 (almost certainly under-)reporting $30M in losses in 2020. Another oft-cited (but unsubstantiated) report estimates that ransomware might have cost as much as $20B in 2021.

Whatever the actual numbers are, the damages caused by email schemes are right on par with those caused by ransomware—and therefore, we should probably make sure we’re not treating these email-based threats as an afterthought.

An example, so we can show you how to detect bad things

We’re focusing on just one variant of email compromise in this article, namely those that involve an adversary who leverages email forwarding rules. Let’s talk through how things might play out before we describe some detection and testing options.

We’ll start at the point where an adversary has successfully logged into a victim’s mailbox. From there, an adversary can attempt to maintain access for as long as possible, quietly collecting valuable or sensitive information by simply reading through individual email messages, manually exporting messages to review offline, or stealthily forwarding email messages to external email accounts. In the latter scenario, adversaries may create email forwarding rules tied to a user’s account that auto-forward all or specific emails to an external SMTP address. Auto-forwarding emails in this way allows an adversary on-demand and real-time access to email messages without worrying about the legitimate user deleting emails or even changing their password. In other words, adversaries set up forwarding rules as a form of insurance in case they lose access to their victim’s email account.

Adversaries set up forwarding rules as a form of insurance in case they lose access to their victim’s email account.

In our example, we’ll say the adversary is only interested in emails that contain terms like “direct deposit,” “wire transfer,” or “password reset.” As such, they can set up a rule that automatically moves any emails containing those words in any part of the email to a mailbox folder the victim rarely checks, like their “RSS Feeds” or “Archived” folder. Part of the email rule might even mark the message as “read” or delete it altogether before forwarding the message to an external mailbox.

From here, if a message about fund transfer gets forwarded to the adversary, they might then respond to the sender (posing as the victim/recipient) with an email containing the direct deposit information of an account controlled by the adversary in an attempt to goad the victim into initiating a fraudulent wire transfer. Alternatively, they may just use the collected emails to launch additional phishing campaigns against the victim’s colleagues to further entrench themselves in the environment.

A solution, so you can defend against email threats

Luckily for defenders, many enterprise email clients collect audit logs that you can use to detect suspicious email rules. Microsoft Exchange and Office 365 provides robust logging of user mailbox activity in the Unified Audit Log in the Microsoft 365 Compliance Center, which was recently renamed to the Microsoft Purview Compliance Portal.

These logs provide visibility into the actions a user conducts in their mailbox, including the creation of new email rules, what’s been modified or accessed, records of user logons (or failed logon attempts), and much more. Over the last year or so, Red Canary has started collecting telemetry from these log sources and using that telemetry to develop detection analytics that pretty reliably catch malicious email forwarding, but more on that in a moment (spoiler alert: legitimate email forwarding rules are relatively uncommon and pretty easy to baseline).

Setting and logging forwarding rules

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 follow parameters can be used to modify mail-forwarding rules with New-InboxRule, Set-InboxRule, Remove-InboxRule, and Disable-InboxRule Operations: