Working as a modern workplace consultant also means that sometimes you have to go deep into Exchange Online options in order to make sure that (sensitive) data of your customer doesn’t leave the organization without the proper security measurements taken. In the Microsoft documentation titled: “Best practices for configuring EOP and Office 365 ATP“, the recommended settings for both Standard and Strict states that Auto-forwarding to external domains should be disallowed or monitored at least.

Automatic email forwarding is one of the possible and still most common way (sensitive) company data might leave the organization. Giving the users the ability to automatically forward emails using either mailbox forwarding or message rules to users outside the organization in that case can be very risky. I’ve seen many cases where corporate email accounts were configured to automatically forward all email to personal gmail.com or hotmail.com accounts. Also still enabled mailboxes which forward mail to users personal accounts while the user doesn’t work at the company anymore is common practice. 

It’s also commonly known that if a user somehow gets compromised, hackers usually put a forward on the mailbox of the user in order to gain knowledge about the user in order further continue with their attack methods, or to retrieve sensitive company data for their own gains.

Good reason to disable forwarding of mail to outside of the organization for most of your users, create an exception list in rare circumstances where forwarding is needed and do so in a controlled way so that users are not all of the sudden flooded with non-deliverable emails telling them that auto forwarding is not allowed. This blogpost tries to address the options and a possible scenario on how to take the necessary steps.

Keep in mind that in most cases, the user enables the mail forwarding for a good reason, not aware of the risks. Therefore good communication towards the end-user explaining why automatic forwarding of email isn’t a good idea is necessary.

Ways a user can automatically forward email

A user has several options to automatically forward email to an external users, below are the options within Outlook Web Access (OWA), rules can also be created in Outlook and for forwarding in Outlook the link redirects to the Forwarding page in OWA:

If you measure, you know more

Before you start your next steps, it’s a good idea to get an idea of which users are forwarding email within your organization.

To get an idea of how many messages are auto-forwarded within your organization, Microsoft provides a dashboard in the Office 365 Security & Compliance portal. Initially it displays the amount of emails auto-forwarded in the past week, giving a good idea on what you are dealing with.

Auto-forwarded messages 
Messages auto-forwarded outside your 
organization in the past week 
6
Example count for the amount of emails auto-forwarded in the past week.

And if you click through you are presented with a more detailed view detailing how forwarding takes place, you get an overview of the types of forwarding (mail flow, Inbox rules or SMTP forwarding).

Messages auto-forwarded outside your organization 
Messages automatically forwarded to external domains might indicate a data breach. 
The data below shows information about automatically forwarded messages in the past week. Examine this 
information carefully and take any necessary action to mitigate the risk. 
Auto-forwarded messages by forwarding methods 
By mail flow rules: 
By Inbox rules: 
By SMTP forwarding: 
TO View details about the auto-forwarding methods and the top domains and users, click Forwarding report 
Auto-forwarded messages by domains and users 
Top 5 domains forwarded to: 
vansurksum.com 
wmug.nl 
Top 5 forwarding users: 
fkuhlman@emshelden.nl 
New domains (last week): 
2 
New users (last week): 
To view details about new domains and new users involved in auto-forwarding, click Forwarding modifications 
report 
Close 
Feedback
More detailed view

If you want even more details, you can click on the Forwarding report, which looks similar as below.

Home Dashboard Report Viewer - Security & Compliance 
Forwarding report 
This report shows your organization's automatically forwarded messages to external domains. You can view the forwarding methods, target domains, and source mailboxes that 
were used. You can also view the data as a summary chart or a details table. Learn more about this report 
Request report 
Forwarders 
Forwarding Type 
Mailbox Rule 
Mailbox Rule 
Recipient Name 
kenneth 
kenneth.vansurksum 
Recipient Domain 
vansurksum.com 
wmug,nl 
Deta ils 
15288493808828809... 
15288493808828809... 
Count 
bf View report Y Filters 
First forward date 
2/19/20 12:00 AM 
2/19/20 12:00 AM
Detailed report

If you have Microsoft Cloud App Security (MCAS), or Office Cloud App Security (CAS) available within your tenant there are several policies available out of the box which can be triggered and send to your Security Operations mailbox.

