Microsoft Exchange ProxyNotShell vulnerability explained and how to mitigate it

Last year, two high severity, easily exploitable Microsoft Exchange vulnerabilities dubbed ProxyLogon and ProxyShell made waves in the infosec sphere. Nearly a year later, Exchange Server admins are met with another threat: ProxyNotShell, which in fact is a vulnerability chain comprising two actively exploited flaws:

• CVE-2022-41040 is a server-side request forgery (SSRF) vulnerability that an authenticated attacker can exploit for privilege escalation. This vulnerability occurs because the root cause of ProxyShell’s path confusion flaw remains, as explained further below.
• CVE-2022-41082 is a deserialization flaw that can be abused to achieve remote code execution (RCE) in Exchange’s PowerShell backend once it becomes accessible to the attacker. 

Both vulnerabilities impact Microsoft Exchange Server on-premises and hybrid setups running Exchange versions 2013, 2016, and 2019 with an internet-exposed Outlook Web App (OWA) component.

Although an attacker must be authenticated prior to exploiting these flaws, the low degree of complexity required for exploitation, and the potentially damaging impact to confidentiality, availability, and integrity of systems, are reasons for these vulnerabilities to be rated high in severity. In fact, earlier reports suggested that threat actors had leveraged this zero-day vulnerability chain to deploy China Chopper web shells on hacked servers to obtain persistent access and steal sensitive data.

In an ideal ProxyNotShell attack scenario, an authenticated attacker would first exploit the SSRF vulnerability to gain access to Exchange’s PowerShell backend. By then exploiting CVE-2022-41082, they would be able to remotely execute code on a vulnerable Exchange server.

At the time of writing, more than 197,000 unpatched, exposed Exchange Outlook Web App (OWA) servers were on the internet, according to the Shodan.io report below, making the attack surface for Exchange vulnerabilities widespread.

Ax Sharma

An actively exploited zero-day with insufficient mitigations

In early August, Vietnamese cybersecurity incident response and SOC firm GTSC observed the exploitation of a critical system running Exchange Server in one of its client environments. Upon investigation, GTSC determined that the exploit involved a Microsoft Exchange payload. In particular, the payload spotted by the firm’s SOC analysts in IIS server logs was in the format: autodiscover/autodiscover.json?@evil.com/&Email=autodiscover/autodiscover.json%3f@evil.com Interestingly, attack payload for exploiting the previously discovered ProxyShell vulnerability also comprises an identical string, i.e. “…/autodiscover/autodiscover.json.” To the analysts’ surprise, however, the hijacked Exchange Server in question had been running a version that’s patched against ProxyShell, making this attack unlikely to be connected to ProxyShell. Upon further investigation, the analysts deemed this attack resulting from a separate zero-day vulnerability, which was later named ProxyNotShell.

After responsibly reporting the flaw to Microsoft via Zero Day Initiative (ZDI), the firm published its findings in late September. To prevent misuse by adversaries, the disclosure lacks deeper technical details of the exploit.

Understanding ProxyNotShell in ProxyShell context

ProxyNotShell’s active exploitation, not to mention the choice of its moniker that contrasts with ProxyShell, is bound to pique your curiosity and leave you with questions. After all, ransomware groups including Conti have been seen exploiting ProxyShell to conduct their attacks. One may ask, is ProxyNotShell nearly as dangerous?

ProxyShell refers to a set of three different vulnerabilities chained together in an attack:

• CVE-2021-34473 is a path confusion vulnerability that lets an unauthenticated attacker bypass access control. In fact, an insufficient fix for the root cause of the vulnerability is what makes CVE-2022-41040 (the first one of the ProxyNotShell vulnerabilities) possible.

• CVE-2021-34523 is a privilege escalation vulnerability impacting Exchange PowerShell. After exploiting CVE-2021-34473, the threat actor can gain elevated privileges by exploiting this flaw.
• CVE-2021-31207 is an RCE via file write vulnerability. Discovered by researcher Orange Tsai during the 2021 Pwn2Own contest, the vulnerability exploitation requires the attacker to be authenticated and possess high privileges.

