Exchange Emergency Mitigation (EM) service

APPLIES TO: 👁 yes-img-16
2016 👁 yes-img-19
2019 👁 yes-img-se
Subscription Edition

The Exchange Emergency Mitigation service (EM service) helps to keep your Exchange Servers secure by applying mitigations to address any potential threats against your servers. It uses the cloud-based Office Config Service (OCS) to check for and download available mitigations and to send diagnostic data to Microsoft.

The EM service runs as a Windows service on an Exchange Mailbox server. When you install the September 2021 CU (or later) on Exchange Server 2016 or Exchange Server 2019, the EM service is installed automatically on servers with the Mailbox role. The EM service won't be installed on Edge Transport servers.

The use of the EM service is optional. If you don't want Microsoft to automatically apply mitigations to your Exchange servers, you can disable the feature.

Mitigations

A mitigation is an action or set of actions that are taken automatically to secure an Exchange server from a known threat that is being actively exploited in the wild. To help protect your organization and mitigate risk, the EM service might automatically disable features or functionality on an Exchange server.

The EM service can apply the following types of mitigations:

• IIS URL Rewrite rule mitigation: This mitigation is a rule that blocks specific patterns of malicious HTTP requests that can endanger an Exchange server.
• Exchange service mitigation: This mitigation disables a vulnerable service on an Exchange server.
• App Pool mitigation: This mitigation disables a vulnerable app pool on an Exchange server.

You have visibility and control over any applied mitigation by using Exchange PowerShell cmdlets and scripts.

How it works

If Microsoft learns about a security threat, we might create and release a mitigation for the issue. If this happens, the mitigation is sent from the OCS to the EM service as a signed XML file containing the configuration settings that are required to apply the mitigation.

After the EM service has been installed, it checks the OCS for available mitigations every hour. The EM service then downloads the XML file and validates the signature to verify that the XML wasn't tampered with. The EM service checks the issuer, the Extended Key Usage, and the certificate chain. After successful validation, the EM service applies the mitigation.

Each mitigation is a temporary, interim fix until you can apply the Security Update that fixes the vulnerability. The EM service isn't a replacement for Exchange SUs. However, it's the fastest and easiest way to mitigate the highest risks to internet-connected, on-premises Exchange servers before updating.

List of mitigations released

The following table describes the repository of all released mitigations.

Prerequisites

If these prerequisites aren't already on the Windows Server where Exchange is installed or to be installed, Setup prompts you to install these prerequisites during the readiness check:

• IIS URL Rewrite Module
• Universal C Runtime in Windows (KB2999226) for Windows Server 2012 and Windows Server 2012 R2

Connectivity

The EM service needs outbound connectivity to the OCS to check for and download mitigations. If outbound connectivity to the OCS isn't available during the installation of Exchange Server, Setup issues a warning during the readiness check.

While the EM service can be installed without connectivity to the OCS, it must have connectivity to the OCS to download and apply the latest mitigations. The OCS must be reachable from the computer on which Exchange Server is installed for the EM service to function correctly.

If a network proxy is deployed for outbound connectivity, you need to configure the InternetWebProxy parameter on the Exchange server by running the following command:

Set-ExchangeServer -Identity <ServerName> -InternetWebProxy <http://proxy.contoso.com:port>

You must also configure the proxy address additionally in WinHTTP proxy settings:

netsh winhttp set proxy <proxy.contoso.com:port>

In addition to outbound connectivity to the OCS, EM service needs outbound connectivity to various Certificate Revocation List (CRL) endpoints mentioned here.

These are required to verify authenticity of certificates used to sign the mitigations XML file.

We strongly recommend letting Windows maintain the Certificate Trust List (CTL) on your machine. Otherwise, this must be maintained manually regularly. To allow Windows to maintain the CTL, the following URL must be reachable from the computer on which Exchange Server is installed.

Test-MitigationServiceConnectivity script

You can verify that an Exchange server has connectivity to the OCS by using the Test-MitigationServiceConnectivity.ps1 script in the V15\Scripts folder in the Exchange server directory.

If the server has connectivity, the output is:

Result: Success.
Message: The Mitigation Service endpoint is accessible from this computer.

If the server doesn't have connectivity, the output is:

Result: Failed.
Message: Unable to connect to the Mitigation Service endpoint from this computer. To learn about connectivity requirements, see https://aka.ms/HelpConnectivityEEMS.

