Recently published blog posts:
Go to the blog archive and browse all previous blog posts
we have published so far.
Subscribe to the GovCERT.ch blog RSS feed to stay up to
date and get notified about new blog posts.
Recently published whitepapers:
Subscribe to the whitepapers RSS feed to stay up to date
and get notified about new whitepapers.
Report an incident:
The following email address can be considered as point of
contact for FIRST members and other
Alternative GovCERT.ch PGP Key (for older versions of PGP without Curve25519 support)
Published on March 9, 2021 13:21 +0100 by GovCERT.ch (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:
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.
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.
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:
Known Webshell SHA256 Hashes:
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:
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.
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