Sending email anonymously through Exchange Servers

The purpose of this article is to raise awareness of the possibility of sending mail anonymously through Microsoft Exchange Servers and to show mitigations for the resulting risks. After setting up Exchange Server 2019, you might be unaware that it's possible to send mail anonymously to internal recipients by default. This means that, using PowerShell, for example, anyone in your LAN may send messages to internal accounts without revealing their identity.

Contents

Sending emails anonymously using PowerShell
Restrict IP addresses for Exchange
Disable port 25 on Exchange
Block port 25 using Kerberos authentication
Conclusion

Author
Recent Posts

Welf Alberts

Welf has been working as a system administrator since the year 2000. He focuses on IT security for the Windows platform.

Sending emails anonymously using PowerShell

Let's try this out in Example A:

Send-MailMessage -smtpserver yourexchangeservername -from santa@south.pole -to somerecipient@yourdom -subject "Sorry, no Xmas this year" -attachments c:\temp\some.txt

Sending an email anonymously

If you are unsure whether your environment allows anonymous sending even to external addresses, you can test that as follows: substitute somerecipient@yourdom with your own private mail address. This should not work unless you have intentionally set it up that way. If it works, you have an even bigger problem: the attached data could leave the company network that way, completely unauthenticated and triggered by a malicious background process.

Since this may not apply to you, let us first look at sending internally within your domain and ask: Is this dangerous?

Since it works like this by default, you might think it should not be a problem. If someone really wants to fool around with that, you can quickly investigate the IP that anonymous mail comes from by looking at the email headers, which list the source IP address. This should enable you to find out who sent it:

Identifying the source of an anonymous email

So is it dangerous, or isn't it?

Well, it depends. If your endpoints are secured and isolated and are not allowed to exchange data between them, this could mean that the Exchange Server opens up a side alley through which an attacker could move files from System A to System B.

To put this into perspective, let me compare it to how Outlook works. With the above commands, an unauthenticated SMTP (port 25) was used. Configured Outlook clients don't use port 25, since they must always be authenticated.

Nevertheless, some script placed in your auto-start by a malicious actor could abuse Outlook without your knowledge. That script won't need to hold credentials since it is executed by you, and Outlook uses single sign-on. Thus, even without allowing Exchange to deliver mail from unauthenticated users, there are ways for attackers to make your machine send mail in the background, even to external recipients! How does that work?

$mail = (New-Object -com Outlook.Application).CreateItem(0)
$mail.subject = "Sent by script"
$mail.body = "Test"
$mail.To = "welf.alberts@some.dom"
$mail.Send()

Change the recipient's address and try that out as well. If you are lucky, your admin has restricted this, and a warning message will appear in Outlook telling you that some program is trying to use Outlook and asking for your consent:

A program is trying to send an email message on your behalf

If no warning pops up, consider deploying this protection (the ObjectModelGuard registry key).

Okay, I hope this example raised your awareness. Now let's see if that protection, after you have ensured it's set up, works against the aforementioned Example A, too…

It might come as a surprise that it does not, but that is only logical, since that registry key protects only Outlook and does not work outside of it.

On the PowerShell console, an attacker is able to send automated, unauthenticated mail with no protection possible. What can you do about it?

Restrict IP addresses for Exchange

You can restrict the IP addresses from which your Exchange Server may accept unauthenticated mail, which is described in parts of the Exchange documentation.

Disable port 25 on Exchange

You could disallow traffic on port 25 for anyone and at the same time allow certain accounts to use the Exchange pickup directory functionality to send mail, which ensures that only authenticated sending takes place. This will work as long as the processes that create these mails can be configured to create a message file on a network share with restricted share permissions; not every process will be that flexible. This is documented here.

Block port 25 using Kerberos authentication

In a concept similar to the first solution but more sophisticated, you will use the Windows Firewall on the Exchange Server to block port 25 for certain accounts (users and/or computers), to the effect that certain accounts may send while others may not, even on the same machine.

This comes in handy if, for example, you would like to send automated log messages from your terminal server as an admin or system account, but at the same time prevent users from sending anonymously from that server. This can be achieved by using secure Windows Firewall rules with Kerberos authentication. Since this is my preferred option, I will share details about how to do this.

Secure Windows Firewall rules are described here as part of a how-to about securing RDP with IPSec.

In that guide, the procedure is performed on privileged access workstations and domain controllers. You can do much the same on your Exchange Server and clients; the difference is that it's not for the domain controllers' IP addresses but for the Exchange Server, and, of course, not for the RDP port but for SMTP on TCP port 25.

That way, you will be able to limit authenticated sending to certain computers and users at the same time. You could, for example, limit it to the security group domain computers in the authorized users section and limit it to a group that only contains servers in the authorized computers section. This means that only processes with system privileges may send mail without being authenticated via port 25, and only from these few servers. This is a lot better compared to the IP-based receive connector settings.

For network components that are unable to use Kerberos authentication but should still be able to send unauthenticated mail for logging or alerting purposes, be aware that you may, of course, set up different rules, one secure rule (Kerberos authentication-based) and one standard rule (IP-based), using the latter to "whitelist" these devices by IP.

Finally, after setting this up, you will also need to change the default rules that the Exchange Server setup has implemented. Locate these three rules in the firewall GUI of your Exchange Server.

Locating firewalls on the Exchange Server

You will need to duplicate these rules 1:1 manually, with the exception that you will need to remove port 25 as the allowed port and then disable the original rules. To make it visually easier, I used the same rule names with a "!" prefix; see the following screenshot for an example:

Modifying Windows Firewall rules

After you create the modified duplicates, you may disable the original three rules. From now on, only authenticated SMTP sending is possible (other than any exceptions that you might have configured).

Conclusion

I hope you will agree that anonymous sending is a big problem that must be addressed.

Subscribe to 4sysops newsletter!

Using secured firewall rules to defend against this is the best option, in my opinion. Microsoft's way (option 1) is surely the easiest way, but it is less flexible when it comes to allowing accounts to send mail, so it pays to go the extra mile and use secured firewall rules.

Want to write for 4sysops? We are looking for new authors.

4sysops members can earn and read without ads!