CU22 and CU11 for Exchange 2016 and 2019 install the new Emergency Mitigation (EM) function. It is intended to implement immediate measures automatically when critical vulnerabilities occur. These can reduce the threat but can also deactivate Exchange features.

Microsoft explicitly points out that EM is only intended to close security gaps as long as no patch or CU is available to eliminate the vulnerability. So, in the on-prem world, administrators are still required to maintain the systems regularly and to apply updates and CUs.

Automatic responses in case of emergency ^

The EM service can apply three types of mitigation to ward off a potential threat:

  • IIS URL Rewrite rule mitigation: This blocks specific patterns of malicious HTTP requests.
  • Exchange service mitigation: Vulnerable services on an Exchange server can be (temporarily) disabled.
  • App pool mitigation: Like Exchange services, app pools can also be disabled.

Installing CUs with EM ^

Administrators no longer have to download the CUs from the license portal, but can also get them from the public support pages. The CU for Exchange 2019 is available here. Basically, the aforementioned CUs can be installed as usual. On the download page of the CU, you can find out the additional requirements related to EM:

The download page provides information on the extended requirements for the CU

The download page provides information on the extended requirements for the CU

In particular, you will need the URL rewriter for the IIS. The universal C-Runtime is downloaded and set up when the IIS rewrite module is installed. It immediately appears in the IIS Manager.

The Rewrite module plays an essential role in defending against attacks via the HTTP connection

The Rewrite module plays an essential role in defending against attacks via the HTTP connection

Note: Before you can start with the CU installation, Exchange usually needs a restart.

As you can see from the mandatory requirements for the CU setup, the installation of the mitigation service cannot be avoided. However, administrators do not have to use the feature and can deactivate it via PowerShell after installing the CU.

With this approach, Microsoft is apparently pursuing the goal of securing poorly maintained systems with an EM that is switched on by default.

Another prerequisite for EM is that the Exchange server must be able to reach the Office Config Service (OCS) over the URL https://officeclient.microsoft.com/getexchangemitigations. It connects to this once every hour to check for the presence of risk mitigations.

If vulnerabilities are detected, the EM service automatically implements a corresponding configuration, which the service receives in the form of an XML file.

Admins can test the connection to the OCS with a supplied script. From the Exchange script directory, you can start it with:

TestMitigationServiceConnectivity.ps1
The Rewrite module plays an essential role in defending against attacks via the HTTP connection

The Rewrite module plays an essential role in defending against attacks via the HTTP connection

After the CU has been installed on the Exchange server, it implements a new service called Microsoft Exchange Emergency Mitigation Service. If necessary, it should be included in the monitoring. Regardless of whether the EM is activated or deactivated, the service is always running.

Configuration of EM via PowerShell ^

The EM is immediately active after completion of the CU installation. Currently, it can only be configured via PowerShell.

You can query the status as follows:

Get-OrganizationConfig | Format-List MitigationsEnabled
Querying the status of the EM feature with PowerShell

Querying the status of the EM feature with PowerShell

You can query and change settings not only for the organization, but also per Exchange server, for example, with:

Get-Exchangeserver | Format-List MitigationsEnabled

Using:

Set-OrganizationConfig -MitigationsEnabled $false

You can deactivate EM throughout the organization. On the other hand:

Set-Exchangeserver -MitigationsEnabled $false

does this for only one server.

The latter makes perfect sense if some Exchange servers are accessible from the Internet and others are not.

Checking the application of risk mitigation ^

Admins should regularly check the state of the EM and see whether it has blocked any Exchange functions for security reasons. This can be done using the following cmdlet:

Get-ExchangeServer | Format-List name, MitigationsApplied, MitigationsBlocked
Using PowerShell to check which risk mitigations have been applied to the Exchange server

Using PowerShell to check which risk mitigations have been applied to the Exchange server

In this case, it is recommended to set up a scheduled task that automates sending a message to the respective Exchange administrator in the event of a new mitigation.

Since the EM is new, and thus organizations lack operational experience with it, you cannot rule out that it might block services and disrupt business processes in the company. If you don't keep an eye on EM, a search for any error could be tedious.

For this purpose, another script can further analyze the recommended security measures. This can also be found in the script directory of the Exchange server (Get-Mitigations.ps1).

Retrieving the report on the applied security measures

Retrieving the report on the applied security measures

Its report currently looks quite empty, as Microsoft has yet to deliver any mitigation apart from the one for testing purposes. You could run the script regularly and send the report to yourself by email.

The report created by Get Mitigations.ps1 in CSV format

The report created by Get Mitigations.ps1 in CSV format

Blocking mitigations ^

If you want to prevent certain mitigations, you can achieve this by running the following command:

Get-ExchangeServer | Set-ExchangeServer -MitigationsBlocked @("PING1")

If you want to apply the command to several mitigations, then you pass them as a comma-separated list to the MitigationsBlocked parameter.

Blocking is especially important after you have undone one of the mitigations, for example, because EM has deactivated an important Exchange function. In this case, the mitigation would be reapplied during the next run.

Documentation in the event log ^

For troubleshooting purposes, events 1005, 1006, and 1008 can be evaluated using the MSExchange Mitigation Service source, which should also be monitored. Here, you can learn details about the actions of EM, whereas 1008 only logs occurring errors.

In addition, the mitigation service creates a local log file in the \V15\Logging\MitigationService directory.

In addition to the event log EM writes to a new local log file daily.

In addition to the event log EM writes to a new local log file daily.

Conclusion ^

We currently still lack experience with this new feature, but I hope that it will not have to intervene too often or be so disruptive that the processes within the organization are affected.

Subscribe to 4sysops newsletter!

Otherwise, acceptance of this feature is likely to wane, which would defeat the whole purpose of this security extension for Exchange.

0 Comments

Leave a reply

Please enclose code in pre tags

Your email address will not be published. Required fields are marked *

*

© 4sysops 2006 - 2021

CONTACT US

Please ask IT administration questions in the forums. Any other messages are welcome.

Sending

Log in with your credentials

or    

Forgot your details?

Create Account