Disable automatic mitigation through the EM service

One of the EM service functions is downloading mitigations from the OCS and automatically applying them to the Exchange Server. If your organization has an alternate means of mitigating a known threat, you might choose to disable automatic applications of mitigations. You can enable or disable automatic mitigation at an organizational level or at the Exchange server level.

To disable automatic mitigation for your entire organization, run the following command:

Set-OrganizationConfig -MitigationsEnabled $false

By default, MitigationsEnabled is set to $true. When set to $false, the EM service still checks for mitigations hourly but doesn't automatically apply mitigations to any Exchange server in the organization, regardless of the value of the MitigationsEnabled parameter at the server level.

To disable automatic mitigation on a specific server, replace <ServerName> with the name of the server, and then run the following command:

Set-ExchangeServer -Identity <ServerName> -MitigationsEnabled $false

By default, MitigationsEnabled is set to $true. When set to $false, the EM service checks for mitigations hourly but doesn't automatically apply them to the specified server.

The combination of the organization setting and the server settings determine the behavior of the EM service on each Exchange server. This behavior is described in the following table:

View applied mitigations

After mitigations are applied to a server, you can view the applied mitigations by replacing <ServerName> with the name of the server, and then running the following command:

Get-ExchangeServer -Identity <ServerName> | Format-List Name,MitigationsApplied

Example output:

Name : Server1
MitigationsApplied : {M01.1, M01.2, M01.3}

To see the list of applied mitigations for all Exchange servers in your environment, run the following command:

Get-ExchangeServer | Format-List Name,MitigationsApplied

Example output:

Name : Server1
MitigationsApplied : {M01.1, M01.2, M01.3}

Name : Server2
MitigationsApplied : {M01.1, M01.2, M01.3}

Reapply a mitigation

If you accidentally reverse a mitigation, the EM service reapplies it when it performs its hourly check for new mitigations. To manually reapply any mitigation, restart the EM service on the Exchange server by running the following command:

Restart-Service MSExchangeMitigation

Ten minutes after restarting, the EM service runs its check and applies any mitigations.

Block or remove mitigations

If a mitigation critically affects the functionality of your Exchange server, you can block the mitigation, and manually reverse it.

To block any mitigation, add the Mitigation ID in the MitigationsBlocked parameter:

Set-ExchangeServer -Identity <ServerName> -MitigationsBlocked @("M1")

The previous command blocks the M1 mitigation, which ensures that EM service won't reapply this mitigation in the next hourly cycle.

To block more than one mitigation, use the following syntax:

Set-ExchangeServer -Identity <ServerName> -MitigationsBlocked @("M1","M2")

Blocking a mitigation doesn't automatically remove it, but after blocking a mitigation, you can manually remove it. How a mitigation is removed depends on the type of mitigation. For example, to remove an IIS rewrite rule mitigation, delete the rule in IIS Manager. To remove a service or app pool mitigation, start the service or app pool manually. For the detailed steps to remove a specific released mitigation, see the Rollback procedures for released mitigations section.

You can also remove one or more mitigations from the blocked mitigations list by removing the Mitigation ID in the MitigationsBlocked parameter in the same command.

For example:

Set-ExchangeServer -Identity <ServerName> -MitigationsBlocked @()

After a mitigation is removed from the blocked mitigations list, the EM service reapplies the mitigation on its next run. To manually reapply the mitigation, stop and restart the EM service by running the following command:

Restart-Service MSExchangeMitigation

Ten minutes after restarting, the EM service runs its check and applies any mitigations.

View applied and blocked mitigations

You can view both applied and blocked mitigations for all Exchange servers in your organization by using the Get-ExchangeServer cmdlet.

To view the list of applied and blocked mitigations for all Exchange servers, run the following command:

Get-ExchangeServer | Format-List Name,MitigationsApplied,MitigationsBlocked

Example output:

Name : Server1
MitigationsApplied : {M01.1, M01.3}
MitigationsBlocked : {M01.2}

Name : Server2
MitigationsApplied : {M01.1, M01.2}
MitigationsBlocked : {M01.3}

To view the list of applied and blocked mitigations on a per-server basis, replace <ServerName> with the name of the server, and then run the following command:

Get-ExchangeServer -Identity <ServerName> | fl name, *Mitigations*

