Microsoft Exchange misconfiguration opens the door to spoofing attacks

By Alexander Romanov, Infrastructure Security Team Lead at Acronis

In 2023, Microsoft announced a change to how it handles DMARC in Microsoft Exchange. Despite the warning, many users have not followed Microsoft’s recommendations to set up enhanced filtering, or perhaps are not aware of the change. As a result, users who have not properly configured Microsoft Exchange are now exposed to email spoofing, which could lead to email compromise, data breaches and more.

Approximately 36% of all data breaches in the EU and U.S. originate from phishing attacks. Phishing emails often appear to come from legitimate sources, such as "admin@microsoft.com" or "IT administrator email@google.com," and feature subject lines and content designed to capture users' attention — such as information about salaries, payroll, etc.

In some cases, attackers can spoof email addresses to make it seem as though the email is from a trusted source, such as "your_boss@yourcompany.com." Because the email client recognizes the sender's address as matching your manager’s, it may automatically display the associated contact photo, further enhancing the illusion of legitimacy. This makes it much easier to deceive users into taking harmful actions, such as entering their credentials, launching malicious applications, or transferring money to an unknown account.

What protocols are in place to protect us from phishing?

Simple Mail Transfer Protocol (SMTP) is a protocol used to send email messages. It was first created in 1982, without any consideration for email security. Initially, it was expected that security would be handled by other means. Today, SMTP traffic between email servers can be encrypted and authenticated using the TLS protocol. However, the original SMTP did not include any way to authenticate email.

As email remains a key target for cybersecurity threats like spam, phishing and email spoofing, three main protocols have been developed to enhance email security:

1.      Sender Policy Framework (SPF): This protocol checks if a mail server is authorized to send email for a particular domain by using DNS.

2.      DomainKeys Identified Mail (DKIM): This protocol allows emails to be digitally signed, proving that they come from an authorized mail server. DKIM signatures help email providers verify the authenticity of the sender's domain.

3.      Domain-based Message Authentication, Reporting, and Conformance (DMARC): This protocol determines how to handle emails that fail SPF or DKIM checks. It helps decide the appropriate action when an email fails to authenticate.

1.      Server A makes a DNS request to find the MX (Mail Exchange) server of ourcompany.com.

2.      Server A sends an email from user@company.com to user2@ourcompany.com through one of the MX servers (Server B).

3.      Server B verifies the email by:

• Checking if the email is from an authorized server (SPF verification).

• Ensuring the email has a valid DKIM signature.

• Following the actions specified by the DMARC policy.

For example, if Server A is not listed in the SPF records, and the email either lacks a DKIM signature or has an invalid one, and if the domain company.com has a DMARC policy set to "Reject," then Server B should reject the email.

If we have:

We expect that all emails arriving from sources not listed in our MX records would be rejected.

But what if the receiving server is configured to ignore these policies? What if it is not your (Admin of MX) decision? Or what if you have one more mail exchange server, but are not aware of it and how it works?

Let's delve further into this.

You can configure and use Exchange Online as a mail server. In this case, you do not need on-premises Exchange servers or third-party anti-spam.

If you use Exchange Online without on-premises servers or a third-party MX, then this scenario does not apply to you. This scenario covers two cases:

• Hybrid environment: If you have on-premises Exchange and your online and on-premises Exchange communicate via connectors.

• Use of a third-party MX server: If you are using a third-party spam or other email security solution.

If your MX is pointed to the third-party MX, you should refer to this article from Microsoft to configure your EXO instance.

It means, for example, instead of:

A full article about what it is and how it should be configured can be found here. If you don’t have your own MX and all traffic goes through *.protection.outlook.com, then there is no threat of configuration abuse.

But what if you use your own MX? By default, the Hybrid Setup wizard will create some standard inbound and outbound connectors for data exchange between Exchange Online and on-prem Exchange.

We couldn't find any references to the article about third-party MX in the Hybrid exchange documentation. We found one mention about third-party MX in the Transport Routing documentation:

