Stop automatic e-mail forwarding in Exchange Online

Here's the scenario:  A user's O365 account was successfully Phished.  The attacked logged in to Outlook online, rifled around the user's mailbox and then decided to implement an auto-forward rule to send any newly received messages to some external e-mail address.  

You dutifully killed the auto-forwarding rule as part of the account remediation.  But you ask yourself: why permit auto-forwarding to external e-mail addresses in the first place?  (in point of fact, a lot of organizations ban this practice in policy, citing that storing organizational information on systems outside of their reach is a good way to lose control of their intellectual property).

If you seek advice on banning the automated forwarding of e-mail to external addresses, you'll likely be told to setup an Exchange Transport Rule.  Here's an example:

https://support.office.com/en-us/article/stop-auto-forwarding-emails-in-microsoft-365-f9d693ba-5c78-47c0-b156-8e461e062aa7

That was easy?  Not so fast.  If you experiment with this, you soon discover that it is easily bypassed by an attacker.

All the attacker has to do is use "Redirect to" instead of "Forward to" or "Forward as Attachment" and your transport rule is effectively bypassed.  It is difficult to rely upon the naivety of attackers, so this method leaves much to be desired.

A more comprehensive alternative involves changing your Exchange policy for dealing with remote domains to prevent auto-forwarding.  

Portal.office.com > Admin > Exchange admin center > mail flow > remote domains > edit the default policy

This is very effective and most advice stops here.  

What if you have legitimate reasons to allow for auto-forwarding?  Is there a way to provide some kind of white-list?  Yes.

White-list scenario #1

Let's use the same technique applied above.  Scenario:  You want to block user's auto-forwarding to external e-mail's, but you have some existing processes that send e-mail tickets to an important third party business partner (e.g. BigAccountingFirm.com)

Portal.office.com > Admin > Exchange admin center > mail flow > remote domains > + to create a new policy

Of course, I don't recommend this for domains for which you don't have a high level of trust (e.g. those domains that host web based email).  

White-list Scenario #2

Consider where administrators have setup auto-forwarding e.g.:

Exchange Admin Centre > Recipients > mailboxes > (select the mailbox) > mailbox features > mail flow

So long a the recipient (in this example: FW-PonRatterson) is a contact, and not a raw SMTP address, it will successfully bypass the policy that denies auto-forwarding.

Under the covers:  This method of auto-forward sets the attribute DeliverToMailboxAndForward to $true.    The forwarding address is picked up from the attributes ForwardingAddress, and/or ForwardingSMTPSAddress.  The remote domains policy will block ForwardingSMTPAddress as external.  If a contact is placed within ForwardingAddress, even if it is an external address, it will not trigger the blocking response.  This information is important if you have to 'fix' existing Auto-Forward rules to grandfather them into your new policy framework.

Review or setup contacts:  portal.office.com > Admin > Users > Contacts

Limitations

Whitelisting isn't all have  your cake and eat it too'.  With white-listing in Scenario #1, you can still use more granular (conditional) outlook rules for auto-forwarding.  e.g.  If subject contains the word 'foo' then ForwardTo: email@bigaccountingfirm.com

You can't use contacts in outlook rules the same way: If subject contains the word 'foo' then ForwardTo FW-PonRatterson will still result in the policy blocking the email.  (Don't trust me?  Try it, and check your results in Message Trace).

If you can't whitelist the domain (Method #1) you may cleverly say "I'll create a shared mailbox that forwards to a contact (e.g. FW-PonRatterson).  Then I'll create the Outlook rule:  If subject contains he word 'foo' then ForwardTo the shared mailbox.  Since the shared mailbox is internal, outlook will route it there and the autoforward rule on the mailbox will send it to the external mailbox!".  This doesn't work.  Exchange will still block this.  Best of all, it will work when you test it manually, because a manual test isn't an "auto forward"! 

So be warned:  if you have conditional outlook auto-forwarding rules that you simply have to grandfather, you may have to re-scribe them as individual transport rules to get them out of Outlook.