Microsoft Exchange Zero-Day Vulnerability Response
Last Updated: March 16, 2021
Microsoft and DHS CISA announced the confirmed exploitation of several vulnerabilities in Microsoft Exchange Server which have allowed adversaries to access email accounts, exfiltrate data, move laterally in victim environments, and install additional accesses and malware to allow long-term access to victim networks. The exploitation of these vulnerabilities is described as a zero-day (or 0day), which means they were targeted and acted upon prior to the vendor knowing that the vulnerabilities existed. In other words, there were zero days for the vendor to implement a fix for the vulnerability before it was used in an attack.
Patches are available and all organizations using Microsoft Exchange are encouraged to patch as soon as possible. However, patches will not remove accesses gained by adversaries or additional capabilities dropped in victim environments. Therefore, the MS-ISAC is recommending vigilance in investigating activity in your environment, looking for evidence of unauthorized access as described below, following the MS-ISAC playbook, and contacting the MS-ISAC SOC if you believe you were compromised. Additionally, new tools for detecting and mitigating compromise are available.
Who, What, When, Where
Microsoft detected multiple successful attacks against previously unknown vulnerabilities in Microsoft Exchange Server. These vulnerabilities are tracked as CVE-2021-26855, CVE-2021-26857, CVE-2021-26858, and CVE-2021-27065. Exchange Online is not affected.
Theses vulnerabilities are associated with an attack chain that allows an attacker to effectively inject code into resources used in the Exchange Offline Address Book (OAB) service.
Microsoft, DHS CISA, and the MS-ISAC strongly urge all customers who use Microsoft Exchange to update on-premises systems as soon as possible.
Microsoft Threat Intelligence Center (MSTIC) has attributed observed activity with high confidence to a group they have named HAFNIUM, which they assess to be state-sponsored and operating out of China. The U.S. Government has not confirmed attribution at this time.
In most cases observed so far, the attack unfolded in three phases. First was initial access, either via stolen credentials or exploitation of previously mentioned vulnerabilities. After gaining initial access, actors deployed web shells on the compromised server. A web shell is an interface that allows attackers to execute commands on the victim device over the Internet, and can be interacted with via a web browser. After successfully deploying a web shell, the actors would maintain access via U.S.-based private servers to take further actions, including downloading additional malware, stealing data, and moving around the victim’s network.
Victims are widespread and many. According to Brian Krebs, at least 30,000 organizations across the country, including a significant number of small businesses and SLTT organizations, have been affected.
Victims appear to be random, rather than targeted, as described in this article from Palo Alto's Unit 42.
For example, multiple MS Exchange OAB files have been observed with the same configurations but different modification times, and therefore unique hashes (aka file signatures). This signifies that not only is the same device compromised twice with the exact same webshell and associated key, but that the attackers are not likely checking to see if a system is already compromised during their scanning and exploitation process.
The MS-ISAC is currently working with members who have been impacted. We aim to support all SLTTs and ask for your patience as we work through this together.
DHS has stood up a landing page for remediation support related to these vulnerabilities.
Organizations that cannot immediately patch should follow Microsoft’s alternative mitigations recommendations.
In addition, DHS CISA is keeping their initial Activity Alert up-to-date with the latest technical details, including recently released Malware Analysis Reports (MARs), and recommendations for mitigation.
Microsoft has released a new “one-click” Microsoft Exchange on-premises mitigation tool, which is available for download for free, and easy to use for organizations of all maturity levels. While this tool will mitigate the issue, it will make changes in the environment in which it runs, and therefore may eliminate the ability to conduct further analysis.
The MS-ISAC recommends SLTTs use the following playbook:
Please note the following if you have already completed a rebuild of your exchange server and updated it with the most recent patches:
- As with all zero-day exploits, initial knowledge can be and is significantly limited and fluid as information frequently changes.
- Based on current industry knowledge of this exploit, a rebuild and updated patching are the best-known actions to take at this time.
- Current knowledge of indicators related to lateral movement or post compromise activity is limited; however, MS-ISAC has established a webpage dedicated to addressing the Microsoft Exchange zero day. The webpage will continue to be updated with the most recent information concerning the exploit. The webpage is https://www.cisecurity.org/ms-exchange-zero-day/
- CIRT will conduct an initial Incident Response (IR) call with you. The case status will initially be set as inactive due to lack of additional information; however, the case can be reactivated as new information develops.
- This will enable CIRT to focus additional assistance on members who may not possess the same resources to conduct rebuilds and patching of their Exchange environment.
- Data regarding the incident can still be provided to CIRT and preserved. It is recommended members preserve, if possible, exploit data as well.
- There has been a significant influx of cases related to this exploit. Our desire is to assist as many members as possible. We ask that you please continue to be patient as we work through these cases. We sincerely appreciate the understanding, which many of you have already expressed. Thank you.
- Please do not hesitate to ask additional follow up questions or reach out for help
- Investigate for Signs of Initial Compromise:
- Run the Microsoft script “Test-ProxyLogon.ps1” from the below link. This tool checks for exploitation attempts against the recent Exchange 0days.
- Search the following directories for unexpected “.aspx” files, as well as search within subdirectories. Common webshell names are provided in the Microsoft advisory. Should you find any webshells, please save a copy for our analysis prior to removal.
- Reference: https://www.microsoft.com/security/blog/2021/03/02/hafnium-targeting-exchange-servers/
- %IIS installation path%\aspnet_client\
- %IIS installation path%\aspnet_client\system_web\
- %Exchange Server installation path%\FrontEnd\HttpProxy\owa\auth\
- %Exchange Server Installation%\FrontEnd\HttpProxy\ecp\auth
- Utilize EOMT to scan for threats on the local exchange system (this will also attempt to clean any identified malware or webshells).
If no evidence of compromise is detected in Step 1 or the EOMT script is successful in mitigating identified threats, the system(s) should be fully updated in accordance with Microsoft’s guidance and can then be re-introduced into the environment.
If evidence is found and you would like to engage the MS-ISAC CIRT for IR assistance, please email the SOC with the request, and complete steps 2-4. Our CIRT will be in touch to inform you how to submit the results of your investigation from these steps.
If you do not require CIRT assistance, we recommend taking a forensic image to aid in your investigation before moving on to step 4.
- Isolate the system for investigation
- It is suggested that the system be disconnected from the network (but not shutoff) until an investigation determines the scope of the compromise.
- If you are unable to completely take the system off the network, at a minimum, disable public access to it over port HTTP/S. The initial exploitation and subsequent webshell access are done via this access.
- Gathering Data: (Please try to provide all the following items for CIRT to be able to assist you with the best service. A share link will be provided shortly following this email.)
- Utilize KAPE to gather forensics artifacts from the system.
- Download: https://cisecurity.sharefile.com/d-s290ea9e96a5b40fca7a430a6787d7a4f
- Simply download all the files in the above link, put them on the Exchange server/s of interest, and execute “kape.exe”. This should create a .zip file of artifacts for us to analyze within the directory KAPE was executed.
- Provide web server/IIS logs for OWA. Typically located at “C:\inetpub\logs\LogFiles\”, the last three months of logs should suffice.
- Provide the last three months of logs (if applicable) from the following directory: “%Exchange Server installation path%\Logging\CmdletInfra\Others\Cmdlet\*.log”
- Provide any network logs you may have from the time of the incident.
- Provide any AV/EDR/IDS alerts you may have that are related to the incident.
- Provide the output of the Microsoft “Test-ProxyLogon.ps1” script referenced in Step 1.
- Provide a copy of any webshells or other suspicious artifacts that you have identified.
- If possible, collect a memory capture and full disk image of the affected system using FTK Imager. Keep these stored somewhere that they can be uploaded should they be required for analysis. Please do not upload these two items to the MS-ISAC CIRT unless instructed to do so.
- Utilize KAPE to gather forensics artifacts from the system.
- Investigation of Post-Compromise:
- Check to see if “Administrator” has been removed from the “Exchange Organization administrators” group. (if applicable)
- Check for unexpected, recently created local users and/or domain users.
- Check for suspicious, recently created .zip, .rar. and .7z files within the “C:\ProgramData\” directory. It is suspected that malicious third parties have been storing compressed data here for data exfiltration.
- Look for suspicious, recently created files within the “C:\windows\temp\” and “C:\root\” directory. Especially suspicious would be any file with a .dmp extension, or have "lsass" in the name. It is suspected that malicious third parties have been storing LSASS dumps here.
- Monitor for unexpected activity on the network, such as:
- Unexpected user logins to systems or logins at strange times.
- AV/EDR/IDS within the environment that could indicate a compromise.
- Strange network activity, such as an influx in outbound traffic or unusual connections to/from the exchange system over non-SMTP ports that could indicate a reverse shell.
- Installed admin applications such as ProcDump or PSExec on systems that should not have them.
- Review local PowerShell event logs for suspicious command execution. Some examples:
- Unexpected downloads: “IEX (New-Object Net.WebClient).downloadstring(<SuspiciousDomain>)”
- Possible Unexpected mailbox export requests: “New-MailboxExportRequest” and “Get-MailboxExportRequest”
- Entries that appear to be making unauthorized connections to external IPs and domains.
- Reference to unauthorized tools/programs such as “powercat”.
- Conduct enterprise-wide AV scans looking for suspicious activity.
- It is strongly recommended that agencies prepare to restore the Exchange system from backup, if possible. Please do not restore the system from backup unless a full image capture has been taken or our analysis has been completed.
- Additional updated Microsoft Guidance as of 3/9 - https://raw.githubusercontent.com/Azure/Azure-Sentinel/master/Sample%20Data/Feeds/MSTICIoCs-ExchangeServerVulnerabilitiesDisclosedMarch2021.csv
- MS-ISAC page – Exchange Zero Day Vulnerability Response