If you decide to keep your MX record pointed to your on-premises organization: All messages sent to any recipient in either organization will be routed through your on-premises organization first. A message addressed to a recipient located in Exchange Online will be routed first through your on-premises organization and then delivered to the recipient in Exchange Online. This route can be helpful for organizations where you have compliance policies that require messages sent to and from an organization be examined by a journaling solution. If you pick this option, Exchange Online Protection will not be able to effectively scan for spam messages.

The most important point to note is that if the tenant recipient domain's MX record points to a different email security solution that sits in front of Office 365, then Honor DMARC will not be applied.

Because you use MXs other than Microsoft's, all emails will be verified by this third-party MX. It should be okay, right?

No. If you didn't lock down your Exchange Online organization to accept mail only from your third-party service, or if you didn't enable enhanced filtering for connectors, anyone could send an email to you through ourcompany.protection.outlook.com or ourcompany.mail.protection.outlook.com, and DMARC (SPF and DKIM) verification will be skipped.

To get the full picture of how this works, we need to look at configurations of inbound connectors.

Important parts of this configuration: Which servers will this connector be used for? For any IP and any domain.

What should be done with connections that do not fall under the scope? Nothing.

It means that if you have only this type of connector, connections to ourcompany.protection.outlook.com or ourcompany.mail.protection.outlook.com are not restricted by your on-prem Exchange.

And if we look at the notes in this article about third-party MX, we will find an important point:

If you already have an OnPremises inbound connector for the same certificate or sender IP addresses, you still need to create the Partner inbound connector (the RestrictDomainsToCertificate and RestrictDomainsToIPAddresses parameters are only applied to Partner connectors). The two connectors can coexist without problems.

It means, by default, our configuration is not secure.

If you want to configure inbound connectors for third-party MX, you could use PowerShell or GUI. And you can use two types of authentication: by "sender domain" or by "IP."

If you have a Partner connector with SenderIPAddresses : {}, for example, a Partner connector with authentication by "sender domain”, all connections (except IPs from the connectors where this specific address is set) will go through this connector.

If you create a Partner connector with authentication by IP and with RestrictDomainsToIPAddresses, all connections "without" connectors will be blocked.

If you try to create a connector via the GUI, you cannot set RestrictDomainsToIPAddresses for cases where IP is used for authentication because there is no such option as "Reject email messages if they aren't sent from within this IP address range." This can only be done via PowerShell. Or you should use verify by sender domain.

And set: Reject email messages if they aren't sent from within this IP address range:

If you have third-party MX, you should configure at least one additional inbound connector following the Microsoft's recommendations.

In the case of hybrid, you should create a Partner connector with the same IP / certificate used in the OnPremises connector, like:

• Enhanced Filtering for Connectors in Exchange Online.

• DLP
  

• Transport rules, for example, to drop all emails that did not come from your MX servers.

You can use the below code to check for yourself.

Important:

TO is a real-life address. The email address must exist on the Exchange online side if you do not use a hybrid scheme.

Server you can get from the result of the requests:

• dig yourdomain.onmicrosoft.com mx

• dig yourdomain.mail.onmicrosoft.com mx

PowerShell code example:

$from="user1@yourdomain.com"

$to = "user2@yourdomain.com"

$server = "yourdomain.mail.protection.outlook.com"  

$SMTPMessage = New-Object System.Net.Mail.MailMessage($from,$to)

$SMTPMessage.Subject = "Misconfiguration in the M365 tenant"

$SMTPMessage.Body = "From user@yourdomain.com"

$SMTPClient = New-Object Net.Mail.SmtpClient($server, 25)

try {    

$SMTPClient.Send($SMTPMessage)    

Write-Host (Get-Date).ToUniversalTime()    

Write-Output "Email sent successfully to $to. From $from"

} catch [System.Net.Mail.SmtpException] {    

Write-Host (Get-Date).ToUniversalTime()    

Write-Output "SMTP Exception: $_"

} catch [System.Exception] {    

Write-Host (Get-Date).ToUniversalTime()    

Write-Output "General Exception: $_" }