Bryson Medlock

Bryson Medlock
on March 8, 2021

Perch bulletin: Exchange Marauder update

Perch bulletin: Exchange Marauder update

Last week, we wrote about several critical vulnerabilities released concerning on-premises Microsoft Exchange servers. More information is now available, and this continues to be a critical incident nearly a week after the information was originally disclosed.

First of all, if you haven’t patched your Exchange servers yet, you can assume that you’ve already been compromised. Current reports suggest at least 30,000 US organizations have been affected by this vulnerability. According to our search on Shodan this morning, there are still over 60,000 vulnerable Exchange servers across the world, about 15,000 in the US.

Image and data from Shodan

Some reports suggest these 0-day vulnerabilities have been used since November 2020. Even if you patched your servers as soon as the vulnerabilities were announced, we still recommend using the information below to look for infections.

Patching your servers will prevent exploitation but will do nothing to mitigate any existing malicious scripts or shells.

Again, we strongly recommend patching your servers immediately. According to Microsoft, full mitigation is only possible by applying the relevant patches.

Interim Mitigation Techniques

If you’re unable to apply the patch, Microsoft has released some interim mitigation techniques.

The first interim mitigation technique for CVE-2021-26855 uses IIS rewrite rules, and Microsoft has released a PowerShell script to help you implement them.

Refer to the Microsoft MSRC blog for full details on using this script. For a quick reference:

To apply with MSI install via PowerShell:

.\BackendCookieMitigation.ps1 -FullPathToMSI “FullLocalPathToMSI” -WebSiteNames “Default Web Site” -Verbose

PowerShell command to create IIS rewrite rule without installing the IIS rewrite module:

.\BackendCooieMitigation.ps1 -WebSiteNames “Default Web Site” -Verbose

To revert changes:

.\BackendCookieMitigation.ps1 -WebSiteNames “Default Web Site” -RollbackMitigation -Verbose

The second interim mitigation technique recommend by Microsoft is for CVE-2021-26857 and it is to disable the UM service. Keep in mind that this will cause an outage for Unified Messaging/Voicemail. Again, details are in the Microsoft article. You can disable the UM service via the Exchange management shell:

Set-ServerComponentState -Component UMCallRouter -Identity “ComputerName” -Requester Maintenance -State Inactive

Stop-Service MSExchangeUM

Set-Service MSExchangeUM -StartupType Disabled

Stop-Service MSExchangeUMCR

Set-Service MSExchangeUMCR -StartupType Disabled

Interim mitigation recommended by Microsoft for CVE-2021-27065 is to Disable ECP Application Pool. This will bring your Exchange Control Panel offline. Disable your ECP Application Pool via the Exchange Management Shell with the following commands:

Set-ServerComponentState -Component EcpProxy -Identity “ComputerName” -Requester Maintenance -State Inactive

Import-module WebAdministration

$AppPoolName = “MSExchangeECPAppPool”

$AppPool = Get-Item IIS:\AppPools\$AppPoolName

$AppPool.startMode = “OnDemand”

$AppPool | Set-Item -Verbose

Stop-WebAppPool -Name $AppPoolName

Microsoft recommends disabling OAB Application Pool as interim mitigation for CVE-2021-26858. This will cause calls to your Offline Address Book to fail with a 503 error, and downloads of the OAB by Outlook clients will fail. Disable the OAB Application Pool via the Exchange Management Shell:

Set-ServerComponentState -Component OabProxy -Identity “ComputerName” -Requester Maintenance -State Inactive

Import-module WebAdministration

$AppPoolName = “MSExchangeOABAppPool”

$AppPool = Get-Item IIS:\AppPools\$AppPoolName

$AppPool.startMode = “OnDemand”

$AppPool | Set-Item -Verbose

Stop-WebAppPool -Name MSExchangeOABAppPool

Additional Tools for Detecting Vulnerability/Infection

An Nmap script is available to detect whether a specific URL is vulnerable to the Exchange SSRF vulnerability (CVE-2021-26855). On Windows, you can download the Nmap script directly or use the following command:

nmap –script-updatedb

Then use Nmap to scan the IP address of your Exchange server:

Nmap -Pn -p T:443 –script http-vuln-cve2021-26855 IP

Microsoft has also released a PowerShell script that will search through your logs for artifacts related to these vulnerabilities. Scan your servers with the PowerShell script released by Microsoft.
Check the local Exchange server only and save the report:

.\Test-ProxyLogon.ps1 -OutPath $home\desktop\logs

Check all Exchange servers and save the reports:

Get-ExchangeServer | .\Test-ProxyLogon.ps1 -OutPath $home\desktop\logs

Perch Detection

Generally speaking, initial detection isn’t possible using only IDS signatures as the web traffic all occurs over TLS and is encrypted. At this time, detection by Perch requires log collection.

Make sure you install the Perch log shipper on all your Exchange servers. Follow the Perch Help guide for installing the log shipper. We’ve been able to detect exploitation by searching through Perchybana for “cmd.exe” processes spawned by “w3wp.exe” (the IIS worker process). In Perchybana, this query looks like:

process.parent.args:“c:\windows\system32\inetsrv\w3wp.exe” AND process.args:“C:\Windows\System32\cmd.exe”

Some reporting applications, such as Logi Report, will produce false positives, but, in most cases, the above query will quickly identify exploitation. The Perch SOC has been using this query to identify a number of affected customers and is working with them to mitigate.

We also strongly recommend configuring Filebeat to ship your IIS logs to Perch for improved detection. Filebeat is a separate agent that will need to be downloaded and configured manually. Download the Filebeat agent at

Use the information in Perch Help to configure additional Beats agents. To configure the collection and parsing of IIS log files, go to the appropriate ‘manifest.yml’ located under \module\

Edit the manifest.yml file to include the appropriate path to logs (see example below):

Then save the manifest.yml file and enable the desired module by running the following command in PowerShell:

PS > .\filebeat.exe modules enable iis

Without the necessary logs, our detection capabilities will be limited. The Perch support team ( is available to assist with configuration if needed.

We also recommend checking the following directories for potentially malicious files:

\inetpub\wwwroot\aspnet_client\ (any .aspx file under this folder or sub folders)

\\FrontEnd\HttpProxy\ecp\auth\ (any file besides TimeoutLogoff.aspx)

\\FrontEnd\HttpProxy\owa\auth\ (any file or modified file that is not part of a standard install)



Perch Observations

We have observed several web shells, mostly China Chopper, as well as some malicious PowerShell activity within multiple customer environments. The PowerShell looks like it was obfuscated using the Veil Framework and ends up installing MimiKatz, a tool for stealing credentials, as well as Cobalt Strike for C2 activity. Malicious PowerShell has also been observed installing a cryptocurrency-mining bot.

In some cases, customers have patched their servers but were already compromised. Patching does not remove existing infections. Even if you have patched your systems or used the mitigation techniques listed above, we recommend using the Microsoft script above to scan for existing infections.

While exploitation was primarily coming from the threat actor group Hafnium, multiple adversaries have jumped on the bandwagon, including UNC2639, UNC2640, and UNC2643.

If you haven’t already, watch the live stream we did on the Microsoft Exchange 0-day vulnerability and the upcoming 2021 MSP Threat Report.


We'd love to hear your thoughts. Find us on Twitter, LinkedIn or write in to

Next: Clearing the Path: Perch Adds Datto Autotask PSA Ticket Integration

Share this on:

Bryson Medlock

Bryson Medlock
on March 8, 2021

Perchy Subscribe to our blog