{"id":21487,"date":"2023-03-15T11:21:02","date_gmt":"2023-03-15T19:21:02","guid":{"rendered":"https:\/\/www.palada.net\/index.php\/2023\/03\/15\/news-15218\/"},"modified":"2023-03-15T11:21:02","modified_gmt":"2023-03-15T19:21:02","slug":"news-15218","status":"publish","type":"post","link":"http:\/\/www.palada.net\/index.php\/2023\/03\/15\/news-15218\/","title":{"rendered":"Observing OWASSRF Exchange Exploitation\u2026 still"},"content":{"rendered":"

Credit to Author: Angela Gunn| Date: Wed, 15 Mar 2023 16:45:56 +0000<\/strong><\/p>\n

\n

Late last year, Sophos X-Ops responded to exploitation of what appeared to be the ProxyNotShell attack flow, which targets Microsoft Exchange servers, and which Microsoft attempted to address in an early-November patch. That patch targeted two vulnerabilities, CVE-2022-41080 and CVE-2022-41082, which when attacked could result in remote code execution on vulnerable systems.<\/p>\n

Right before the December holidays, however, X-Ops\u2019 MDR team saw additional exploitation campaigns against Microsoft Exchange servers, leveraging (nearly) the same two vulnerabilities. This was followed by sustained activity in January, including attacks on high-profile entities such as RackSpace<\/a>, leading up to a law-enforcement takedown of the Hive network and its infrastructures. This network has been linked<\/a> in the past to the PLAY ransomware, which makes use of the OWASSRF technique associated with the two vulnerabilities. However, additional ransomware entities, such as Cuba, have also been seen making use of the flaw, and some reports suggest that PLAY shares infrastructure with yet other ransomware groups such as Quantum as well as the SVCReady and Emotet botnets.<\/p>\n

The situation was both tangled and active, and by the end of January, the US Cybersecurity and Infrastructure Security Agency (CISA) had taken the strong step of ordering<\/a> federal executive-branch agencies to apply the available patches, strongly recommending that other organizations do the same.<\/p>\n

This post details some of our observations and provides visibility into current indicators of compromise associated with the attacks.<\/p>\n

Prologue: CVE-2022-41040 and CVE-2022-41082<\/h3>\n

The two vulnerabilities in Microsoft Exchange Server that made ProxyNotShell possible were first publicly flagged<\/a> in October, though attacks in the wild were underway not later than midsummer of 2022. The attack based on the pair was dubbed \u201cProxyNotShell\u201d by the industry at large, for its similarity to the notorious ProxyShell attacks<\/a> of 2021 \u2013 in both cases, a server-side request forgery (SSRF) attack followed by remote code execution (RCE). In response, Microsoft released<\/a> first a hotfix, then a patch that provided URL Rewrite rule improvements.<\/p>\n

The Holiday Rush<\/h3>\n

Unfortunately, these improvements were swiftly bypassed by a technique dubbed \u201cOWASSRF\u201d by CrowdStrike<\/a> and LogPoint<\/a> researchers, among many others. It is an awkward but descriptive moniker: The OWASSRF technique once again chains two CVEs \u2013 CVE-2022-41080 allows an SSRF-like privilege escalation against an Outlook Web Access (OWA) endpoint, replacing CVE-2022-41040\u2019s SSRF against an AutoDiscover endpoint on an Exchange server; CVE-2022-41082 allows RCE as it did before — to achieve a ProxyShell \/ ProxyNotShell-style attack via OWA.<\/p>\n

On November 26, Sophos MDR Operations began responding to novel Microsoft Exchange exploitation efforts that resembled ProxyNotShell. The Sophos MDR team observed post-compromise activity in multiple unique environments. In all cases, the threat actor was evicted prior to successfully completing the attack. Unit 42 also reported eight incidents<\/a> with similar observations around that time.<\/p>\n

During December 2022, CrowdStrike published research<\/a> about a ProxyNotShell bypass identified during a PLAY ransomware incident. Unit42 also continued to report<\/a> multiple incidents with similar observations. In this timeframe, the MDR Operations team observed a variety of activities spawning from the IIS Worker Process (w3wp.exe) following successful exploitation with OWASSRF. This led to the execution of encoded PowerShell commands, reconnaissance via domain logging tools, usage of BITSAdmin for file transfers, attempted installation of dual-use agents, and enablement of remote connections.<\/p>\n

 <\/p>\n

\"Code<\/a><\/p>\n

Figure 1: A snippet of the threat actor\u2019s OWASSRF exploitation tooling (poc.py). Among other findings, we noted that the email address owa\/mastermailbox<at>outlook.com occurred in multiple POST requests made to the Exchange servers in question.<\/em><\/p>\n

As stated above, we saw encoded PowerShell commands spawning from w3wp. These encoded commands spawned child processes that performed the following actions:<\/p>\n