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 MX rule 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!
Tony, could you please clarify something? For your “recipient domain is…” rule, are we using only “companyname.com”? Is it necessary to input the MS internal redirects such as “companyname.onmicrosoft.com”, “companyname.mail.onmicrosoft.com”, “companyname.mail.protection.outlook.com”, “companyname-mail-onmicrosoft-com.mail.protection.outlook.com”, etc?
BTW thank you for the article. This is some incredibly valuable information. I cannot thank you enough for taking the time to write this.
Tony, how come I cannot follow you on linkedin? You deserve a following there lol
Oh, I’m sure you can find me on LinkedIn. It’s not like I hide there.
How does applying this ruleset work with all the “internal” notifications that come from your tenant services such as Teams missed chats, Yammer notifications, O365 alerts and message recall reports? In our tenant they all come from the Microsoft environment internally and do not use MX records.
How would we do this for domain.onmicrosoft.com addresses though to redirect to proofpoint? I noticed teams meetings from external are going to that instead of domain.com
Hi Joshua,
Did you manage to get it working via Proofpoint?
We are having a similar issue where all emails send to onmicrosoft.com is not passing through to Proofpoint.
Cheers
JP
This has been absolutely invaluable info for us – thanks for posting. We took this a step further and have the transport rule insert a header of x-redirected: True, and then set up our edge mail filter to quarantine mail that has that header. This has improved our security posture and reduced the number of Phishing emails that are delivered. Good work!
Hi Tony.
A great article and exactly what I have been looking for.
In your example, you have Proofpoint as the external mail filtering service – Snap.
However, we continued to replicate the IP filtering within our Exchange 365 as a backup in the event PP ever missed any. But the IP rules now dont apply as Exchange Message trace always identifies the Proofpoint IPs as the Sender IPs.
Have logged it with both PP and Microsoft, but am getting nowhere fast. Microsoft have basically told me, this is how it is with an external email filtering service. Just wondering if that was your understanding as well?
Many thanks
So how do you handle group expansion for onmicrosoft addresses?
Microsoft now have an article on this;
https://docs.microsoft.com/en-gb/exchange/mail-flow-best-practices/manage-mail-flow-using-third-party-cloud
what happened when replying back to the email that has bypass the EOP Spam Filter?
the outgoing email will also bypass the outbound EOP Spam Filter?
Hi,
The rule isn’t working for me. I feel like the 1st condition if messages is sent to username@domain.org is the problem, the incoming message will come from customdomain.mail.onmicrosoft.com?
if the message…
Is sent to ‘username@domain.org’
and recipients’s address domain portion belongs to any of these domains: ‘customdomain.mail.onmicrosoft.com’
and Is received from ‘Outside the organization’
Hi Tony,
Just came across this and what a great article and discovery, thanks for sharinng. I’m thinking of incorporating an automated detection mechanism for this into my website.
On a side note, I recently published an article which focuses on how abuse of the Exchange Postmaster can lead to Information Disclosure of sensitive spam/malware filtering information (particularly affecting Exchange On-prem/Hybrid deployments).
Keen to get your take – https://www.linkedin.com/pulse/abusing-exchange-postmaster-bypass-email-spam-malware-sebastian-salla/
I’m currently researching additional bypass mechanisms.
Could you just create a rule that blocks email messages sent from “Outside the Organization” unless they are from the company’s IP doing the filtering? Would that work? Any emails coming in that are NOT from the filtering company would most likely be malicious anyway right?
No. Other Office 365 tenants along with emails from Microsoft and Azure would also get caught by this rule, and you don’t want those discarded. This will redirect those along with any direct emails to your external filtering service.
A rule to block external senders will work. In my experience, email from Microsoft and other O365 tenants. The only exception to this is voicemails from Teams – these messages are not routed via an MX lookup yet Microsoft view them as external. Therefore as a workaround, I recommend setting up a block rule then adding a seperate rule to allow Teams voicemails:
1. Navigate to Exchange admin center > mail flow > rules
2. Click on “Create a new rule”
3. Create a new rule that:
Name: Teams Bypass
Apply this rule if: “The message type is”> include the message type > “Voice Mail”
and
Sender’s IP address is in the range “52.120.0.0/14 or 52.112.0.0/14 or 13.107.64.0/18”
These IP’s are sourced from Microsoft’s documentation of their current Teams IP addresses – see https://docs.microsoft.com/en-us/office365/enterprise/urls-and-ip-address-ranges
Do the following…
“Require TLS Encryption”
Chose a mode for this rule: Enforce
Check “Stop processing more rule”
4. Click Save
Hi, thanks for the solution provided here.
I can see that emails originated from O365 like postmaster@onmicrosoft.com OR Office365Reports@microsoft.com are also redirected to third party filtering service.
These emails should be delivered directly to mailbox. How do we exempt all microsoft related IPs/domains?
Did you come up with a solution to your in-house email addresses not being filtered? We are about to implement this and I am worried about this as well.
Thanks
Hi, these would be using the Exempt IF command in the rule which is above “ExceptIfSenderIpRanges 10.10.10.10/19,11.11.11.11/22”.
Tony,
You have the range 10.10.10.10/19 and 11.11.11.11/22 in your blog and the comment above; but the screenshots show 10.10.0.0/19 and 11.11.8.0/22. can you please confirm which of these two sets of values should be used? Or if it even matters?
Respectfully,
You need to set the values to your own IP address ranges (that is, the ranges of your 3rd party mail service, on premise email servers, or any email server/service that you will be receiving email at sent at your domain)
Tony,
What about the situation where the sender happens to be using the same email gateway provider form outbound (i.e., coming from the same pool of IPs)? Wont the rule as written then pass those emails straight on into the email provider without passing them to the gateway…. ?
Perhaps a new header record can help to determine if the email has just arrived or is coming back in.
We recently discovered this issue and handled it via a mail rule:
Apply this rule if:
The sender is located … ‘Outside the Organization’
Except if:
Message header includes ‘x-ms-exchange-organization-authas’ header includes ‘internal’
or
Sender’s IP Address is in the range (our on prem server IPs)
Any advantage of doing it via the connector vs the mail rule?
Great article and very important informations for us. We have created the same transport rule since missed call and voicemail notifications were also affected on our side.
If the message…
Is received from ‘Outside the organization’
Except if…
sender ip addresses belong to one of these ranges: xxx
or ‘X-MS-Exchange-Organization-AuthAs’ header contains ”Internal”
Now we have recognized that the transport rule also applies to inbox forwarding rules and see how we can fix it. X-MS-Exchange-Generated-Message-Source –> Mailbox Rules Agent
thanks so much for this, very helpful
You can achieve the same with a partner connector that reinforces any incoming email to be received by the 3rd party or on-premise, depending where MX records point to.
Like that the Transport rule is not needed.
I also don’t see the point of the transport rule to redirect those emails to MX. Why would you redirect email sent by Spammers to you MX record? Why not simply block it?
The partner connector is further described in example 4 in the following article:
https://docs.microsoft.com/en-gb/exchange/mail-flow-best-practices/use-connectors-to-configure-mail-flow/set-up-connectors-for-secure-mail-flow-with-a-partner
Using the connector scenario doesn’t work for us. I still get mails going around ProofPoint, even though I have both inbound and outbound connectors configured. I’m still trying to wrap my head around Tony’s method but I’m pretty sure I’m going to implement it.
One problem I forsee though is that if laptop users are off network and off VPN, I will not know their IP addresses and so the IP exception won’t work.
Thanks for your valuable info. hope to join sessions related to Off365 if you have time to learn it well.
Thanks Tony, very good information and learning 🙂
I like the explanation of our attackers by-pass 365. The instructions followed causes all emails to the domain and/or user to get an NDR. This is with or without the “sendto”.
Scot, thanks for your feedback! I’d be happy to work with you next week on this in detail if you like? You can reach me at tony.akers@outlook.com and we can schedule a meeting.