Language selection

Exchange Vulnerability 2021

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

Introduction

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:

    b75f163ca9b9240bf4b37ad92bc7556b40a17e27c2b8ed5c8991385fe07d17d0
097549cf7d0f76f0d99edf8b2d91c60977fd6a96e4b8c3c94b0b1733dc026d3e
2b6f1ebb2208e93ade4a6424555d6a8341fd6d9f60c25e44afe11008f5c1aad1
65149e036fff06026d80ac9ad4d156332822dc93142cf1a122b1841ec8de34b5
511df0e2df9bfa5521b588cc4bb5f8c5a321801b803394ebc493db1ef3c78fa1
4edc7770464a14f54d17f36dc9d0fe854f68b346b27b35a6f5839adf1f13f8ea
811157f9c7003ba8d17b45eb3cf09bef2cecd2701cedb675274949296a6a183d
1631a90eb5395c4e19c7dbcbf611bbe6444ff312eb7937e286e4637cb9e72944

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:

    hXXp://p.estonine[.]com/p?e
hXXp://cdn.chatcdn.net/p?low

    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.

    103.77.192[.]219
104.140.114[.]110
104.248.49[.]97
104.250.191[.]110
108.61.246[.]56
112.66.255[.]71
139.59.56[.]239
149.28.14[.]163
157.230.221[.]198
161.35.1[.]207
161.35.1[.]225
161.35.45[.]41
161.35.51[.]41
161.35.76[.]1
165.232.154[.]116
167.99.168[.]251
167.99.239[.]29
182.18.152[.]105
185.250.151[.]72
188.166.162[.]201
192.81.208[.]169
203.160.69[.]66
211.56.98[.]146
45.77.252[.]175
5.2.69[.]14
5.254.43[.]18
77.61.36[.]169
80.92.205[.]81
86.105.18[.]116
89.34.111[.]11
91.192.103[.]43

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