Microsoft Exchange on-premises hardening recommendations

Microsoft Exchange on-premises hardening recommendations

/in

Few cybersecurity experts would dispute that attacks on Microsoft Exchange servers should be viewed as inevitable, and the risk of compromise remains consistently high. In October, Microsoft ended support for Exchange Server 2019, making Exchange Server Subscription Edition (Exchange SE) the only supported on-premises solution for 2026. Despite this, many organizations continue to operate Exchange Server 2016, 2013, and even more antiquated releases.

For threat actors, Exchange is an irresistible target. Its popularity, complexity, abundance of settings, and, most importantly, its accessibility from external networks make it susceptible to a wide range of attacks:

  • Infiltration of mailboxes via password spraying attacks or spearphishing
  • Account compromise via outdated authentication protocols
  • Theft of specific emails by injecting malicious mail flow rules through Exchange Web Services
  • Hijacking of employee authentication tokens or message forgery by exploiting flaws in the Exchange mail processing infrastructure
  • Exploitation of Exchange vulnerabilities to execute arbitrary code (deploy web shells) on the server
  • Lateral movement and server compromise, where the Exchange server becomes a foothold for network reconnaissance, malware hosting, and traffic tunneling
  • Long-term email exfiltration via specialized implants for Exchange

To truly grasp the complexity and variety of Exchange attacks, it’s worth reviewing research on the GhostContainer, Owowa, ProxyNotShell, and PowerExchange threats.

Making it harder for attackers to compromise Exchange and reducing the impact of a successful attack is not impossible, but requires a wide range of measures — from simple configuration changes to effort-intensive authentication protocol migrations. A joint review of priority defense measures was recently published by CISA (the Canadian Centre for Cyber Security) and other cybersecurity regulators. So how do you start hardening your on-premises Exchange server?

Migrating away from EOL versions

Both Microsoft and CISA recommend transitioning to Exchange SE to receive timely security updates. For organizations unable to make the switch immediately, a paid Extended Security Updates (ESU) subscription is available for versions 2016 and 2019. Microsoft emphasizes that upgrading from 2016 or 2019 to Exchange SE is comparable in complexity to installing a standard Cumulative Update.

If for any reason you need to keep an unsupported version in operation, it should be thoroughly isolated from both internal and external networks. All mail flow should be routed through a specially configured email security gateway.

Regular updates

Microsoft releases two Cumulative Updates (CUs) per year, along with monthly security hotfixes. A key task for Exchange administrators is to establish a process for deploying these updates without delay, as threat actors are quick to weaponize known vulnerabilities. You can track the release schedule and contents of these updates on the official Microsoft page. To verify the health and update status of your Exchange installation, use tools like SetupAssist and the Exchange Health Checker.

Emergency mitigations

For critical, actively exploited vulnerabilities, temporary mitigation guidance is typically published in the Exchange blog and on the Exchange mitigations page. The Emergency Mitigation (EM) service should be enabled on your Exchange Mailbox servers. EM automatically connects to the Office Config Service to download and apply mitigation rules for urgent threats. These measures can quickly disable vulnerable services and block malicious requests using URL rewrite rules in IIS.

Secure baselines

A uniform, organization-wide set of configurations optimized for an organization’s needs must be applied not only to Exchange servers but also to mail clients across all platforms and their underlying operating systems.

Since the recommended security baselines differ for various OS and Exchange versions, the CISA guide references the popular, freely available CIS Benchmarks and Microsoft instructions. The latest CIS Benchmark was created for Exchange 2019, but it’s also fully applicable to Exchange SE — since the current Subscription Edition doesn’t differ in its configurable options from Exchange Server 2019 CU15.

Specialized security solutions

A critical mistake many organizations make is not having EDR and EPP agents on their Exchange servers. To prevent vulnerability exploitation and the execution of web shells, the server needs to be protected by a security solution like Kaspersky Endpoint Detection and Response. Exchange Server integrates with the Antimalware Scan Interface (AMSI), which enables security tools to effectively process server-side events.

Application allowlisting can significantly hinder attackers attempting to exploit Exchange vulnerabilities. This feature comes as standard in most advanced EPP solutions. However, if you need to implement it with native Windows tools, you can restrict untrusted applications via App Control for Business or AppLocker.

