Microsoft Exchange On-Prem Zero-Day Vulnerabilities Exploited in the Wild

On Thursday, September 29th, 2022, GTSC–a Vietnam-based cybersecurity company–published a blog detailing intrusion they investigated that chained together two exploits for Microsoft Exchange zero-day vulnerabilities to achieve remote code execution (RCE). Technical details around how to exploit these vulnerabilities were not provided.  

Microsoft has acknowledged these vulnerabilities and assigned CVE-2022-41040 for a Server-Side Request Forgery (SSRF) vulnerability and CVE-2022-41082 for a post-authentication remote code execution (RCE) vulnerability that can be exploited when PowerShell Remoting is accessible to an already authenticated user. 

According to Microsoft, the company “is investigating two reported zero-day vulnerabilities affecting Microsoft Exchange Server 2013, 2016, and 2019”. Furthermore, Microsoft states that Exchange Online is not affected. There are no patches available for these vulnerabilities, however, Microsoft has also stated “They are working on an accelerated timeline to release a fix” and has provided a mitigation that involves a URL re-write that can be applied to Exchange On-prem Servers directly to which we have outlined in the recommendations section of this bulletin. 

Microsoft has stated that for a threat actor to achieve full remote code execution exploiting these two vulnerabilities, the following needs to happen: 

1. Threat actor requires prior authentication to the Exchange Server
   • Based on previous Exchange remote code execution vulnerabilities we have seen such as ProxyLogon and ProxyShell, we assess with moderate confidence that this can include credentials for any Exchange user (including mailbox users). 

1. • These types of credentials can potentially be acquired via phishing a user or performing credential replay attacks to identify sets of email credentials where the password has been re-used and has been available in public breach data sets. 
2. PowerShell Remoting needs to be enabled on your Exchange with port 5985/5986 publicly accessible. 
   • Note: Having PowerShell Remoting publicly accessible on an Exchange Server is not a best security practice.  

Based on the criteria for exploitation, we assess with moderate confidence that these vulnerabilities are not as impactful as previous Exchange RCE vulnerabilities like ProxyLogon and ProxyShell, however, they may still introduce significant risk to organizations if PowerShell Remoting is publicly accessible on Exchange Servers. 

We strongly recommend you review the recommendations section of this bulletin and apply security enhancements to your on-prem Exchange Servers where applicable to reduce the likelihood of these zero-day vulnerabilities being successfully exploited. 

Recommendations 

Recommendation #1: Restrict Access to External-Facing Exchange Servers 

Practice the principle of least-privilege when configuring your Microsoft Exchange Server. Leverage Access Control List (ACL) restrictions on Exchange Control Panel (ECP) and other directories within IIS. The ECP directory should not be exposed to the Internet unless absolutely necessary.  

Restrict access to Exchange Servers via VPN for approved users; deny access from TOR, proxy, and third-party VPN IPs to limit exploitation. Furthermore, restrict unnecessary ports and traffic from the Exchange Server. 

• Note: Necessary ports for outbound traffic from Exchange Server are 25, 53, 123, 80, 443 

Recommendation #2: Block Exposed Remote PowerShell Ports 5985 and 5986 

Threat actors that can access PowerShell Remoting on vulnerable Exchange servers can trigger the RCE vulnerability CVE-2022-41082. Blocking HTTP port 5985 and HTTPs port 5986 used by Remote PowerShell can limit exploitation.  

Recommendation #3: Implement Microsoft Provided URL Rewrite Instructions 

Microsoft recommends implementing a URL rewrite in IIS Manager on Exchange.  

Instructions provided by Microsoft are below on how to implement this URL rewrite (more details here): 

1. Open IIS Manager
2. Select Default Web Site
3. Click URL Rewrite in the Feature View
4. Click Add Rule(s) in the Actions pane
5. Select Request Blocking and click OK
6. Add String “.*autodiscover\.json.*\@.*Powershell.*” (excluding quotes) and click OK
7. Select Regular Expression under Using
8. Select Abort Request under How to block and click OK
9. Expand the rule and select the rule with the Pattern “.*autodiscover\.json.*\@.*Powershell.*” and click Edit under Conditions
10. Change the condition input from {URL} to {REQUEST_URI}

Note: Microsoft has stated there is no known impact to Exchange functionality if the URL Rewrite module is installed as recommended. 

References: 

• GTSC Blog  
• Microsoft Statement on Zero-Days