With the ever-changing developments on the ProxyNotShell Exchange Server vulnerability, I’d like to provide a high level overview covering the history of this exploit and the recommended mitigation steps to take.
A little history
First uncovered in September of 2022 by researchers at Vietnamese security firm GTSC Cyber Security, ProxyNotShell is an elevation of privilege (EoP) attack that is highly exploited in the wild. It is accomplished through a Server-Side Request Forgery (SSRF) CVE-2022-41040, and a remote code execution CVE-2022-41082 vulnerability. When these chain of attacks are successfully executed, an authenticated attacker could compromise an Exchange server via PowerShell.
To put it short, CVE-2022-41040 allows the breach, and CVE-2022-41082 provides the means to implant malware for further escalation. An email address and password is all that is necessary for the attack to take place. It is important to note that multi factor authentication (MFA) does not protect against ProxyNotShell, since the Exchange front-end used allows the attacker to exploit the service via basic authentication.
Before Microsoft released its patches in November, they provided an IIS URL rewrite mitigation around the Autodiscover front-end using the Exchange Emergency Mitigation Service. Researchers discovered soon after that the proposed mitigations could easily be bypassed.
In December, CrowdStrike detailed their findings on a new exploitation method using Outlook Web App (OWA). CrowdStrike researchers were able to replicate the attack on Exchange servers that did not have the November patch, but could not replicate it on servers which had received the patch.
- Exchange Server 2013
- Exchange Server 2016
- Exchange Server 2019
What to do
- If you are using Exchange Online, you are not impacted.
- Apply the November 8, 2022 Exchange Server patches to prevent exploitation. The URL rewrite mitigations provided by EEMS for are not effective against this exploit.
- If you cannot apply the November patch, disable OWA until the patch is applied.
- Disable remote PowerShell for non-admin user accounts using any of the methods highlighted here.
- Run the CrowdStrike OWASSRF PowerShell script to check against any indicators of compromise (IoC).