Exchange Server Emergency Mitigation Service

Exchange Server Emergency Mitigation Service

It has been a tough few months for Microsoft. After the SolarWinds/NOBELLIUM attacks, Microsoft Exchange customers were afflicted with a slew of vulnerabilities. In March 2021, the ProxyLogon vulnerability emerged, followed by an exploit that surfaced in April 2021 called NSA Meeting. In August 2021, Orange Tsai released a series of new vulnerabilities called ProxyOracle and ProxyShell, followed by the discovery of another Proxy flaw, dubbed ProxyToken.

This week, it was revealed that a new Autodiscover flaw could be used to steal user credentials. The Autodiscover flaw was reported by Marco Van Beek to Microsoft in 2016 and was also separately discovered by security researcher Amit Serper. In 2016, Microsoft stated that this was not a “security issue to be serviced as part of our monthly Patch Tuesday process”. However, this is perhaps a sign of Microsoft’s renewed focus on exchange vulnerabilities, as 5 years later Microsoft has stated that it is “continuing to investigate” the issue.

 

What is the Emergency Mitigation service?

Microsoft has clearly recognised that organisations find it difficult to patch their on-premise servers in time, therefore has released a new feature called the Microsoft Exchange Emergency Mitigation service (EM). Whilst the service is not designed to be a replacement for security updates (SUs), it aims to be the fastest and easiest way to mitigate the highest threats prior to installing the applicable SUs. It will apply a temporary fix until the relevant security update can be applied, which properly fixes the issue.

The new mitigation service is designed to reduce the reliance on manual patches and take a much more proactive approach when threats are discovered. This means that the mitigation service may automatically disable features or functionality on an Exchange server in response to threats. To do this, the EM is set to run as a Windows service that integrates with the cloud-based Office Config Service (OCS). Every hour the Exchange server will check the OCS for any required mitigations. If mitigations are found, they are sent to the Exchange server which will automatically apply the preconfigured settings after verifying the signatures to ensure it has not been tampered with.

There are a number of mitigations that can be applied, but Microsoft has outlined the following actions that can be taken:

• Disabling an Exchange Service
• Disabling a virtual directory or app pool, and most importantly;
• Implementing an IIS rewrite rule to filter malicious HTTPS requests

For this reason, the EM service requires the IIS URL rewrite module v2 to be installed on the Exchange server. This module will now be a pre-requisite to installing Exchange and is included with the September 2021 CU. It will be installed whether you plan to use the EM service or not.

It must be noted that running the service is optional and can be disabled by an admin. Microsoft advises that it should be disabled on Exchange servers without internet connectivity because if it cannot connect to OCS, it will not work.

 

How to manage the Emergency Mitigation service

There are a number of new commands that have been added to allow administrators to manage the service. These include disabling the service at the organisational level, the Exchange server level, and blocking individual mitigations. Blocked mitigations are added to a blocklist to prevent them from being reapplied in the future, for example:

• To block mitigations named “M1” and “M2” you can use: Set-ExchangeServer -Identity -MitigationsBlocked @(“M1”, “M2”)
• To remove M2 from the blocklist where both M1 and M2 have been previously blocked: Set-ExchangeServer -Identity -MitigationsBlocked @(“M1”)
• Removing all mitigations from the blocklist is a case of issuing: Set-ExchangeServer -Identity -MitigationsBlocked @0
• Microsoft has included a script with the update called Get-Mitigation.ps1, which can be used to export both the list of applied mitigations and their descriptions: .\Get-Mitigation.ps1 -Identity -ExportCSV “C:\temp\CSVReport.csv”

The EM service is intended to be an interim measure. When mitigations are applied but no longer required (as in the case of a CU or SU update), the admin must manually remove applied mitigation actions to reverse their effects.

If an update patches an issue for which there is mitigation, the mitigation will be removed from the list of available mitigations to download and will also remove itself from the list of applied mitigations. However, the mitigation would remain configured. If the mitigation was to disable a service, the admin will need to manually enable the service again.

In the case of IIS rewrite rules, Microsoft has prefixed these with “EEMS ”, but currently the onus is on admins to track what automatic mitigations have been applied.

• The following command may help track these mitigations by showing the applied and blocked mitigations across the environment: Get-ExchangeServer -Identity | fl name, MitigationsApplied, MitigationsBlocked
• Actions taken by the EM service will also be logged and can be searched using Search-AdminAuditLog. An example to search for mitigations applied and blocked in October: Search-AdminAuditLog -Cmdlets Get-ExchangeServer -Parameters MitigationsApplied, MitigationsBlocked -StartDate 10/01/2021 -EndDate 10/31/2021

Overall, this is a welcome step in the right direction for fast automatic patching of vulnerabilities as soon as mitigations are available. The interim nature of the solution does create some headaches for administrators, but given the severity of recent Exchange exploits, this may be a price worth paying for the additional protection.

Sentrium can assist with your security needs, view our penetration testing services for more details or contact us today.