[German]We're likely to get security updates for on-premises Exchange Server (2016-2019) in a few hours that will hopefully close the two 0-day vulnerabilities (CVE-2022-41040, CVE-2022-41082) known since late September 2022. But there is likely another 0-day vulnerability in Exchange Server that is being actively exploited in the wild to infect installations with the LockBit 3.0 ransomware. Here is some information on what I am aware of.
Advertising
Last week, the vulnerability called NotProxyShell – due to the previously unpatched vulnerabilities (CVE-2022-41040, CVE-2022-41082) – yes kept administrators busy. I had reported extensively about this issue here in the blog (see links at the end of the article). But there is more lurking in Microsoft's Exchange Server software.
New 0-day vulnerability discovered
I just came across it on Twitter via the following tweet that there is another, new 0-day vulnerability in Exchange Server. This was discovered in June 2022 by AhnLab, a South Korean software company and market leader in antivirus programs in South Korea.
Their security researchers describe the find in the blog post From Exchange Server vulnerability to ransomware infection in just 7 days (written in Korean, but now deleted – the link points to the wayback machine with the cached copy). In July 2022, one of the vendor's customers was infected by ransomware. AhnLab then inspected two of the affected servers, which were running Windows Server 2016 Standard, and found LockBit 3.0 ransomware there. Here is a rough overview of the damage progression:
- A WebShell was installed on the infected systems running Windows Server 2016 using an Exchange Server vulnerability.
- This enabled an RDP connection via SSH tunneling
- Then information about the AD was retrieved via BloodHound
- Then information about AD administrator accounts was extracted using Mimikatz
The LockBit 3.0 ransomware was able to retrieve approximately 1.3 TB of data from the servers and then encrypted the files on those systems. AhnLabs writes that the WebShell upload was likely able to occur through a 0-day vulnerability. Multiple VPN IPs were used for the WebShell calls. All remote commands to control the LockBit3.0 ransomware infection were executed using Wmic.
Advertising
According to AhnLabs, it took only seven (7) days from the time the WebShell was uploaded to the time the AD administrator account was taken over and infected with ransomware. According to security researchers, the attacker is believed to be of Russian descent.
Some more details
The affected customer runs two mail servers for the email service and load balances the mail server connections to Mail01 and Mail02 by using the L4 switch in the front stage. Mail01 and Mail02 are Microsoft Exchange servers, and the IIS server is also used to provide the mail web service and mobile access.
On July 21, 2022, WebShell files were (presumably) uploaded to the OWA folder on Mail02. The WebShell files were later encrypted so that their contents could not be analyzed. In the IIS log, one of the two WebShell files was identified as HttpRedirService.aspx (which is why the security researchers assume a WebShell).
The customer had already been compromised by Microsoft Exchange Server vulnerabilities in December 2021. Since then, this customer received technical support from Microsoft and applied security patches quarterly (January, April, July). The latest patch at the time was update KB5014261, which was released on May 10, 2022 and installed by the customer on July 9. AhnLabs writes about this:
Looking at the Microsoft Exchange Server vulnerability history, the vulnerability related to remote code execution was disclosed on December 16, 2021 (CVE-2022-21969), the vulnerability related to privilege escalation was disclosed in February 2022, and the most recent vulnerability was disclosed on June 27.
That is, among the vulnerabilities disclosed after May, there were no reports of vulnerabilities related to remote commands or file creation
Since Exchange servers were fully patched on July 9, 2022, but WebShell was not installed until July 21, 2022, it is likely that the attacker exploited an undisclosed zero-day vulnerability. AhnLabs writes that there is a theoretical possibility that the Microsoft Exchange Server vulnerabilities (CVE-2022-41040, CVE-2022-41082) disclosed by Vietnamese security firm GTSC on September 28 were exploited for the infection. But the attack method, the generated WebShell filename, and subsequent attacks after WebShell installation suggest that another attacker exploited a different zero-day vulnerability.
Article series:
Exchange Servers are attacked via 0-day exploit (Sept. 29, 2022)
Microsoft's recommendations for Exchange Server 0-day vulnerability ZDI-CAN-18333
Update on Exchange Server 0-day Vulnerability ZDI-CAN-18333: Fixes, Scripts and EMS Solution
Exchange Server: Microsoft updates it's mitigation for the 0-day ProxyNotShell vulnerability (October 5, 2022)
Exchange Server: Microsofts improves solutions for 0-day mitigation again (October 8, 2022)
Similar articles:
Exchange Update errors and information (April 13, 2021)
Exchange isues with ECP/OWA search after installing security update (March 2021)
Exchange 2016/2019: Outlook problems due to AMSI integration
Exchange Server September 2021 CU comes Sept. 28 with Microsoft Exchange Emergency Mitigation Service
Exchange Server 2016-2019: Custom attributes in ECP no longer updatable after CU installation (July 2021)
Exchange Server 2013: Microsoft's tips on decommissioning the systems
Update for Exchange Extended Protection script, but still error
Tip: Exchange Health Checker – Script extensions by Frank Zöchling
