Exchange Vulnerability 2021

Published on March 9, 2021 13:21 +0100 by (permalink)
Last updated on March 9, 2021 13:21 +0100


In the past days, there was a lot of press coverage about several critical zero day vulnerabilities in Microsoft Exchange Server that are being tracked under the following CVEs:

  • CVE-2021-26855
  • CVE-2021-26857
  • CVE-2021-26858
  • CVE-2021-27065

Unfortunately, we recently became aware of several hundred organizations in Switzerland that got compromised by a threat actor that exploited the said vulnerability. While Microsoft attributed the initial, in-the-wild observed compromises to a Chinese state-sponsored group called HAFNIUM, several other threat actors quickly got hold of this exploit since the publication of patches by Microsoft. As a result, we have started informing possible compromised organizations based on information provided to us by trusted third parties.

Since the release of the security updates by Microsoft, the infections have become much more widespread. We have warned the public via Twitter (2nd of March), NCSC Homepage and the critical infrastructures via our closed community platform. In the meanwhile, we have been informed about several compromised Exchange servers in Switzerland. Please note that this vulnerability does not only affect Exchange servers that expose OWA (Outlook Web Access) to the Internet but also servers exposing other components using https (e.g. ActiveSync or Unified Messaging, the Offline Address Book (OAB) and other services).

We have evidence that the vulnerability got exploited very quickly after the release of the initial advisory issued by Microsoft on March 2nd 2021, probably even within just a few hours. At the moment, we are still receiving and dispatching information about the vulnerabilities and possible compromised organizations in Switzerland. If you receive such an information from NCSC or if you want to ensure that you have not been compromised, we suggest following the below mentioned procedure. If you are not sure if you have the technical knowledge internally, we strongly suggest asking a specialized company providing incident response for support.

Ensure you are patched

Determine if your servers are still vulnerable or if they have been successfully patched. Microsoft provides guidance for patching as well as patches for End Of Life (EOL) products here. Please note that despite the EOL patches Microsoft provides for Exchange 2007, 2010, these versions are EOL and should be migrated to a supported version as soon as possible.

Please note that patching after a compromise is not enough and the system MUST BE REBUILT from scratch. If this is not possible in the short term, then the mitigation tool by Microsoft can apply temporary mitigations for the Exchange vulnerability and remove some attacker artifacts.

Search for Forensic Artifacts

  • Detect if webshells are present. There are a few places where no .aspx should exist or only very few provided by the Exchange Server itself:

    \inetpub\wwwroot\aspnet_client\ (any .aspx file under this folder or sub folders)
    \<exchange install path>\FrontEnd\HttpProxy\ecp\auth\ (TimeoutLogoff.aspx is legit)
    \<exchange install path>\FrontEnd\HttpProxy\owa\auth\ (newer files (e.g. after 2nd of March 2021 that do not belong to the installation))
    \<exchange install path>\FrontEnd\HttpProxy\owa\auth\Current\ (should not contain .aspx files)
    \<exchange install path>\FrontEnd\HttpProxy\owa\auth\<folder with version number>\ (should not contain .aspx files)

    Microsoft provided a list of currently known locations where webshell have been dropped.

    You can also scan for the presence of webshells using YARA, e.g. by the free Loki Scanner provided by Nextron Systems or by using YARA rules provided by Volexity

  • Search for other forensic artifacts:

    • All files that have been written in the timeframe between the date of publication (maybe start 14 days earlier) and now that reside within the Exchange Server web root.
    • Child processes started by C:\Windows\System32\inetsrv\w3wp.exe, e.g. cmd.exe
    • Files written by w3wp.exe or by UMWorkerProcess.exe.
    • Also promising is a search for the following tools that are known to be used by these attacker groups (but these may have been legitimately used by their team - especially in the case of psexec):
      • psexec and procdump from the SysInternals Tool Suite.
      • WinRAR for exfiltration of stolen data
      • Powershell scripts
      • ASPx and PHP webshells. In general, however, you can look at what files were uploaded around the time period and check them.
      • Tools from the Nishang Tool Suite Github
      • Powercat - a netcat in Powershell: Github
    • Search for newly created user accounts with high privileges
    • Search for Mailbox Access using Powershell CmdLets (e.g. New-MailboxExportRequest)
  • Known Webshell SHA256 Hashes:


Analyse your logfiles

A good approach is to check the logs from Exchange IIS. Usually the attackers don’t bother to disguise the user agents, so new user agents or user agents pointing to a script can be a good indicator.

  • Search for unusual User Agents or User Agents that emerged only after the publication of the security bulletin. Volexity provides a list of known User Agents that were used during these attacks performing POST requests. Please note that most of these user agents can also be legitimate, so combine the search with POST requests to suspicious URLs

  • Search your logfiles for .aspx files that have never been accessed before the publication of the security bulletin.

  • Search for requests to files you have found during the search for forensic artefacts. This may give you a hint if there has been attacker’s activity after the initial compromise

  • Search for POST requests without a Referer.

  • Have a close look at your AD logs and search for signs of lateral movement

  • Have a look at your AV logs for suspicious entries such as blocking Mimikatz or other attack tools

  • Search and monitor for outbound connections originating from the exchange server.

  • Search for references such as the below mentioned strings or variants of it: S:CMD=Set-OabVirtualDirectory.ExternalUrl='

  • The following URLs are known to have been used during these attacks:


    Both domains are hosted on the same IP address (188.166.162[.]201), we suggest treating any connection to a domain residing on this IP address to be considered suspicious.

  • On several occasions, the attackers used one of the following IP ]addresses. Please note that IP addresses can cause False Positives.


General recommendations

We recommend the following security precautions for a better protection of your Exchange Server infrastructure:

  • Do not expose Exchange directly to the Internet. Either have a WAF in front of it and/or use an SMTP filtering proxy in front of Exchange servers

  • Have an emergency patch process that allows you patching your infrastructure, especially elements that are directly exposed to the Internet, within a very short timeframe (hours).

  • Closely monitor all Exchange Server logfiles, collect them in a SIEM and look for unusual patterns

  • Always deploy a 2nd factor for the authentication of users

  • Use a dedicated management network for accessing Exchange Server with high privileges

  • Log all AD logs centrally and analyse them on a regular base

  • Increase the visibility on the endpoints by using an EDR Tool (Endpoint Detection and Response)

  • Quite exhaustive blogpost by Volexity

  • Another readworthy blogpost by BlueTeam

  • Blog by Microsoft Security Response Center MSRC

  • Blog by Microsoft about Hafnium Blogpost

  • Blog by Fireeye

  • Powershell Script from Microsoft on Github

  • nmap Script for Searching of vulnerable Instances Github

  • Sysmon Config Github

  • Warning of ANSSI (French) ANSSI

  • Warning of BSI (German) BSI

  • One-Click Microsoft Exchange On-Premises Mitigation Tool

Back to top