Cloud App Security 
Policies 
risk category... 
STATUS 
19 
TYPE 
policy 
Suspicious inbox forwarding 
SEVERITY 
01 -2 of 2 Policies 
count 
CATEGORY 
Severity 
This policy profiles your environment and triggers alerts when suspicious inbox forwarding rules are set on an. 
Suspicious inbox manipulation rule 
This policy profiles your environment and triggers alerts when suspicious inbox manipulation rules are set 
I open alerts 
O open alerts 
Threat detection 
Threat detection 
Action 
o 
o 
Create 
Modified 
Feb 10, 2020 
Feb 10, 2020
Default policies concerning auto-forwarding
Alerts > Suspicious inbox forwarding PM 
Suspicious inbox foruarding Microsoft Exchange Online Ferry Kuhlman 
Resolution options 
Description 
+32 
MEDIUM SEVERITY 
71.173209222 
A suspicious inbox forwarding rule was set on a user's inbox This may indicate that the user account is compromised, and that the mailbox is being used to exfiltrate information from your organization. The user Ferry Kuhlman (fkuhlman@emshelden.nl) created 
or updated an inbox forwarding rule that forwards all incoming email to the external address kenneth@vansurksumcom. 
Important information 
Microsoft Exchange Online (Default) was used for the first time in 180 days by this user 
Activity log 
I -I of I activities O 
Ip address 
o 
users 
o 
Act i vity 
Edit forwarding Inbox rule: Outlook Inbox Rule 1528849380... 
Ferry Kuhlman 
Ferry Kuhlman 
user 
Microsoft 
- I of I users and accounts 
fkuhlman@emshelden.nl 
ation 
Netherlands 
Gmps 
Investigate in Activity log 
Date 
Feb 19, 2020, 7:09 PM 
Feb 19. 2020, 709
Example alert triggered by the policy

Disabling Auto-forwarding to external domains

When searching on the internet about the best way to disable auto-forwarding, I quickly found the following article “The many ways to block automatic email forwarding in Exchange Online“. The article, written December 22nd 2017 details the available options in a detailed manner. To summarize, there is no real one click option which does the trick.

You either configure the remote domain option through Exchange Online Admin Center and disable “Allow automatic forwarding”, the big disadvantage of this option is that users are never notified, which is not something you want when disabling auto-forwarding in an existing organization where auto-forwarding is in use.

The other option is to create a transport/mail-flow rule to disable auto forwarding, only disadvantage is that the rule cannot block the Forwarding option on the mailbox of the user. This can be mitigated by creating a custom RBAC role and applying that role to the users. This will remove the forwarding tab from the OWA options at all.

Please read the article carefully and make sure that you are familiar with the options. In this case I decided to use the transport/mail-flow rule in combination with the RBAC role option. The rest of this post will detail my experiences when implementing the suggested options.

Implementation steps

Since we want to implement this change in the environment with minimal impact, we decided to include the users currently having some sort of auto-forwarding enabled in a group for which we will temporarily allow auto forwarding. By doing so, we block any new rules created, and we can reach out to the user already auto-forwarding and help them to find another solution for the reason they setup auto-forwarding to begin with. Once found, we simply can remove the user from the group. We also found that some accounts have a legitimate reason to auto forward, for example a company account which automatically forwards emails with attachments to a specific email address of a SaaS provider which automatically processes the attachment in the system.

Step 1: Investigate which users have auto-forwarding enabled and add them to a mail-enabled security group (in our case called “Allow auto forwarding”)

Step 2: Implement the transport/mail-flow rule from the referenced article in audit only mode and measure what is happening by generating incident reports

Step 3: Modify the transport/mail-flow so that we can exclude a group of users and keep monitoring for incident reports

Step 4: Enforce the transport/mail-flow rule if you a certain that all scenarios are working.

Step 5: Implement a process to review the Allow list on a regular basis

Lessons learned while implementing the mail flow rule

Before implementing the mail-flow rule I first thought about the scenario’s I wanted to test and came up with the following scenario’s:

Scenario 1: Email send from inside or outside of the organization and auto-forwarded to someone outside of the organization must be blocked, unless the user sending the email is member of the “allow auto forward” mail enabled security group.

Scenario 2: Email send form inside or outside the organization and auto-forwarded to someone inside of the organization must be allowed.

Based on the article, the following mail-flow rule was created in audit mode as a starter

Rule 
a https:// 
outlook.office365.com/ecp/RulesEditor/EditTransportRule.aspx?ActivityCorrelationlD=bf101 b... 
Block auto-forwarded email to external senders 
Name: 
Block auto-forwarded email to external senders 
X 
X 
•Apply this rule if.„ 
The recipient is located„. 
The message type is... 
add condition 
•DO the following.„ 
Reject the message with the explanation„. 
add action 
Except if... 
add exception 
properties Of this rule: 
priority: 
Audit this rule with severity level: 
Not specified 
'Client 
main Are
Initial transport/mail-flow rule

