Email spoofing is a form of cyber-attack commonly used in phishing attacks and scams. Its purpose is to trick users into thinking a message came from a person or entity they trust. The manipulated email is sent by a hacker and may contain malicious links or false information.
This technical blog is written by Dubex’ Technical Services team and showcase our finds in the matter: A misconfiguration in Mail Exchange allowing hackers to do CEO-fraud and perform extortion schemes.
A technical blog by Dubex Technical Services.
Kudos to Kevin.
We have tested many organisations for this weakness, and we can’t emphasise this enough: There are too many organisations vulnerable to this, based on our current test results.
This blog describes the issue, what is causing it and comes up with potential solutions based on the knowledge we have obtained so far.
We strongly encourage you to test your organisations vulnerability to this weakness, whether you fall within the mentioned scenarios in this blog post or not. Please note, that the scenarios presented only show the expected results. Unexpected results can still occur due to poorly configured email flows.
Technical details
We have come across a configuration allowing a threat actor to craft and send spoofed mails into an organisation, even with mechanisms such as SPF and DMARC in place.
We’ve managed to get an email through in close to 90% of the tests. Among those emails, close to 85% of them were delivered directly to the inbox, 10% as NDR and the last 5% somehow managed to end in junk.
Let’s dig into how we discovered this weakness.
A normal (oversimplified) email flow, having an external email gateway in front of Exchange Online, looks like this:
Here, a user crafts an email going to a recipient e.g., bob@acme.com. The email is sent through the user’s Mail Transport Agent (MTA), which looks up the Mail Exchange (MX) with DNS for the domain acme.com.
MTA delivers the email to the recipient’s email filtering solution, which scans and sends it to Exchange Online. Exchange Online then delivers it to the user inbox (can be on-prem or cloud).
The misconfiguration
What we discovered is that a threat actor can ignore the MX record and take their email directly to Exchange Online Protection (EOP).
EOP will likely not scan emails due to the expectation that this would have been done by the email filtering solution.
Sysadmins and support staff will not, and should not, manage spam filters multiple places, but it is possible to configure this architecture correctly. More on that later.
An (oversimplified) email flow for abusing the misconfiguration will therefore look like this
Knowing the onmicrosoft.com domain of the tenant <name>.onmicrosoft.com makes us able to guess the domain for Exchange Online Protection being <name>.mail.protection.outlook.com.
External email Gateway bypass
Let us try the old-school telnet style: Delivering an email to and from the same user with the target (recipient) organisation to see what happens. We continue with the same example of bob@acme.com for familiarity.
https://aadinternals.com/aadinternals/#get-aadinttenantdomains
Microsoft accepted our email even though the MX pointed to an external email gateway, which is where we are expecting our email to come from!
We have added an email alias bob@azure.dubextestenvironment.com for visibility. (We use a test tenant here and had to hide a few details). We tweaked the telnet a bit, enabling us to demonstrate all the dangers within this misconfiguration.
The result:
We have done a ton of testing to understand all the outcomes and configurations. And in short, this is the essence of the problem.
Organisations with external email gateways not using EOP tend to be the most common architecture exploitable.
The Solution to External Email Gateway Bypass
There are several protectional actions you can take to this.
Firstly, familiarise yourself with Microsoft’s documentation regarding different email scenarios and best practices.
Secondly, in case you have an external email filtering solution, you should implement step 4 of Microsoft’s documentation for external email filtering[3].
We strongly advise you to fully understand your email flow before blindly implementing this; it might cause an incident putting your email flow to a stop due when being rejected by EOP.
Proceeding from this, we can create a receive connector locking it down to only accept this external email filter. We also set up enhanced email filtering (as the documentation advises), and now get the following message when trying to deliver the email:
DMARC Reject with EOP
Let’s take a closer look at DMARC reject with EOP to understand the scenario.
First, let us configure the tenant to prevent the original spoofing attack and make that unsuccessful. This is done by having an anti-phishing policy where spoof intelligence is enabled.
So, what is the issue here?
From evaluating a ton of different configurations, we noticed that some email setups with EOP or Defender for Office 365 were identified and quarantined as expected: nothing reached the user.
In other cases, users received a NDR (Non-Delivery Report) regarding Microsoft being unable to deliver the email they sent hint: they didn’t, somebody spoofed and claimed to be them! and Microsoft sent a NDR to the “sending” user from the users’ domain! These emails were the cause of organisations having DMARC record with the policy of reject, hence Microsoft sends a reject NDR to the sending user.
In most cases, even with an inbound anti-spam policy protecting against NDR Backscatter enabled[4], emails somehow still managed to find its way to the user’s inbox, and sometimes ended in junk. When we sent multiple spoofed emails, they sometimes also caused the first to land in junk and the second in the inbox. Our guess is that there are malfunctioning machine-learning models making these decisions.
Thus enlightened, let’s try to move our email flow to EOP by moving the MX record to EOP. We make sure to enable spoof intelligence and create a DMARC record with the policy of reject.
This should be a good configuration, right?
Not really. The text in the email is of course not directly visible. But notice the X-Not-Suss-Header and the link we sent with the mail. As we stated earlier, the user Bob had a safe links policy rewriting the links. It turns out that Outlook makes the link clickable and Defender for Office 365 (MDO) does not apply the safe links policy to this email, hence bypassing safe links!
Worse is, if an organisation is running Centralized Mail Transport (CMT) where emails are routed through on-premises Exchange server (hybrid configuration), we have seen cases where the NDR gets the original email attached. This makes the email clickable and shows the original email, again without safe links applied.
Additionally, if the user already experiences NDR from time to time, they are more likely to open the email tab and select Send Again, which will present the email to them like an original as well.
What is the solution to this, you might wonder?
Our hope was that having an inbound anti-spam policy with NDR Backscatter protection enabled fixed this. But the testing up until this point, has shown that emails still get through. So, that leaves you with the solution of either changing your domains DMARC policy to quarantine (and risk not getting the information if somebody spoofs your domain) or doing an override in EOP, so when policy is rejected, you are quarantined instead. This, however, is not a great solution either, as you are not respecting other domains DMARC policy.
Therefore, we do not see any good mitigation for this to exist at this moment in time.
Other (human) scenarios to consider
We have seen a couple of other variants of the same misconfiguration outlined below. This is to inform you that you should expect more of these configurations to flourish out in the wild as we speak.
- We troubleshooted why emails still went through with Exchange Online Protection Spoof Intelligence enabled for a client.
After getting access to the client’s Security Portal, we identified with Threat Explorer that an email flow rule was allowing it. The rule set the Spam Confidence Level (SCL) to -1[5] for all emails having sender domain of the client with the result of having the email skipped from the spam filter. The rule likely spawned from a sysadmin struggling with SPF from an external system sending emails to the users as the user or their domain. Instead of fixing the issue, this became the “solution”. If an actor spoofs the sender as the client domain, like done in CEO-fraud and extortion schemes, they will succeed. - In another client case, we had an external email gateway in front of their on-premises Exchange with CMT, and very few mailboxes in Exchange Online. When assessing them by delivering to EOP, it succeeded. We went a step further as we could see the on-premises Exchange server in the email headers, and directly connected to the exchange a port 25 (SMTP), which was exposed. Again, we succeeded bypassing the external email filtering solution. If the Exchange server had been locked down to only accept incoming connections from the external email gateway, this wouldn’t have been an issue.
Could you be vulnerable to these human mistakes within your organisation? Always TEST to find out.
Municipalities and public institutions in the spotlight
We have had many municipalities and public institutions as clients over the years. We know that all 98 Danish municipalities have a Microsoft Entra ID tenant, and likely most, if not all, have secure mail solutions in place to be compliant with current legislation.
These solutions require having the MX record pointing to them, as they expect to receive encrypted data/mails, and then unwrapping them before delivering to the organisations email gateway. This makes the municipalities of Denmark (and in general, public institutions) more commonly vulnerable to this attack.
We thus created a small script to enumerate email domains for the 98 Danish municipalities. And 65 of them are having an MX record that does not point to EOP! (We tested in December 2023.)
If we enumerate further, the Second-Level Domain (SDL) were the most “single used” source EOP. Based on the number of records, a single municipality apparently has two records pointing to Microsoft.
Knowing some of these email gateway providers does not include best practice from Microsoft regarding locking down the connector, we can only imagine how many are vulnerable.
Let us have a look at those using EOP. Pivoting on the data, 19 municipalities using EOP have DMARC Policy set to reject, and therefore likely impacted by this!
| Mail Exchange (SDL) | Municipalities | Records |
|---|---|---|
|
outlook.com (EOP) |
33 |
34 |
|
centerasecurity.dk |
20 |
57 |
|
heimdalsecurity.com |
11 |
22 |
|
< using own domain > |
8 |
11 |
|
hostedsepo.dk |
8 |
8 |
|
electric.net |
7 |
14 |
|
iphmx.com |
5 |
10 |
|
mailanyone.net |
5 |
8 |
|
mx25.net |
4 |
6 |
|
messagelabs.com |
2 |
4 |
|
scanscope.net |
1 |
4 |
|
comendosystems.com |
1 |
1 |
|
comendosystems.net |
1 |
1 |
|
trendmicro.eu |
1 |
1 |
Finally, let’s look at municipalities using EOP. Pivoting on the data, 19 municipalities using EOP have DMARC Policy set to reject, and are therefore (also) likely impacted by this!
Conclusion
As proven so many times, email was designed without security, and we have shown yet another flaw in email or its implementation. Solutions such as SPF and DMARC are add-ons designed as an attempt to make the existing more secure.
In this blog post we have showed that:
- Threat actors are currently abusing this misconfiguration, allowing them to send spoofed mails and successfully getting them delivered. Currently seen used to do CEO-fraud and perform extortion schemes.
- Organisations with external email gateways not using Exchange Online Protection (EOP), tend to be the most common architecture exploitable.
- An implemented DMARC with the policy of reject and using EOP, tends to allow a kind of successful attack, bypassing safe links, without any great mitigation if you are using EOP.
- Having implemented DMARC with the policy of reject and using EOP, tends to allow a kind of successful attack, bypassing safe links, without any great mitigation if you are using Exchange Online Protection.
We strongly encourage you to test if you are vulnerable to this even if you fall within the abovementioned scenarios or not. The scenarios showed in this article is just the expected results. Unexpected results can still occur due to poorly configured email flows.
A discussion of whether Microsoft implementation is good, does not fall within scope of this article. We have had the opportunity to test many organisations for this weakness, however, and can’t emphasise this enough: There are too many vulnerable to this, based on our current test results. Test your mail set up!
We have been in touch with KL to inform every Danish municipality on the issue.
The use of security.txt[6], which enables security researchers to contact and inform about findings without having to spend a ton of hours hunting down the right staff, could be a great asset here. Kudos to Municipality of Copenhagen for being the first and only one at the time of writing having this deployed of all municipalities.
Sources and links
- [1] https://aadinternals.com/aadinternals/#get-aadinttenantdomains
- [2] https://mha.azurewebsites.net/
- [3] https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/
- [4] https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/anti-spam-backscatter-about?view=o365-worldwide
- [5] https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/anti-spam-spam-confidence-level-scl-about?view=o365-worldwide
- [6] https://securitytxt.org/