Example output:

Name : Server1
MitigationsEnabled : True
MitigationsApplied : {M01.1, M01.3}
MitigationsBlocked : {M01.2}

Get-Mitigations script

You can use the Get-Mitigations.ps1 script to analyze and track the mitigations provided by Microsoft. This script is available in the V15\Scripts folder in the Exchange Server directory.

The script displays the ID, type, description, and status of each mitigation. The list includes any applied, blocked, or failed mitigations.

To view the details of a specific server, provide the server name in the Identity parameter. For example, .\Get-Mitigations.ps1 -Identity <ServerName>. To view the status of all the servers in your organization, omit the Identity parameter.

Example: Export the list of applied mitigations and their descriptions to a CSV file by using the ExportCSV parameter:

.\Get-Mitigations.ps1 -Identity <ServerName> -ExportCSV "C:\temp\CSVReport.csv"

Remove mitigations after an SU or CU upgrade

After an SU or a CU has been installed, an admin must manually remove any mitigations that are no longer needed. For example, if a Mitigation named M1 is no longer relevant after installing an SU, the EM service stops applying it, and it's removed from the list of applied mitigations. Depending on the type of mitigation, it can be removed from the server if necessary. For the detailed steps to remove a specific released mitigation, see the Rollback procedures for released mitigations section.

There might be a delay between the release of an Exchange Server Security Update (SU) or Cumulative Update (CU) and an update to the Mitigation XML file, excluding the security fixed build numbers from the Mitigations being applied. This is expected and shouldn't cause any problems. If you want to remove and block a Mitigation being applied in the meantime, you can follow the steps outlined in the Block or remove mitigations section.

We update the table under List of mitigations released section, along with the corresponding steps in the Rollback procedures for released mitigations section, for the specific Mitigation as soon as it's no longer applied to security fixed Exchange builds.

Rollback procedures for released mitigations

This section provides the detailed steps to manually remove specific released mitigations. Only run these steps after you confirm that the mitigation is no longer needed (for example, after you install the SU or CU that fixes the underlying vulnerability) and that the EM service won't reapply it. To prevent the EM service from reapplying a mitigation, block it first as described in the Block or remove mitigations section.

M1

Remove the rule EEMS M1.1 PowerShell - inbound manually from the IIS URL Rewrite module inside the Default Web Site.

M2

Run the following commands to back up the affected web.config file and remove the M2 URL Rewrite outbound rule and its precondition:

Copy-Item -Path "$env:ExchangeInstallPath\FrontEnd\HttpProxy\owa\web.config" -Destination "$env:ExchangeInstallPath\FrontEnd\HttpProxy\owa\web.config.$((Get-Date).ToString('yyyyMMdd-HHmmss')).bak"

Remove-WebConfigurationProperty -PSPath "IIS:\Sites\Default Web Site\owa" -Filter "system.webServer/rewrite/outboundRules" -Name "." -AtElement @{name="EEMS M2.1 OWA CSP - outbound"}

Remove-WebConfigurationProperty -PSPath "IIS:\Sites\Default Web Site\owa" -Filter "system.webServer/rewrite/outboundRules/preConditions" -Name "." -AtElement @{name="EEMS M2.1 OWA SPA HTML shell - precondition"}

Audit and logging

Any mitigations blocked by an admin are logged in the Windows Application Event Log. In addition to logging blocked mitigations, the EM service also logs details about service startup, shutdown, and termination (like all services running on Windows) and details of its actions and any errors encountered by the EM service. For example, Events 1005 and 1006 with a source of "MSExchange Mitigation Service" are logged for successful actions such as when a mitigation is applied. Event 1008 with the same source is logged for any encountered errors, such as when the EM service can't reach the OCS.

You can use Search-AdminAuditLog to review actions taken by yourself or other admins, including enabling and disabling automatic mitigations.

The EM service maintains a separate log file in the \V15\Logging\MitigationService folder in the Exchange Server installation directory. This log details the tasks performed by the EM service, including fetched, parsed, and applied mitigations and details about the information sent to the OCS (if sending diagnostic data is enabled).

Diagnostic data

When data sharing is enabled, the EM service sends diagnostic data to the OCS. This data is used to identify and mitigate threats. To learn more about what is collected and how to disable data sharing, see Diagnostic Data collected for Exchange Server.