To protect employees and their machines, the server should use a solution like Kaspersky Security for Mail Server to filter mail traffic. This addresses several challenges that the out-of-the-box on-prem Exchange lacks the tools for — such as sender authentication via SPF, DKIM and DMARC protocols, or protection against sophisticated spam and spearphishing.

If for any reason a full EDR isn’t deployed on the server, it’s essential to at least activate the default anti-virus, and ensure the Attack Surface Reduction (ASR) rule “Block Webshell creation for Servers” is enabled.

To prevent server performance degradation when running default anti-virus, Microsoft recommends excluding specific files and folders from scans.

Restricting administrative access

Attackers often escalate privileges by abusing access to the Exchange Admin Center (EAC) and PowerShell remoting. Best practice dictates making these tools accessible only from a fixed number of privileged access workstations (PAWs). This can be enforced via firewall rules on the Exchange servers themselves, or by using firewall. The built-in Client Access Rules in Exchange can also offer limited utility in this scenario, but they can’t counter PowerShell abuse.

Adopting Kerberos and SMB instead of NTLM

Microsoft is gradually phasing out legacy network and authentication protocols. Modern Windows installations disable SMBv1 and NTLMv1 by default, with future versions slated to disable NTLMv2. Starting with Exchange SE CU1, NTLMv2 will be replaced with Kerberos, implemented using MAPI over HTTP, as the default authentication protocol.

IT and security teams should conduct a thorough audit of legacy protocol usage within their infrastructure, and develop a plan for migration to modern, more secure authentication methods.

Modern authentication methods

Beginning with Exchange 2019 CU13, clients can leverage a combination of OAuth 2.0, MFA, and ADFS for robust server authentication — a framework known as Modern Authentication, or Modern Auth for short. This way, a user can only access a mailbox after successfully completing MFA through ADFS, with the Exchange server then receiving a valid access token from the ADFS server. Once all users have migrated to Modern Auth, Basic authentication should be disabled on the Exchange server.

Enabling Extended Protection

Extended Protection (EP) provides a defense against NTLM relay attacks, Adversary-in-the-Middle, and similar techniques. It enhances TLS security by using a Channel Binding Token (CBT). If an attacker steals credentials or a token, and attempts to use them in a different TLS session, the server terminates the connection. To enable EP, all Exchange servers must be configured to use the same version of TLS.

Extended Protection is active by default on new server installations starting with Exchange 2019 CU14.

Secure TLS versions

The entire server infrastructure, including all Exchange servers, should be configured to use the same TLS version: 1.2 or, ideally, 1.3. Microsoft provides detailed guidance on optimal configuration and necessary prerequisite checks. You can use the Health Checker script to verify the correctness and uniformity of these settings.

HSTS

To ensure all connections are protected by TLS, you should additionally configure HTTP Strict Transport Security (HSTS). This helps prevent certain AitM attacks. After implementing the Exchange Server configuration changes as recommended by Microsoft, all connections to Outlook on the web (OWA) and the EAC will be forced to use encryption.

Download domains

The Download Domains feature provides protection against certain cross-site request forgery attacks and cookie theft by moving attachment downloads to a domain other than one hosting the organization’s Outlook on the web. This separates the loading of the UI and message list from downloading file attachments.

Role-based administration model

Exchange Server implements a Role-Based Access Control (RBAC) model for privileged users and administrators. CISA notes that accounts with AD administrator privileges are often also used to manage Exchange. In this configuration, a compromise of the Exchange server immediately leads to a full domain compromise. So it’s critical to use split permissions and RBAC to separate Exchange management from other administrative privileges. This reduces the number of users and administrators with excessive privileges.

PowerShell stream signing

Administrators frequently use PowerShell scripts known as cmdlets to modify settings and manage Exchange servers via the Exchange Management Shell (EMS). Remote PowerShell access should ideally be disabled. When it is enabled, command data streams sent to the server must be protected with certificates. As of November 2023, this setting is enabled by default for Exchange 2013, 2016, and 2019.

Protection of mail headers

In November 2024, Microsoft introduced enhanced protection against attacks involving the forgery of P2 FROM mail headers, which made emails appear to victims as if they were sent from a trusted sender. New detection rules now flag emails where these headers have likely been manipulated. Administrators mustn’t disable this protection, and should forward suspicious emails bearing the X-MS-Exchange-P2FromRegexMatch header to security experts for further analysis.

Kaspersky official blog – ​Read More