If you have a third-party filtering provider or are planning to move to one, this is a must read! Attackers can bypass your third-party gateway systems delivering spam and malicious content directly into Office 365 with email never going to your MX record. So, you may ask yourself, “How can this even be possible and am I affected?” If your company is using a third-party filtering software in the cloud or on-premise and your MX records are pointing to these devices, then you are affected. If you do not use a third-party filtering software and your MX records go directly to Office 365 and your EOP settings are already configured for protection, then you have little to worry about.
Why do companies use third-party filtering instead of O365 EOP?
Well, it’s an extra layer of protection. While EOP is great, it can’t do everything. Vendors these days have all in cumbersome solutions rolled into one solution. For example, Forcepoint, Fire eye, Symantec technology not only scans for viruses, malware etc., it also can be used as a proxy solution for internet browsing and blocking of malicious sites. Microsoft also provides a very good page on different scenario setups with third-party filtering here. The third-party mail flow we are working on will look like the below:
How attackers do the bypass
Once a domain is added and verified into Office 365 there is a default domain appended to every tenant. You can view your tenant setup by going to Setup and Domains within the admin portal. Typically, when you do the registration most admins will configure the tenant with the company name. For example, in domains, you may see “companyname.onmicrosoft.com”
Attackers research companies by doing the following to determine if the bypass is open or not. So, let’s do the research portion first on a couple of domains. Attackers are aware the normal MX records for the onmicrosoft.com domains are usually “CompanyName.onmicrosoft.com” This is the basis of domains hosted in Office 365.
Using MXtoolbox.com, search for your domains first, then we will search for the default onmicrosoft.com domain. In this case, I am going to test with two name brand companies, however, I will be blocking the actual names out for privacy. Company1 and Company2 throughout the article.
Company1 and Company2 have their email routed through pphosted.com Proofpoint, likely doing email scanning. But how do we know they host their email with Office 365? We do an MX query for their companyname.onmicrosoft.com. Based on the mail.protection.outlook.com result below they are hosted in Office 365 as these domain records are only created by Microsoft when new tenants are created and validated.
By using this technique and knowing company names, attackers can script out an MX DNS query for company names looking for this information. This is how attackers get a clear database of whose email is hosted in Office 365 or using a third-party filtering solution.
Now to conduct email flow to the onmicrosoft.com domain for your tenant you must know the onmicrosoft.com mail routed address. If you have done an on-premises to Office 365 migration you may recall the email address that gets stamped to your users is in the form of “companyname.mail.onmicrosoft.com”. You can check this by looking at the attributes of your user’s target address like below. However, this isn’t always the case. Depending on who conducted your migration they may have changed this to something else. Often it will be as below:
For my company, whoever set up the initial configuration in Office 365 used mail.onmicrosoft.com. Let’s see if Company 1 and Company 2 used this same setup.
We can clearly see that users are more than likely stamped with username@company1.mail.onmicrosoft.com as their target address in Active Directory, or stamped on their cloud users as another email address. These servers at Microsoft will accept email for their companyname.onmicrosoft.com default domain address or their standard company1.com or company2.com email addresses for example. This is not the standard mail flow design if your company is using a third-party solution that is accepting your email first.
Testing the theory
Say it isn’t so! Now that we know the destination IPs for the MX records directly into the Microsoft servers, the email address of users and that onmicrosoft.com accepts email for “company1.mail.onmicrosoft.com” and “company1.com” we can move on to the testing phase.
Test 1 via Office 365 test tenant
If you want to ensure a true test from outside your network (like an attacker) and have access to a test tenant, you can create a connector scoped for “*.company1.com” (your companies domain) that will deliver directly to “company1-mail-onmicrosoft-com.mail.protection.outlook.com”. This is the best way to ensure your tests aren’t coming from known IPs on your network. Please note creating a connector to the IP address of Microsoft servers will fail with a reservation statement. You must use the full name in the connector. If you don’t have a test tenant then it’s best to create one, even if it’s for a trial period.
Open Exchange PowerShell and login to your Office 365 test tenant. The command below will create a new connector.
New-OutboundConnector -name ‘testbypassdelivery’ -ConnectorType ‘partner’ -RecipientDomains *.company1.com -UseMXRecord:$false -SmartHosts company1-mail-onmicrosoft-com.mail.protection.outlook.com
Once the connector is in place you can log in to a test mailbox in your test tenant and send an email to yourself and then we can review the headers.
Before we check to see if the bypass is successful lets first look at the email headers of the correct path via your third-party gateway. Normal mail flow through your MX record to your third-party solution should look like the below. You will see the email comes in via third-party vendor on a normal email transaction in hops 4 and 5 below.
Now that you have sent a test email to yourself let’s check the headers from the test email you sent. In the below image you can see the test email is all outlook.com traffic showing that the email you sent completely bypassed your third-party gateway due to the connector we created.
Test 2 via Telnet (if you do not have a test tenant)
Based off your own domain query you can telnet to the IP listed in your “companyname.mail.onmicrosoft.com” MX record.
Conduct an email test from a fake address to yourself via telnet. Note, you do not have to use the mail.onmicrosoft.com target address. Simply using the domain name will work as it’s still a routed domain within the Microsoft tenants. E.g.: alias@company1.com
As you can see, the email has been delivered.
Let’s check the headers though over at https://testconnectivity.microsoft.com of this email that just bypassed your third-party filtering software.
Even with the telnet-based mail flow, you do not see the third-party solution in the traffic path, therefore, showing the email bypassed your third-party solution. This traffic shows all outlook.com to outlook.com Office 365 traffic only from the telnet test.
And this is how attackers are bypassing your third-party solutions and dropping emails straight into your Office 365 tenant. Most companies that use a third-party solution may leave their Exchange Online Protection settings in Office 365 as the default and think they are protected by their third-party solution. In this scenario, they are not. If you have hundreds of blocked IPs, email addresses and domains configured in your third-party solution and not in EOP, then attackers can still send emails via this method because your EOPremise solution is not likely to be configured with the same blocks you have in place with your third-party solution. Attackers may have Office 365 tenant subscriptions with connectors configured like the above to bypass your third-party filtering solutions.
How to fix this issue
Now that we walked through how third-party solutions can be bypassed let’s get these changes tested and fixed permanently in your tenant.
You will be creating a new connector and transport rule. Basically, this connector is going to be a partner connector that uses MX records for delivery and will have a transport rule scope defined. You will also need to gather your server IP address ranges from your third-party vendor and any on-premises external IPs that may still be sending email to Office 365. The result is that any email dropped off at Office 365 to your domain that is from the outside will be rerouted to the MX record for your domain. Thus, making the emails go via the correct MX path.
Open Exchange PowerShell and login to Office 365. The first command will create a new connector.
New-OutboundConnector -Name ‘Internet email to MX2222’ -ConnectorType ‘Partner’ -UseMxRecord:$true -IsTransportRuleScoped:$True
You can login to the admin portal, view the connector and see that it is now created. The connector will be ‘on’ but since it requires a transport rule to be in place it’s not in effect yet.
Let’s create the transport rule: please update your settings accordingly.
New-TransportRule -Name ‘Redirect to MX2222’ -FromScope NotInOrganization -RecipientDomainIs yourdomainname.com -sentto user@domain.com -ExceptIfSenderIpRanges 10.10.10.10/19,11.11.11.11/22 -SetAuditSeverity Low -RouteMessageOutboundConnector ‘Internet email to MX2222’
Once completed you can check the new rule in the admin portal.
This will apply the rule to the test account user@domain.com, only so that there isn’t any risk associated with the work you are doing. It is best to test in a test tenant if possible however if you must do in production please use the above method. Now make sure the connector has been validated and reconduct your mail flow test once the settings have replicated across Microsoft.
Finally, lets retest after the rule set is in place and check the headers.
The new test email submitted is going the correct path through your third-party filtering as shown in hops 5 and 6. This will now completely remove any risk of attackers dropping email off for your domain via Office 365 servers.
The final step will be to remove the “sentto” variable in the rule so it is applied domain wide pending your companies change control processes of course.
Once this is implemented you can see how much email has really been coming into your environment. In Exchange Admin Center under Mail Flow, Rules, find the Redirect to MXrule you created and click the reports button at the top.
And then select the correct rule in the window.
To view the details, you can select a date and the email details will show below in this graph. A lot of emails from Microsoft services go via this ruleset so don’t be alarmed to see Microsoft related alert emails in the report. Example below:
I hope this has a been a great learning experience for you and if you have any questions or would like to discuss please comment. Thanks!
