OWASSRF: New Exploit Method for Exchange Bypassing ProxyNotShell Mitigations

  • Home
  • OWASSRF: New Exploit Method for Exchange Bypassing ProxyNotShell Mitigations
OWASSRF: New Exploit Method for Exchange Bypassing ProxyNotShell Mitigations
OWASSRF: New Exploit Method for Exchange Bypassing ProxyNotShell Mitigations
OWASSRF: New Exploit Method for Exchange Bypassing ProxyNotShell Mitigations
OWASSRF: New Exploit Method for Exchange Bypassing ProxyNotShell Mitigations
OWASSRF: New Exploit Method for Exchange Bypassing ProxyNotShell Mitigations

A recent publication demonstrated that several Play ransomware intrusions seem to have been caused by the Microsoft Exchange ProxyNotShell vulnerabilities CVE-2022-41040 and CVE-2022-41082. In each instance, the relevant logs and ruled there was no evidence of the exploitation of CVE-2022-41040 for initial access.

Instead, it appears that the PoC was made directly through Outlook Web Application (OWA), indicating a previously undisclosed attack technique for Exchange.

ProxyNotShell and Exchange Architecture Primer

A Microsoft Exchange server consists of two major components: the frontend, also known as the Client Access Service, and the backend. The frontend handles all client connections, and proxies any given request to the appropriate backend service. The backend processes are responsible for handling specific requests made to the frontend such as URLs, also known as endpoints.

OWASSRF_Terraeagle

It is accessed using a URL redirection mix-up, CVE-2022-41040, by the attacker to enable access to the server for arbitrary URLs. This type of vulnerability is called server-side request forgery (SSRF). In the case of ProxyNotShell, the targeted backend service is PowerShell, the Remote service.

Terraeagle incident handlers discovered that the renamed Plink and AnyDesk executable creation timestamps on affected backend Exchange Servers were closely correlated with the Remote PowerShell execution timestamps in the affected servers’ configuration (Remote PowerShell Event Summary log), suggesting that the threat actor leveraged the newly discovered exploit chain to at least drop other persistent tools for access to the affected Exchange Servers.

The threat actor cleared Windows Event Logs on backend Exchange servers so information would not become accessible regarding the PowerShell commands leveraged by the threat actors. When researchers later reproduced the attack, events were present in PowerShell event logs for the creation of an arbitrary process from PowerShell.

Threat Actor POC Leak

Reports indicate that researchers were working to produce a proof-of-concept (POC) code for an exploit method indicative of the logging traffic present after recent Play ransomware attacks. At the same time, a security researcher found that an employee was copying code through an open repository, downloaded all the tools, and made them available through a MegaUpload link in a Twitter post.

OWASSRF_Terraeagle

Researchers studied how the November 8, 2022 patch KB5019758 impacted executions on Untangle that had not yet received the update, but could not replicate this study on Exchange systems that had received this patch. There were two privilege escalation vulnerabilities corrected in the patch. 

The first, CVE-2022-41123, discovered by ZDI, shows that DLL hijacking is occurring because of loading a package file by a privileged command. The second, CVE-2022-41080 has not been public yet but its CVSS score of 8.8 is the same as CVE-2022-41040 used in the ProxyNotShell exploit chain, and the fact that it is exploitation most likely suggests that it is as well.

OWASSRF_Terraeagle

Terraeagle Recommendations:

  • Organizations should install the Exchange add-on by November 8, 2022, since the patch’s URL rewrite mitigations in this area do not function against this exploit method.
  • If the patch KB5019758 has not become available for Windows 10, you should disconnect OWA until you can allow that.
  • Be sure to disable non-administrative users’ PowerShell remote access according to Microsoft’s recommendations.
  • Implement rigorous endpoint detection and response (EDR) solutions on every endpoint.
  • While considering application-level controls, such as firewalls for web applications, as well as system-level controls.
  • In HTTP requests with an X-Forwarded-For header, ensure that the IP address of the external proxy server is located in the log.

Found this article interesting? Follow Terraeagle on Facebook, Twitter and LinkedIn to read more exclusive content we post.

Leave a Reply

Your email address will not be published. Required fields are marked *