OWASSRF: CrowdStrike Identifies New Exploit Method for Exchange Bypassing ProxyNotShell Mitigations

December 20, 2022

From The Front Lines
  • CrowdStrike recently discovered a new exploit method (called OWASSRF) consisting of CVE-2022-41080 and CVE-2022-41082 to achieve remote code execution (RCE) through Outlook Web Access (OWA). The new exploit method bypasses URL rewrite mitigations for the Autodiscover endpoint provided by Microsoft in response to ProxyNotShell.
  • The discovery was part of recent CrowdStrike Services investigations into several Play ransomware intrusions where the common entry vector was confirmed to be Microsoft Exchange.
  • After initial access via this new exploit method, the threat actor leveraged legitimate Plink and AnyDesk executables to maintain access, and performed anti-forensics techniques on the Microsoft Exchange server in an attempt to hide their activity.

CrowdStrike Services recently investigated several Play ransomware intrusions where the common entry vector was suspected to be the Microsoft Exchange ProxyNotShell vulnerabilities CVE-2022-41040 and CVE-2022-41082. In each case, CrowdStrike reviewed the relevant logs and determined there was no evidence of exploitation of CVE-2022-41040 for initial access. Instead, it appeared that corresponding requests were made directly through the Outlook Web Application (OWA) endpoint, indicating a previously undisclosed exploit method for Exchange.

ProxyNotShell and Exchange Architecture Primer

A Microsoft Exchange server is composed of two major components: the frontend, also known as the Client Access Service, and the backend. The frontend is responsible for handling all client connections and for proxying any given request to the appropriate backend service. The backend services are responsible for handling specific requests made to the frontend such as URLs, also known as endpoints. A simplified Exchange 2016 architecture is illustrated in Figure 1.

Figure 1. Simplified architecture of a 2016 Microsoft Exchange Server1 (click to enlarge)

In the case of a traditional ProxyNotShell exploit chain, the attack sequence is done in two steps:

First, the Autodiscover endpoint, used for informing clients about services offered by the remote Microsoft Exchange server, is accessed using an authenticated request to the frontend. It is accessed using a path confusion exploit, CVE-2022-41040, allowing the attacker to reach the backend for arbitrary URLs. This type of vulnerability is known as a server-side request forgery (SSRF). In the case of ProxyNotShell, the targeted backend service is the Remote PowerShell  service. 

A typical web request to the frontend to exploit the SSRF vulnerability on CVE-2022-41040 involves some variation of path confusion that references the Autodiscover endpoint as shown below:

The backend request for a typical ProxyNotShell exploitation is shown below:

Once the PowerShell remoting service can be reached, the second step involves vulnerability CVE-2022-41082 being exploited in order to execute arbitrary commands. A typical log entry showing access to the PowerShell backend is detailed in the Remote PowerShell HTTP logs, located in C:\Program Files\Microsoft\Exchange Server\V15\Logging\CmdletInfra\Powershell-Proxy\Http\, such as in the example below:

New Exploit Method Discovery

CrowdStrike incident responders discovered Remote PowerShell logs similar to log entries for ProxyNotShell exploitation to gain initial access, suggesting the attacker leveraged Remote PowerShell. An example of these log entries can be found below:

By correlating the user, IP address and cafeReqId GUID from the Remote PowerShell HTTP logs to the Exchange frontend, CrowdStrike found a POST request using the mastermailbox@outlook.com mailbox to the following OWA URL, https://{exchange_host}/owa/{email_address]/powershell, corresponding to the IIS log entry below:

The backend request for the new exploitation chain is similar to the example shown below:

This request seemed to show a novel, previously undocumented, way to reach the PowerShell remoting service through the OWA frontend endpoint, instead of leveraging the Autodiscover endpoint.

CrowdStrike incident responders found that renamed Plink and AnyDesk executable creation timestamps on affected backend Exchange servers were closely correlated with PowerShell execution events in the Remote PowerShell logs, indicating the threat actor leveraged the newly discovered exploit chain to drop other tooling for persistent access to the affected Exchange servers. The threat actor cleared Windows Event Logs on affected backend Exchange servers so further information was not available regarding the PowerShell commands leveraged by the threat actors. When CrowdStrike 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

