Microsoft mitigation for new Exchange Server zero-day exploits can be bypassed

No permanent fix for the Exchange Server vulnerabilities is yet available, but other steps can mitigate the risk.

There are currently two unpatched vulnerabilities that are being used to hack on-premises Microsoft Exchange systems remotely. The vulnerabilities were acknowledged by Microsoft late last week, and mitigation advice was given until a full fix could be prepared. However, it has been reported that the proposed mitigation can be readily circumvented.

In early August, a Vietnamese security firm called GTSC found the new vulnerabilities while conducting security monitoring and incident response for a client whose systems had been compromised. As the malicious queries in the server logs resembled those of a ProxyShell exploit, the GTSC team at first suspected that they were dealing with one. ProxyShell is a layered attack that exploits three previously patched vulnerabilities in Microsoft Exchange.

The incident response team, however, soon determined that this was not ProxyShell because the compromised Exchange servers from which the attackers had gotten remote code execution capabilities were up to date. After discovering zero-day vulnerabilities through reverse engineering, the team reported them to Trend Micro’s Zero Day Initiative (ZDI) program, where analysts verified the findings and informed Microsoft.

The new attack exploits two vulnerabilities

There are two new vulnerabilities in this attack chain, which Microsoft has assigned the numbers CVE-2022-41040 and CVE-2022-41082. One is a server-side request forgery (SSRF) flaw that can be exploited by a trusted user to gain access to the other vulnerability. As a result, PowerShell scripts can be run remotely. While Microsoft Exchange Online already has protections in place, the on-premises versions of Exchange 2013, 2016, and 2019 are vulnerable. Microsoft (advisory) said that “authenticated access to the vulnerable Exchange Server is necessary” to exploit either flaw.

By using this vulnerability, attackers were able to spread web shells, or backdoor programs, to several clients, using the guise of seemingly genuine Exchange files like RedirSuiteServiceProxy.aspx, as seen by GTSC. After compromising the servers, they used malware capable of dumping credentials to steal them. The experts believe the attackers are Chinese based on the web shells used and other traces left behind.

Cisco Talos found that the attackers employed Antsword, a popular open-source online shell written in Chinese, SharPyShell, a web shell written in ASP.NET, and China Chopper. They are also using the legitimate tool certutil to distribute implants, which is a security Risk

Microsoft’s mitigation for the Exchange Server zero-days can be bypassed

Microsoft recommends utilizing the URL Rewrite engine found in “IIS Manager -> Default Web Site -> URL Rewrite -> Actions” to prevent common attack vectors. Both a blocking rule and a PowerShell script to automate its rollout were supplied by the company.

One Vietnamese security researcher who goes under the Twitter handle Janggggg did point out on Monday, however, that there is a simple way to avoid the restriction. Other security experts, such as the now-retired CERT/CC analyst Will Dormann, have corroborated this finding:

“The ‘@’ in the Microsoft-recommended “.*autodiscover\.json.*\@.*Powershell.*” URL block mitigations for CVE-2022-41040 CVE-2022-41082 seems unnecessarily precise, and therefore insufficient. Probably try “.*autodiscover\.json.*Powershell.*” instead.”

Without access to PowerShell from a compromised account, this attack is useless, hence Microsoft recommends that businesses prohibit remote PowerShell access for non-admin users in addition to this blocking rule. Unfortunately, that doesn’t protect admin users, but once they’re compromised, the attackers have a significant amount of latitude.

Microsoft provides instructions on how to disable remote PowerShell access for users in a separate article as well as detection and threat hunting guidance for the currently observed attacks. The GTSC and Talos reports also contain indicators of compromise.

Microsoft has published detection and threat hunting recommendations for the recently detected attacks, as well as instructions on how to disable remote PowerShell access for users. Indicators of compromise can also be seen in the GTSC and Talos reports.

Organizations and units can refer to below analysis article. In this article, we will include some more signs to identify attacks to check for themselves in the organization’s Mail Exchange system.

Signs of detection

IIS log:

Check the access to the path /ecp/<single char>.js. returns a response code of 200 . We detected 3 files of the form x.js, y.js, z.js through the log. User-Agent is ExchangeServicesClient/0.0.0.0 and Python-requests/2.22.0

Exchange ECP log

The RCE vulnerability is related to the set-OabVirtualDirectory ExchangePowershell cmdlet. Check in the HttpProxy log located in the Exchange ECP log (the folder containing the Exchange log: c:Program FilesMicrosoftExchange Server{Version}Logging) with the log access url: /ecp/DDIService.svc/SetObject with schema parameters OABVirtualDirectory and ResetOABVirtualDirectory, can add UserAgent as python-requests.

Webshell/Malware Path:

We detect webshells located at the following paths

\inetpub\wwwroot\aspnet_client\system_web\

\inetpub\wwwroot\aspnet_client\

In addition, it is necessary to perform a webshell check in the Exchange path such as:

%ProgramFiles%\Microsoft\Exchange Server\<version>\ClientAccess %ProgramFiles%\Microsoft\Exchange Server\<version>\FrontEnd

Pay attention to check the webshell as dll in the bin directory, for example:

\Program Files\Microsoft\Exchange Server\<Version>\ClientAccess\owa\bin hoặc \Program Files\Microsoft\Exchange Server\<Version>\FrontEnd\HttpProxy\owa\bin …

The malicious DLL is located at the following paths:

C:\\Windows\Microsoft.Net\FrameWork\sbs_clrhost.dll
C:\Program Files\Common Files\microsoft shared\WMI\iiswmi.dll
C:\Program Files\Common Files\System\websvc.dll
C:\\Windows\Microsoft.Net\FrameWork64\\v4.030319\Util.config
C:\\Windows\Microsoft.Net\FrameWork64\version.dll

Name of the webshell:

Aspnet_client.aspx

Errorv.aspx

Access.aspx

Hashes

Webshell hashes

286F877DAD9E7CECC69A0FA30DE582DE910A1E6E C3FA8F4B7A2D84E1A54A2DC973985C76652BBCF2

DLL hashes

3ED18FBE06D6EF2C8332DB70A3221A00F7251D55

C8675C1578D3FDD22CBB0F64340258BCFDD5743F 3399681CFD6F7F2A270D9A543021ED9B93E85675

1EE063A2B7B29334E7388B621AE8B37DD2488210

Network

Note the following relevant IPs in which IP 167.99.168.251 has also been mentioned in other articles

167.99.168.251

185.220.101.204

162.247.72.199

194.156.98.191

202.182.100.134

109.70.100.55

185.220.101.18

193.36.119.144

After successfully exploiting the vulnerability, the attacker deploys webshell on the compromised server. An example of webshells we collected:

Perform write file:

Compile and execute the required class and method:

After obtaining the webshell, we detected that the following DLLs were dropped. iisvmi.dll(x64) this DLL will be run as a service named ExchangeSvc. The task of this DLL drops out another DLL named websvc.dll. Dll websvc.dll receives the parameter as the string base64, with the string base64 as the parameter passed from iisvmi.dll stored on the registry. websvc.dll will decrypt the base64, xor strings with 63, decompress gzip to get a new DLL.DLL which will load directly on memory. Analyzing malicious code samples in detail, we would like to update to another article.