Detecting O365 AutoForward Rules using Splunk


Recently, Microsoft O365 AutoForward rules are back in the news as SANS suffered a data breach on August 11, 2020. The full details of the breach can be found here. If you hadn’t heard about the incident basically an attacker successfully phished a SANS employee which resulted in a malicious O365 cloud app and an auto-forwarding rule being installed/enabled on the victim user’s account. SANS detected the breach within a few weeks of the incident during a routine O365 audit.

There are multiple ways in which these auto-fowarding rules can be detected. SANS was gracious enough to provide a walk-through as an ISC diary (courtesy Rob VandenBrink) which can be found here. There is also a very neat and useful tool developed and maintained by Canthv0 called Hawk, which is touted as a “Powershell Based tool for gathering information related to O365 intrusions and potential Breaches”. I’ve personally used Hawk and have found it useful as an audit tool.

For organizations that do not have the capability to implement a SOC or even a SIEM solution due to money or talent restraints the above options are certainly worth checking out. However, for those organizations that already have a SIEM this article is going to walk through the methodology and implementation of an additional proven detection for this type of attack technique.

What I’ll be Using

  • Splunk with the O365 App installed — install instructions can be found here.
  • O365 Logs

First and foremost — the point of collecting all the O365 management logs into Splunk is to allow for the easy and fast correlation between events; after all that’s what your SIEM should be doing for you and where Splunk really shines. (no im not a Splunk rep)

Build the Splunk Search (SPL)

Ignore my index/sourcetype names as they may be different within your environment.

Here is an example of the log from an auto-forwarding rule being created:

So how do we find the above event?

There are a few key field value pairs we want to use as filters. Since we’re focusing on auto-forwarding rules created within the O365 Exchange app we’ll be narrowing our search to only the Exchange workload.

Futhermore, the operation, Set-Mailbox, is for events related to modification of the settings of an existing mailbox. In this case the attacker will be modifying the mailbox to create a new rule.

Additionally, we’ll want to focus on only events that contain parameter names ForwardingSmtpAddress or DeliverToMailboxAndForward. Make sure to ignore parameters values that are blank.

  • ForwardingSmtpAddress — this value will filter down results to ONLY those that have a forwarding address.
  • DeliverToMailboxAndForward in my testing this value wasn’t always present as some mailbox rules would be set to just forward mail like a pass-thru rather than deliver the message and send a copy (which this parameter indicators).

From the above example you can see the Parameters{}.Value =

Combined SPL

index=*_o365 sourcetype=”ms:o365:management” Workload=Exchange Operation=Set-Mailbox (Parameters{}.Name=ForwardingSmtpAddress OR Parameters{}.Name=DeliverToMailboxAndForward) Parameters{}.Value!=””
| fields index sourcetype CreationTime ClientIP ObjectId Operation UserId Parameters{}.Value Parameters{}.Name OrganizationName RecordType UserType
| table index sourcetype CreationTime ClientIP ObjectId Operation UserId Parameters{}.Value Parameters{}.Name OrganizationName RecordType UserType
| sort -CreationTime
| rename ClientIP AS src_ip, CreationTime AS event_time, ObjectID AS Account_Name, “Parameters{}.Value” AS value, “Parameters{}.Name” AS value_name

Below is an example output based on the above search.

How do i get alerted to this activity?

For Splunk customers that have Enterprise Security you would simply create a new correlation search and use the notable Adaptive Response action to generate an alarm that would show up in the Enterprise Security main dashboard. Instructions on how to do that can be found here.

For Splunk customers not paying for Enterprise Security, you can create a scheduled search that sends an email with the results of the search. The scheduled search can be set to run at whatever interval or schedule you want.

Quick note — this rule will ONLY detect auto-forward rules that are created on the server! If the user or attacker creates the rule locally on the victim’s workstation this will NOT detect that as the rule is not stored in the O365 tenant. Moreover, your mileage may vary when it comes to the volume of false positives as it heavily depends on your organization’s policy and guidance regarding forwarding emails outside the corporate environment. If its against policy to enable this type of rule, Microsoft gave you the ability to stop it from even happening.

Hopefully you found this article helpful. Happy hunting!

Cyber Security enthusiast, detection developer and engineer, researcher, consultant.