(Updated April 14, 2021): Microsoft's April 2021 Security Update newly discloses and mitigates significant vulnerabilities affecting on-premises Exchange Server 2013, 2016, and 2019.
Microsoft has released out-of-band security updates to address four vulnerabilities in Exchange Server:
Reading: aka/ms/remoteconnect google
- CVE-2021-26855 allows an unauthenticated attacker to send arbitrary HTTP requests and authenticate as the Exchange Server. The vulnerability exploits the Exchange Control Panel (ECP) via a Server-Side Request Forgery (SSRF). This would also allow the attacker to gain access to mailboxes and read sensitive information.
- CVE-2021-26857, CVE-2021-26858, and CVE-2021-27065 allow for remote code execution.
CVE-2021-26858 and CVE-2021-27065 are similar post-authentication arbitrary write file vulnerabilities in Exchange. An attacker, authenticated either by using CVE-2021-26855 or via stolen admin credentials, could write a file to any path on the server.
CVE-2021-26857 is an insecure deserialization vulnerability in the Unified Messaging service. An attacker, authenticated either by using CVE-2021-26855 or via stolen admin credentials, could execute arbitrary code as SYSTEM on the Exchange Server.
To locate a possible compromise of these CVEs, CISA encourages organizations read the Microsoft Advisory.
It is possible for an attacker, once authenticated to the Exchange server, to gain access to the Active Directory environment and download the Active Directory Database.
(Updated March 12, 2021): Microsoft Security Intelligence has released a tweet on DearCry ransomware being used to exploit compromised on-premises Exchange Servers. Ransomware infections can have negative consequences to an affected organization, including:
- temporary or permanent loss of sensitive or proprietary information,
- disruption to regular operations,
- financial losses incurred to restore systems and files, and
- potential harm to an organization’s reputation.
(Updated April 12, 2021): CISA recommends organizations review Malware Analysis Report (MAR) MAR-10330097-1.v1 – DearCry Ransomware for detailed analysis, along with TTPs and IOCs.
(Updated March 12, 2021): CISA encourages organizations to review CISA’s Ransomware web page for guidance and resources. Victims of ransomware should report it immediately to CISA at wtbblue.com/report, a local FBI Field Office, or Secret Service Field Office.
Tactics, Techniques and Procedures
(Updated March 10, 2021): Microsoft has released a script that scans Exchange log files for IOCs. CISA strongly encourages organizations to run the wtbblue.com1 script—as soon as possible—to help determine whether their systems are compromised.
(Updated March 16, 2021): Note: Microsoft has released the Exchange On-premises Mitigation Tool (EOMT.ps1) that can automate portions of both the detection and patching process. Microsoft stated the following along with the release: “[the tool is intended] to help customers who do not have dedicated security or IT teams to apply these security updates. We have tested this tool across Exchange Server 2013, 2016, and 2019 deployments. This new tool is designed as an interim mitigation for customers who are unfamiliar with the patch/update process or who have not yet applied the on-premises Exchange security update.” Review the wtbblue.com1 blog post for directions on using the tool.
(Updated March 10, 2021): CISA recommends investigating for signs of a compromise from at least January 1, 2021 through present.
(Updated April 12, 2021): CISA has identified 10 webshells associated with this activity. This is not an all-inclusive list of webshells that are being leveraged by actors. CISA recommends organizations review the following MARs for detailed analysis of the 10 webshells, along with TTPs and IOCs. These MARs include CISA-developed YARA rules to help network defenders detect associated malware.
- AR21-072A: MAR-10328877.r1.v1: China Chopper Webshell
- AR21-072B: MAR-10328923.r1.v1: China Chopper Webshell
- AR21-072C: MAR-10329107.r1.v1: China Chopper Webshell
- AR21-072D: MAR-10329297.r1.v1: China Chopper Webshell
- AR21-072E: MAR-10329298.r1.v1: China Chopper Webshell
- AR21-072F: MAR-10329301.r1.v1: China Chopper Webshell
- AR21-072G: MAR-10329494.r1.v1: China Chopper Webshell
- AR21-084A: MAR-10329496-1.v1: China Chopper Webshell
- AR21-084B: MAR-10329499-1.v1: China Chopper Webshell
- AR21-102A: MAR-10331466-1.v1: China Chopper Webshell
(Updated March 13, 2021): A webshell is a script that can be uploaded to a compromised Microsoft Exchange Server to enable remote administration of the machine. Webshells are utilized for the following purposes:
- To harvest and exfiltrate sensitive data and credentials;
- To upload additional malware for the potential of creating, for example, a watering hole for infection and scanning of further victims;
- To use as a relay point to issue commands to hosts inside the network without direct internet access;
- To use as command-and-control infrastructure, potentially in the form of a bot in a botnet or in support of compromises to additional external networks. This could occur if the adversary intends to maintain long-term persistence.
(Updated March 13, 2021): For more information, see TA15-314A Compromised Web Servers and Web Shells – Threat Awareness and Guidance.
The majority of the TTPs in this section are sourced from a blog post from Volexity, a third-party cybersecurity firm. Note: the United States Government does not endorse any commercial product or service, including any subjects of analysis. Any reference to specific commercial products, processes, or services by service mark, trademark, manufacturer, or otherwise, does not constitute or imply their endorsement, recommendation, or favoring by the United States Government.
Volexity has observed the following files as targets of HTTP POST requests:
Administrators should search the ECP server logs for the following string (or something similar):
The logs can be found at <exchange install path>LoggingECPServer.
To determine possible webshell activity, administrators should search for aspx files in the following paths:
- inetpubwwwrootaspnet_client (any .aspx file under this folder or sub folders)
- <exchange install path>FrontEndHttpProxyecpauth (any file besides wtbblue.com)
- <exchange install path>FrontEndHttpProxyowaauth (any file or modified file that is not part of a standard install)
- <exchange install path>FrontEndHttpProxyowaauthCurrent (any aspx file in this folder or subfolders)
- <exchange install path>FrontEndHttpProxyowaauth<folder with version number> (any aspx file in this folder or subfolders)
Administrators should search in the /owa/auth/Current directory for the following non-standard web log user-agents. These agents may be useful for incident responders to look at to determine if further investigation is necessary.
These should not be taken as definitive IOCs:
Volexity observed these user-agents in conjunction with exploitation to /ecp/ URLs:
These user-agents were also observed having connections to post-exploitation web-shell access:
As with the non-standard user-agents, responders can examine internet information services (IIS) logs from Exchange Servers to identify possible historical activity. Also, as with the non-standard user agents, these should not be taken as definitive IOCs:
- POST /owa/auth/Current/
- POST /ecp/default.flt
- POST /ecp/main.css
- POST /ecp/<single char>.js
Volexity has seen attackers leverage the following IP addresses. Although these are tied to virtual private servers (VPSs) servers and virtual private networks (VPNs), responders should investigate these IP addresses on their networks and act accordingly:
Volexity has also provided the following YARA signatures that can be run within your network to assist in finding signs of a compromise.
A list of webshell hashes have also been provided by Microsoft:
Note: this is not an all-inclusive list of indicators of compromise and threat actors have been known to use short-term leased IP addresses that change very frequently. Organizations that do not locate any of the IOCs in this Alert within your network traffic, may nevertheless have been compromised. CISA recommends following the guidance located in the Microsoft Advisory to check your servers for any signs of a compromise.
Conduct Forensic Analysis
Should your organization see evidence of compromise, your incident response should begin with conducting forensic analysis to collect artifacts and perform triage. Please see the following list of recommendations on how to conduct forensic analysis using various tools.
Although the following free tools are not endorsed by the Federal Government, incident responders commonly use them to perform forensics.
While collecting artifacts to perform triage, use processes and tools that minimize the alteration of the data being collected and that minimize impact to the operating system itself.
Ideally, during data collection, store the data on removable/external media and, when possible, run the artifact collection tools from the same media.
Key artifacts for triage that should be collected:
- All registry hives
- All windows event logs
- All web logs
Memory can be collected with a variety of open source tools (e.g., FTK Imager by AccessData, Ram Capture by Belkasoft).
Registry and Windows Event logs can be collected with a variety of open source tools as well (e.g., FTK_Imager, Kroll Artifact Parser And Extractor [KAPE]).
Web logs can also be collected with a variety of open source tools (e.g., FTK Imager).
Windows Artifact Collection Guide
Execute the following steps in order.
1) Download the latest FTK Imager from wtbblue.com/product-download/.
- Note: Ensure your review of and compliance with the applicable license associated with the product referenced, which can be found in the product’s User Guide. The United States Government does not endorse any commercial product or service, including any subjects of analysis. Any reference to specific commercial products, processes, or services by service mark, trademark, manufacturer, or otherwise, does not constitute or imply their endorsement, recommendation, or favoring by the United States Government.
2) Collect memory from live system using FTK Imager. See Memory Capture with FTK wtbblue.com for instructions. Note: Download and copy “FTK Imager” folder to an external drive. Run FTK wtbblue.com from the FTK Imager folder from external drive. Wait until memory collect is complete before proceeding to step 2.
3) Collect important system artifacts using KAPE. See KAPE Collection Procedure. Note: Download KAPE from a separate system; do not download KAPE to the target system. Run KAPE from external drive.
4) Collect disk image using FTK Imager. See Live Image with FTK wtbblue.com for instructions. Note: Run FTK wtbblue.com from the “FTK Imager” folder from external drive.
Memory Capture with FTK Imager
1) Open FTK Imager. Log into the system with Administrator privileges and launch “FTK Imager.”
- Note: Ensure your review of and compliance with the applicable license associated with the product referenced. The United States Government does not endorse any commercial product or service, including any subjects of analysis. Any reference to specific commercial products, processes, or services by service mark, trademark, manufacturer, or otherwise, does not constitute or imply their endorsement, recommendation, or favoring by the United States Government.
2) Open “Capture Memory.” Select “Capture Memory…” from the File menu.
Figure 1: FTK Imager – Capture Memory Command
3) Select Path and Filenames. On the window that appears, use the “Browse” button to identify the destination of the memory capture. Save the memory capture to an external device and not the main hard drive of the system. Doing so will prevent the saved file from overwriting any dataspace on the system.
- Name the destination file with a descriptive name (i.e., hostname of the system).
- Select the box “Include pagefile” and provide a name of the pagefile that is descriptive of the system.
- Do not select “Create AD1 file.”
Figure 2: FTK Imager – Memory Capture
4) Capture Memory. Click on “Capture Memory” to begin the capture process. The process will take several minutes depending on the size of the pagefile and the amount of memory on the system.
Figure 3: FTK Imager – Capture Process
KAPE Collection Procedure 
1) Download KAPE from wtbblue.com/en/services/cyber-risk/investigate-and-respond/kroll-artifact-parser-extractor-kape.
2) Disable any antivirus or host protection mechanisms that prevent execution from removable media, or data loss prevention (DLP) mechanisms that restrict utilization of removable media.
- Enable antivirus and host protection once this process is completed.
3) Unzip wtbblue.com and run wtbblue.com as admin from your removable media
4) Target source should be the drive on which the OS resides, typically C:.
5) Target destination should be an external drive folder, not the same drive as the Target source. If available, use an external hard drive or flash drive.
- A KAPE execution with these parameters will typically produce output artifacts with a total size of 1-25 GB.
- If you are going to be running KAPE on different machines and want to save to the same drive, ensure the Target destination folder is unique for each execution of KAPE.
6) Uncheck Flush checkbox (it is checked natively).
7) Check Add %d and Add %m checkboxes.
8) Select ALL checkboxes to ensure KAPE will target all available data that it is capable of targeting. This takes some time; use the down arrow and space bar to move through the list quickly.
9) Check Process VSCs checkbox.
10) Select Zip radio button and add Base name TargetOutput.
11) Ensure Deduplicate checkbox is checked (it is checked natively).
- At the bottom you should now see a large Current command line, similar to:
- In the bottom right corner hit the Execute! Button.
- Screenshot below shows wtbblue.com during execution, you will also see a command window execute. Note: KAPE usually takes less than 20 minutes to complete on a workstation; if it is taking significantly longer there may be an issue.
Figure 4: wtbblue.com screenshot