With a six times increase in COVID-19 themed incidents, security professionals need to take advantage of every possible configuration and security control to protect against this growing amount of attacks. Today we will discuss how attackers are leveraging a gap in Office 365 best practices that allows undetected eavesdropping on victim’s emails.
When attackers gain control of an account in Office 365, one of the first steps they often take is to configure email forwarding in the compromised environment. Attackers configure email forwarding in order to see new emails that arrive in the victim’s inbox – which can be responses to attacker phishing attempts sent to the victim contacts. In order to disguise their presence, the attacker does not want the victim to see those emails.
This also enables the attacker to gather information to better impersonate the victim and inject themselves into mail conversation for fraudulent intent such as redirecting money transfers. Cybercriminal and law enforcement commonly referred to this technique as “email eavesdropping” or “email tapping.”
For organizations, the solution should be straightforward – enable a policy that blocks email Forwarding throughout the tenant environment, but with exceptions for people that may require temporary forwarding (e.g. contractors, replacement for out of office employees, employees traveling without corporate access).
Unfortunately, no such solution exists in Office 365. Googling “O365 best practice” you will find the most common solution is to add a mail transport flow rule to block external message forwarding to stop a hacker from remotely eavesdropping. Unfortunately, this guidance does not apply to the Office 365 Outlook web client (OWA) will still allow attackers to successfully forward email. In this blog post, we will walk through the options available to organizations for configuring email forwarding and provide recommendations for best practices for different types of use cases.
We will start by discussing the pros and cons of the three different solutions that are commonly cited in public guidance: mail flow rules, exchange remote domains settings and PowerShell.
Mail Flow Rules
A number of public guidance documents, including the following URL, recommend the creation of Mail Flow rules for organizations:
Link to “Stop auto-forwarding emails in Office 365”
This guidance instructs the reader to create Exchange mail flow rule with the following attributes:
- If sender is inside the organization
- If message type is Auto-forward
- Reject the message and include an explanation
This guidance works well within the Office 365 Outlook client. A blocked email is presented below:
Mail Transport Flow Rule Blocks Message
However, this guidance does not apply to the Office 365 Outlook web client (OWA). Email forwarding can still be configured in the Outlook Web Client, as presented in the following screenshot, and emails are successfully forwarded.
Mail Forwarding Set on Outlook Web Access
When considering that attackers will often use OWA to access compromised client credentials, use of Mail Flow rules can be considered incomplete at best.
A more comprehensive solution for blocking all email is using the remote domains setting in Microsoft Exchange, which is presented below:
While this fix implements protection against email forwarding for all mailboxes, it is not a perfect solution. There are two known limitations to this approach:
- Lack of visibility - When the Remote Domains ‘allow automatic forwarding’ setting is disabled, the warning message from the mail flow rule will no longer trigger. As a result, visibility into whether email forwarding was turned on in an Outlook client will be lost. Even if forwarding is disabled, this visibility is important to identify if attempts to enable forwarding are made. These attempts may still be indicative of an account breach.
- Lack of granularity in implementation – The Remote Domains setting is on or off, it does not allow for potential exclusions (e.g. if one employee temporarily requires forwarding because of leave or travel requirements). The mail flow rule, if functional for both OWA and Outlook client, would enable greater granularity.
The third type of guidance uses PowerShell commands to create a new user mailbox role that removes the parameters responsible for the email forwarding functionality in OWA. We have not included that guidance in this discussion for two reasons:
- Implementation of multiple PowerShell commands to change Microsoft exchange settings is not a practical solution for many organizations, especially small and medium businesses
- SecureSky’s testing of the PowerShell guidance indicates that it is not effective.
For those interested, a link to the PowerShell guidance is presented below:
Link to Microsoft guidance that includes PowerShell remediation guidance
Based on these imperfect options, how should organizations address the risk of e-mail forwarding in their organization?
Any solution for email forwarding requires configuration and monitoring of Office 365 alerts to detect potential activities related to account compromise. Additionally, helping users understand how modern attacks against Office 365 work, and identification of signs their account has been taken over can help organizations detect potential attacks. (see the SecureSky blog on BEC attacks)
Three potential approaches for organizations to manage email forwarding are presented below:
- Blocking all forwarding - For organizations that can completely eliminate use of email forwarding in their environment, implementing the Exchange Remote Domains blocking to completely eliminate forwarding is recommended.
- Enable general forwarding – For organizations that wish to permit users to enable forwarding, monitoring of Office 365 alerts is essential to identify potential misuse or account takeover. The Mail Flow solution can be implemented to block access for Outlook clients.
- Enable IT-approved forwarding only – For organizations that wish to enforce IT control over user forwarding, a final approach would be to combine use of Mail Flow rules with Exchange Remote Domain blocking. When using both approaches, use of Mail Flow rules takes precedence. As a result, an organization can block all forwarding, and then whitelist individual users that do require forwarding. This is a more secure solution than enabling general forwarding. However, maintenance of this solution will require IT resources, and the configuration of this control is transparent to the end user, so organizational communication will be required for users to request forwarding to be enabled and subsequently disabled.
As always if you need more information from our Office 365 Security team we are here to help. Just send us an email @ firstname.lastname@example.org