Therefore, a stark similarity between ProxyShell and ProxyNotShell, other than their attack chains comprising vulnerabilities of similar stature, is the presence of the autodiscover string in the exploit payload for both threats:

/autodiscover/autodiscover.json?...

When using Outlook Web App in the browser and opening a new mailbox or calendar window, the URL in your address bar looks something like (notice your email address in the URL):

https://example.com/OWA/you@yourcompany.com/Default.aspx

To put it simply, an (authenticated) attacker with a valid email address could replace their email address with the autodiscover string and slightly modify the URL to look like:

https://example.com/autodiscover/autodiscover.json?@yourcompany.com/?&Email=autodiscover/autodiscover.json%3f@yourcompany.com

This would lead to path confusion in the Exchange Server (CVE-2021-34473). Instead of validating the email address, the server would now be able to access all backend URLs with the NT AUTHORITY/SYSTEM permissions—something a regular OWA user wouldn’t otherwise have access to. This would make it an entry point for the attacker to adjust their privileges (CVE-2021-34523) and ultimately launch a remote PowerShell instance for RCE (CVE-2021-31207).

Microsoft had earlier patched ProxyShell, but the key cause of path confusion issue was not entirely eliminated, giving rise to CVE-2022-41040.

“It turned out that the patch did not address the root cause of the vulnerability,” wrote vulnerability researcher Piotr Bazydło of Zero Day Initiative (ZDI) in a detailed analysis. “Post-patch, unauthenticated attackers are no longer able to exploit it due to the implemented access restrictions, but the root cause remains.”

The exploitation of ProxyShell vulnerability occurs only over port 443 (it used HTTPS/ secure connection), whereas with ProxyNotShell ports 5985 (HTTP) and 5986 (HTTPS) have also been targeted.

In summary, ProxyShell and ProxyNotShell are similar but not the same.

As for whether ProxyNotShell poses that same threat as ProxyShell in terms of real-world attacks, it appears so. In December, cloud computing provider Rackspace confirmed that a ransomware incident was to blame for its multi-day outage. Security researcher Kevin Beaumont suggested that the firm’s Exchange Servers were vulnerable to ProxyNotShell, alluding to the security gap being a potential cause of the attack.

Latest ProxyNotShell mitigation advice

Following public disclosure of the vulnerability, Microsoft publicly acknowledged the vulnerabilities and offered workarounds. Earlier reports suggested that ProxyNotShell exploited could be detected in your network environment and server logs by searching for presence of following string in IIS Logs:

Get-ChildItem -Recurse -Path -Filter "*.log" | Select-String -Pattern 'powershell.*autodiscover.json.*@.*200

Microsoft’s mitigations for ProxyNotShell changed constantly over the last few months as researchers kept uncovering ways that these workarounds could be bypassed. For example, Microsoft had earlier advised Exchange admins to block ports 5985 (HTTP) and 5986 (HTTPS) to deny attackers access to the Remote PowerShell component of Exchange, but the mitigation was later removed.

“The reason Microsoft decided to remove this mitigation was that researchers were able to show that this mitigation strategy is too specific and does not cover all the attack exploit methods,” explained security researcher Ofri Ouzan of cybersecurity firm Rezilion. Instead, the primary mitigation provided to admins was to add a URL rewrite rule in IIS Manager to block known attack patterns.

Ax Sharma

In September 2022, Microsoft released refined detection and remediation guidance for ProxyNotShell that advised relying on its Defender Antivirus and Defender for Endpoint product line for protection  It wasn’t until November, however, that a proper fix for ProxyNotShell was rolled out among November’s Patch Tuesday update set. Microsoft’s patches for the actively exploited zero-day arrived just in time considering proof-of-concept (PoC) exploits for the vulnerabilities had hit the internet by mid-November.

Because the previously suggested ProxyNotShell workarounds have fallen short or been bypassed, the best path forward with regards to squashing the flaw remains, applying the latest updates—specifically the November 2022 Security Updates if you are running Microsoft Exchange Server 2013, 2016, or 2019.