CrowdStrike security researchers were working to develop proof-of-concept (POC) code for an exploit method indicative of the logging present after recent Play ransomware attacks. Simultaneously, a threat researcher outside of CrowdStrike discovered an attacker’s tooling via an open repository, downloaded all of the tools, and made them available through a MegaUpload link in a Twitter post.2 The leaked tooling included a Python script, poc.py, that when executed led CrowdStrike researchers to replicate the logs generated in recent Play ransomware attacks.

The code works in two steps. The first step is the previously unknown OWA exploit technique, as seen in the snippet of the threat actor exploit code in Figure 2.

Figure 2. Excerpt of threat actor’s tooling leveraging the OWA technique (click to enlarge)

This first step provides a SSRF equivalent to the Autodiscover technique used in ProxyNotShell exploitation. The second step is simply the same exploit used in the second step of ProxyNotShell, allowing code execution through PowerShell remoting.

CrowdStrike researchers replicated the exploit method attack on Exchange systems that had not received the November 8, 2022 patch KB5019758, but could not replicate the attack on systems that had received that patch. There were two (2) privilege escalation vulnerabilities corrected in the patch. The first, CVE-2022-41123, has been revealed by ZDI to be DLL hijacking3 due to the loading of a non-existent component by a privileged executed command. The second, CVE-2022-41080, has not been publicly detailed but its CVSS score of 8.8 is the same as CVE-2022-41040 used in the ProxyNotShell exploit chain, and it has been marked “exploitation more likely.” Based on these findings, CrowdStrike assesses it is highly likely that the OWA technique employed is in fact tied to CVE-2022-41080.

The difference between ProxyNotShell and the newly discovered exploit method we are calling OWASSRF is highlighted in Figure 3.

Figure 3. Difference between ProxyNotShell and the new OWASSRF exploit method (click to enlarge)

New Exploit Method Bypasses Microsoft Mitigations for ProxyNotShell

To prevent ProxyNotShell exploitation on older Microsoft Exchange servers, Microsoft released a blog4 advocating for a custom rewrite rule inside the Microsoft IIS server supporting Exchange. This rule was designed to match the decoded URI of any incoming request with the regex (?=.*autodiscover)(?=.*powershell), so when the decoded URI matches this regex, the request is dropped. For newer on-premises servers, Microsoft provided the same rule through the Exchange Emergency Mitigation Service,5 which installs it automatically. The regex, and thus the rule, will match only the requests made to the Autodiscover endpoint of the Microsoft Exchange server. In the case of the exploit method described here as OWASSRF, the Autodiscover endpoint is not used, in lieu, and the request will not be dropped.

CrowdStrike Recommendations

  • Organizations should apply the November 8, 2022 patches for Exchange to prevent exploitation since the URL rewrite mitigations for ProxyNotShell are not effective against this exploit method. 
  • If you cannot apply the KB5019758 patch immediately, you should disable OWA until the patch can be applied.
  • Follow Microsoft recommendations to disable remote PowerShell for non-administrative users where possible. 
  • Deploy advanced endpoint detection and response (EDR) tools to all endpoints to detect web services spawning PowerShell or command line processes. CrowdStrike Falcon will detect the OWASSRF exploit method described in this blog, and will block the method if the prevention setting for Execution Blocking > Suspicious Processes is applied.
  • Monitor Exchange servers for signs of exploitation visible in IIS and Remote PowerShell logs using this script developed by CrowdStrike Services.
  • Consider application-level controls such as web application firewalls.
  • Ensure X-Forwarded-For header is configured to log true external IP addresses for request to proxied services.

Additional Resources

Endnotes

  1. https://learn.microsoft.com/en-us/exchange/architecture/architecture?view=exchserver-2019
  2. https://twitter.com/Purp1eW0lf/status/1602989967776808961?s=20
  3. https://attack.mitre.org/techniques/T1574/001/
  4. https://msrc-blog.microsoft.com/2022/09/29/customer-guidance-for-reported-zero-day-vulnerabilities-in-microsoft-exchange-server/
  5. https://learn.microsoft.com/en-us/exchange/exchange-emergency-mitigation-service?view=exchserver-2019
Related Content
CrowdStrike Services Offers Incident Response Executive Preparation Checklist
Business as Usual: Falcon Complete MDR Thwarts Novel VANGUARD PANDA (Volt Typhoon) Tradecraft
Discovering the MOVEit Vulnerability with the CrowdStrike Falcon Platform