- Microsoft Graph: A single (PowerShell) API for Microsoft’s cloud services - Tue, Aug 23 2022
- Exchange impersonation: Grant permissions to service accounts - Mon, Aug 8 2022
- Send Microsoft Teams meeting invitations in multiple languages - Thu, Jul 21 2022
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
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
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
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
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
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
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
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.
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.