Since the proposed configuration lacked some way of reporting I decided to modify the rule and add the option “Generate incident report and send it to…” which sends the email in our case to our Security Operations shared mailbox, monitored by several of our security operators. 

Rule 
B https:// 
outlook.office365.com/ecp/RulesEditor/EditTransportRule.aspx?ActivityCorrelationlD=bf101 b... 
Block auto-forwarded email to external senders 
Name: 
X 
X 
X 
X 
Block auto-forwarded email to extemal senders 
•Apply this rule if„. 
The recipient is located... 
The message type is... 
add condition 
'DO the following... 
Reject the message with the explanation.„ 
Generate incident report and send it to... 
add action 
Except if... 
add exception 
properties Of this 
priority: 
'Client 
main Are 
Send incident report to: Insjght24_z 
SecQ25. with content:
Logging added

Add a shared mailbox which can monitor for the creation of auto-forwarding rules

Include message properties 
Select all 
sender 
recipi ents 
subject 
cc'd recipients 
bcc'd recipients 
severity 
sender override information 
matching rules 
false positive reports 
detected data classifications 
matching content 
original mail
Message properties

Make sure that you include just enough content in the email send to your shared mailbox so that you can determine if your security measures are correctly in place. 

Challenges while implementing an exclusion group

In order to test the exclusion we modified the transport/mail-flow rule and added the following Except if statement.

Except if... 
X The sender is a member of„. 
add exception 
'Allow auto forward'
Except if…

While testing the new rule in audit mode to also be able to exclude users we noticed some strange results, some emails from users on the allow list were hit by the rule.

Based on that I decided to test the different scenario’s and use the information in the Incident report to determine the following table:

Scenario Int/Ext Sender Recipients To
Automatic redirect all messages External Sending external email address Email address forwarded to Receiving internal email address
  Internal Sending internal email address Email address forwarded to Receiving internal email address
Automatic forwarding all messages External Receiving internal email address Email address forwarded to Email address forwarded to
  Internal Receiving internal email address Email address forwarded to Email address forwarded to
Automatic redirect with attachments External Sending external email address Email address forwarded to Receiving internal email address
  Internal Sending internal email address Email address forwarded to Receiving internal email address
Automatic forwarding with attachment External Receiving internal email address Email address forwarded to Email address forwarded to
  Internal Receiving internal email address Email address forwarded to Email address forwarded to

As you can see, when you want to exclude users, the users which are in your allow group sometimes are addressed as Sender, en sometimes as To, therefore we needed to modify the rule to include two Except if statements:

Except if... 
X The sender is a member o 
X The To or Cc box contains a member of... 
add exception
Except if… or…

More details about the performed tests can be found at the end of this blogpost, it might come in handy for reference or figuring out what was tested.

Final result

Below is a screenshot of the final result

Final Transport/Mail-flow rule

Conclusion

Do not simply copy everything that is stated in a blogpost from more than 2 years ago, things might have changed in the meantime, or you might have slightly different requirements.

Also make sure that when it comes to transport/mail-flow rules that you fully comprehend the solution and implement ways to measure if what you implemented actually is working as intended. Also using a phased approach when it comes to these kind of changes can come in handy, inform users of your new policy and make your company data more secure one step at a time.

Testing scenario’s

In order to determine the options needed in my transport/mail-flow rule I decided to test several options and investigate the information delivered by the incident send to the shared mailbox

Rules defined on mailbox of user: Ferry Kuhlman (fkuhlman@emshelden.nl), where in every scenario the email gets forwarded to Kenneth van Surksum (kenneth.vansurksum@wmug.nl)

External email used to send email to fkuhlman@emshelden.nl: Kenneth van Surksum (kenneth@vansurksum.com)

Internal email used to send email to fkuhlman@emshelden.nl: Stanley Messie (smessie@emshelden.nl)

Scenario 1: Create a forwarding on the mailbox using the mailbox forwarding option

1a – test using sending an email to the mailbox from an external account

1b – test using sending an email to the mailbox from an internal account

Conclusion: Forwarding is not picked up by the rule, you will not receive any incidents. Hence the reason to disable the option from the console using the custom RBAC role

Scenario 2: Create an automatic forwarding rule on all messages

2a – test using sending an email to the mailbox from an external account

Automatic forwarding (from kenneth@vansurksum.com to fkuhlman@emshelden.nl)

Sender: Ferry Kuhlman, fkuhlman@emshelden.nl

Subject: FW: Autoforwarding test (external)

Recipients: kenneth.vansurksum@wmug.nl

