Security Researcher: Ryan Cribelar
Date Last Updated: 9/7/2022

Dubbed ProxyNotShell by Kevin Beaumont, the two-chain pair of vulnerabilities affecting Microsoft Exchange servers 2019 and below exploiting the previously known ProxyShell vulnerability chain exists due to the fact that the barrier for exploitation was strictly a layer of authentication. Using the same SSRF/RCE pair, an authenticated attacker can leverage CVE-2022-41040 to execute code via CVE-2022-41082. The vulnerabilities were declared zero days due to the fact that the GTSC report as well as the Zero Day Initiative confirmed the findings worked on the latest patch of Exchange.

If users have implemented the URL string block observed in previous attempts to exploit ProxyShell, specifically “.*autodiscover\.json.*\@.*Powershell.*“, this should contain any potential external attempts to exploit the vulnerability chain. Steps to do so can be found in Microsoft’s report below. For any interested threat hunters, detection methods for Defender for Endpoint and Azure Sentinel can be utilized when triaging historical IIS logs.

GreyNoise has issued a blog detailing their findings regarding ProxyNotShell as well as more information surrounding their observed exploitation attempts.

Jared Semrau of Mandiant concludes that exploitation is likely to not be seen at mass-scale for these vulnerabilities as “this is a very specific attack vector that isn’t something that is going to be easily done at scale, especially now that workarounds are out there to prevent exploitation.”

As of 10/03/2022 it appears some users are reporting the above detection URL string can be bypassed to allow for successful exploitation. Nucleus recommends adding the string “.*autodiscover\.json.*Powershell.*” as a URL filter as well. Specifically, the ‘@’ character in the first string creates for too small of a detection pattern. You can find more details in this PoC video made by GTSC

As of 10/05/2022 a bypass to the mitigation for ProxyNotShell was discovered by user @honoki in which applying the URL filter input to “{REQUEST_URI}” is ineffective against encoded characters. It is recommended to change the input to “{UrlDecode:{REQUEST_URI}}” excluding quotes to mitigate the bypass.

Security Advisory:
msrc-blog.microsoft.com/2022/09/29/customer-guidance-for-reported-zero-day-vulnerabilities-in-microsoft-exchange-server