increasing MS Exchange protection
At first, IT specialists from Company N suspected banal phishing, because this letter was not in the outbox folder. We also joined the investigation, the results of which turned out to be completely unusual. As it turned out, the attackers gained access to the mail server and had been reading all the correspondence of the organization’s employees for some time, and were also able to send letters on their behalf. Let's figure out how this happened.
MS Exchange: popularity among companies and… hackers
If you look at the statistics, this case in itself does not seem so surprising. According to Positive Technologies researchalmost half of successful cyberattacks on businesses occur through social engineering. The main channel of its distribution is email – 85% of all cases. Let’s add here the data that at least 70% of companies with 2,000 or more employees use Microsoft Exchange, and our “cocktail” is ready.
The Microsoft Exchange service is located on the network perimeter of an organization and is designed both for sending messages within the company and for communicating with the outside world. At the same time, it has a large number of vulnerabilities, many of which have a score of 7 or more on the CVSS v3 scale. From an architectural point of view, everything is also quite tempting: Microsoft Exchange 2019 is integrated with Active Directory by default, which means that hacking it can give attackers administrator rights for this domain. The location and security issues make Microsoft Exchange an attractive and easy target for hackers.
One of the solutions is to try to cover all vulnerabilities with security measures and attach all kinds of scanners to the system. However, this is very expensive and will take a lot of time, and it will probably not be possible to plug all the holes. Therefore, I propose to consider another scenario: what if we try to find a way out not in the information security sector, but through a more competent Exchange setup? First, let's figure out what's wrong with a typical installation.
What does a typical installation look like and why is it bad?
Below you can see what the architectural diagram of a typical mail installation based on Microsoft Exchange Server 2019 looks like.
Most companies choose this installation method because they want to save time and resources for their IT departments. However, there is a downside to everything, and you have to pay with security.
With this installation method, there is no regular testing and installation of updates, and the mail system servers disclose the versions of its components. Traffic from the Internet passes directly to the mail system servers inside the organization's perimeter, using outdated encryption algorithms (DES, RC4), network access protocols (TLS 1.0 and SMB v1) and authentication protocols (NTLM v1). In addition, service accounts are usually given rights to connect via any protocol. In addition, the Exchange installation account remains in elevated Active Directory domain groups, and administrative accounts do not have strong authentication.
If we turn to the MITER ATT&CK matrixwe will see that attackers can use 14 tactics and more than 160 techniques against such an email system. Moreover, to use them you don’t need to be a hacking genius—the “Cyber Hooligan” or “Lone Enthusiast” level is enough.
Upgrading our mail
If the standard installation does not suit us, then it’s time to move on to tuning our mail system. All recommendations for strengthening protection can be divided into five groups:
Update and architecture
Account Security
Troubleshooting protocol issues
Setting up work with external clients
Using Windows Advanced Protection
Detailed descriptions of the recommendations are provided in the subsections below.
Update and architecture
Keep your software up to date
No matter how trivial it may sound, most often the source of problems is outdated software. Use only vendor-supported software and monitor the release of Cumulative Updates (CU) and Security Updates (SU). These updates not only fix bugs and add new features, but also close known vulnerabilities.
Hide Microsoft IIS server response headers
Once you've set up the update process, don't rush to tell everyone about it. The more attackers know about your system, the easier it is for them to find a way to hack it. Therefore, you need to hide the X-AspNet-Version, X-Powered-By, and Server response headers, which contain the version numbers of web applications and the Microsoft IIS (Internet Information Services) server.
To disable the display of the X-AspNet-Version header:
Launch Microsoft IIS Manager and open Server Settings (Configuration Editor).
Select the system.web/httpRuntime section.
Find the enableVersionHeader field and change True to False.
The X-Powered-By header can be replaced with any content instead of a version number:
Open Microsoft IIS Manager Settings.
Select HTTP Response Header.
Select X-Powered-By and replace the contents of the Value field with anything you want.
You can hide the Server header using the URL Rewrite module component. To do this, create an Outbound rule and fill the NAME, VARIABLE NAME and VALUE ANY fields with anything.
Use servers with the Edge Transport role
If you have not encountered Edge Transport servers aka edge transport servers before, you can read more about them in the Microsoft article. They are used to protect against spam and you will need them in two cases:
You don't use third-party anti-spam or anti-phishing tools and rely only on Exchange's built-in tools.
Your third-party anti-spam products require the installation of Edge Transport servers.
If none of the conditions apply to you, to “communicate” with the outside world, you just need to set up a mail transfer agent – Postfix.
Accounts
Disable OWA and ActiveSync for service accounts
In Exchange, service accounts are all accounts that do not belong to individuals – employees or contractors of the company. They are used to send and/or receive messages from monitoring systems or to run services with limited rights.
Often Outlook Web App (OWA) and Exchange ActiveSync services are left enabled for them. The first provides access to mail through a browser, and the second is responsible for synchronization between the work computer and the employee’s mobile device. Service accounts do not need these services, but attackers can use them to try to compromise the system.
To disable OWA and ActiveSync for an account, you can use Exchange admin center or console commands:
Set-CasMailbox -Identity <MailboxIdentity> -ActiveSyncEnabled $false
Set-CasMailbox -Identity <MailboxIdentity> -OWAEnabled $false
Instead of MailboxIdentity you need to specify an account name.
Set up administrative account restrictions
Make sure your Microsoft Exchange administrative account is not a member of the following groups:
Domain Administrator.
Enterprise Administrator.
Schema Administrator.
There are only two exceptions to this rule: temporarily You can include an administrative account in these groups during the initial installation of Microsoft Exchange and during migration to a new version.
Implement strong authentication for employees with administrative rights
Employee accounts with administrative rights must use strong authentication – based on cryptography and smart cards. A smart card is a special device that stores a private key for logging into an account.
To implement it:
Set up your internal public key infrastructure (PKI). You can do this using Microsoft documentation.
Create separate accounts for Exchange administration.
Issue authentication certificates for these accounts that will match following requirements.
Allow employees with administrative rights to authenticate using smart cards only.
Configure certificate authentication for access to Exchange Admin Center according to Microsoft instructions.
In addition, do not forget about password policies to set complexity requirements and the frequency of password changes.
Protocols
Check the SSL and TLS protocol configuration
Outdated network access encryption protocols also have no place in your email system. Make sure your organization's SSL and TLS settings are appropriate Microsoft requirements.
Use strong encryption algorithms:
RSA-2048 — to create new certificate keys.
SHA-256 or more secure — when updating or creating new certificate signing requests.
If you need to create a self-signed (also called self-signed) SSL certificate, refer to on Microsoft recommendations.
Disable SMB v1
Another legacy protocol found on mail servers is SMB v1. Microsoft has been urging administrators to disable it for several years due to security concerns. In particular, it is used in the EternalBlue and EternalRomanc exploits.
You can check its status using the following PowerShell commands:
Get-WindowsFeature FS-SMB1).Installed
Get-SmbServerConfiguration \| Select EnableSMB1Protocol
If the result shows True, then your system is using SMB v1. Make sure your database availability group (DAG) servers support SMB v2 or later. For this checkwhether the DAGs are configured correctly.
Now you can proceed to disabling SMB v1. This can be done using group policies according to Microsoft instructions or teams:
Disable-WindowsOptionalFeature -Online -FeatureName smb1protocol
Set-SmbServerConfiguration -EnableSMB1Protocol $false
Clients
Configure Kerberos service and restrictions for email clients
Use the Kerberos protocol to authenticate Outlook and OWA clients on your local network. The necessary parameters can be found again in Microsoft instructions.
For Outlook email clients, it is necessary to introduce a number of other restrictions:
Block MAPI over HTTP access at the external perimeter. The default port is 443 (TCP). Email clients should only connect from a local wired network or via a VPN.
Prevent mobile clients from connecting via ActiveSync without a VPN or use certificate-based authentication.
Make Outlook on the web accessible only through VPN and deny access via the Internet. If you need to place it on the external perimeter and allow access, publish OWA through a Web Application Proxy and use multi-factor authentication. If you notice several unsuccessful login attempts, it is likely that someone is trying to hack you. In this case, you need to temporarily block the attacker's IP address.
Disable protocols on servers IMAP4 and POP3. By default they should be disabled anyway, but it’s still better check and if necessary take action. If you really need to use them, block Internet access using these protocols and only allow connections from your local wired network or VPN.
Enable advanced Windows protection
Windows Advanced Protection includes additional security measures to prevent authentication relay and man-in-the-middle (MITM) attacks. It is available in Microsoft Exchange Server 2013, 2016, and 2019, and if you have installed the Exchange Server August 2022 Security Update (SU) or a higher version of SU.
However, Windows Advanced Protection has a number of limitations. For example, it won't work:
If Microsoft Exchange 2013 has public folders in a coexistence environment.
If Microsoft Exchange Server 2016 CU22, Microsoft Exchange Server 2019 CU11, or a version below hosts a public folder hierarchy.
The server uses the Hybrid Modern Authentication user identity management method.
In addition, it is worth considering that before enabling extended protection, the TLS certificate configuration must be consistent across all MS Exchange servers, and clients must not use the NTLM v1 protocol.
Let's sum it up
A standard MS Exchange setup greatly simplifies the task for an attacker. This configuration enables only 2 of the more than 40 protection measures. If we try to calculate the time for an attack based on MITER ATT&CK data, then it will take a hacker about 6.5 hours to hack such a system. And here’s what its path through the system might look like.
Now let's take a look at how the situation has changed after “tuning” our mail.
The hacker's path became longer, we managed to slow down every step he took in the system, and the attack time increased to 64.5 hours. Moreover, we were able to achieve such progress without spending on new information security tools, and the implementation of most measures took only a couple of hours.
Following these simple steps will give the response team nearly 10 times more time to detect and neutralize the threat. We will be glad if you also decide to use these recommendations and share your results!
What about our heroes, you ask? Those who turned to us for help?
IT specialists from Company N “kicked out” the attackers from the mail server, “tuned” the mail system and prepared communications for counterparties about the incident (including the measures taken).
Pavel Maslov
Architect, Directorate of Infrastructure Projects Positive Technologies