To: kenneth.vansurksum@wmug.nl

2b – test using sending an email to the mailbox from an internal account

Automatic forwarding (from smessie@emshelden.nl to fkuhlman@emshelden.nl)

Sender: Ferry Kuhlman, fkuhlman@emshelden.nl

Subject: FW: Autoforwarding test (internal)

Recipients: kenneth.vansurksum@wmug.nl

To: kenneth.vansurksum@wmug.nl

Conclusion: Automatic forwarding using a rule puts the email to which is being forwarded into both the Recipients and To field

Scenario 3: Create an automatic redirect rule on all messages

3a – test using sending an email to the mailbox from an external account

Automatic redirect (from kenneth@vansurksum.com to fkuhlman@emshelden.nl)

Sender: Kenneth van Surksum, kenneth@vansurksum.com

Subject: Redirect (external)

Recipients: kenneth.vansurksum@wmug.nl

To: Ferry Kuhlman, fkuhlman@emshelden.nl

3b – test using sending an email to the mailbox from an internal account

Automatic redirect (from smessie@emshelden.nl to fkuhlman@emshelden.nl)

Sender: Kenneth van Surksum, smessie@emshelden.nl

Subject: Redirect (internal)

Recipients: kenneth.vansurksum@wmug.nl

To: Ferry Kuhlman, fkuhlman@emshelden.nl

Conclusion: Automatic redirect rules puts the email to which is forwarded into the Recipients field, and the account receiving the email in the To field

Scenario 4: Create an automatic forwarding rule on messages containing an attachment

4a – test using sending an email to the mailbox from an external account

Automatic forwarding with attachment (from kenneth@vansurksum.com to fkuhlman@emshelden.nl)

Sender: Ferry Kuhlman, fkuhlman@emshelden.nl

Subject: FW: Forward with attachment (external)

Recipients: kenneth.vansurksum@wmug.nl

To: kenneth.vansurksum@wmug.nl

4b – test using sending an email to the mailbox from an internal account

Automatic forwarding with attachment (from smessie@emshelden.nl to fkuhlman@emshelden.nl)

Sender: Ferry Kuhlman, fkuhlman@emshelden.nl

Subject: FW: Forward with attachment (internal)

Recipients: kenneth.vansurksum@wmug.nl

To: kenneth.vansurksum@wmug.nl

Conclusion: Automatic forwarding emails with an attachment using a rule puts the email to which is being forwarded into both the Recipients and To field

Scenario 5: Create an automatic redirect rule on messages containing an attachment

5a – test using sending an email to the mailbox from an external account

Automatic redirect with attachments (from kenneth@vansurksum.com to fkuhlman@emshelden.nl)

Sender: Kenneth van Surksum, kenneth@vansurksum.com

Subject: Redirect with attachment (external)

Recipients: kenneth.vansurksum@wmug.nl

To: Ferry Kuhlman, fkuhlman@emshelden.nl

5b – test using sending an email to the mailbox from an internal account

Automatic redirect with attachments (from smessie@emshelden.nl to fkuhlman@emshelden.nl)

Sender: Kenneth van Surksum, smessie@emshelden.nl

Subject: Redirect with attachment (internal)

Recipients: kenneth.vansurksum@wmug.nl

To: Ferry Kuhlman, fkuhlman@emshelden.nl

Conclusion: Automatic redirect emails with an attachment rules puts the email to which is forwarded into the Recipients field, and the account receiving the email in the To field

Scenario Int/Ext Sender Recipients To
Automatic redirect all messages External kenneth@vansurksum.com kenneth.vansurksum@wmug.nl fkuhlman@emshelden.nl
  Internal smessie@emshelden.nl kenneth.vansurksum@wmug.nl fkuhlman@emshelden.nl
Automatic forwarding all messages External fkuhlman@emshelden.nl kenneth.vansurksum@wmug.nl kenneth.vansurksum@wmug.nl
  Internal fkuhlman@emshelden.nl kenneth.vansurksum@wmug.nl kenneth.vansurksum@wmug.nl
Automatic redirect with attachments External kenneth@vansurksum.com kenneth.vansurksum@wmug.nl fkuhlman@emshelden.nl
  Internal smessie@emshelden.nl kenneth.vansurksum@wmug.nl fkuhlman@emshelden.nl
Automatic forwarding with attachment External fkuhlman@emshelden.nl kenneth.vansurksum@wmug.nl kenneth.vansurksum@wmug.nl
  Internal fkuhlman@emshelden.nl kenneth.vansurksum@wmug.nl kenneth.vansurksum@wmug.nl