Zero-Day Vulnerabilities Found in Microsoft Exchange (CVE-2022-41040 and CVE-2022-41082)

What Happened?

Two zero-day vulnerabilities were discovered in Microsoft Exchange Server 2013, 2016, and 2019. One vulnerability, CVE-2022-41040 is a Server-Side Request Forgery (SSRF) vulnerability; the other, CVE-2022-41082, is a remote-code execution (RCE) vulnerability when the attacker can access PowerShell.

🚨 There’s reports emerging that a new zero day exists in Microsoft Exchange, and is being actively exploited in the wild 🚨

I can confirm significant numbers of Exchange servers have been backdoored – including a honeypot.

Thread to track issue follows:

— Kevin Beaumont (@GossiTheDog) September 29, 2022

These vulnerabilities are nearly indistinguishable to many ProxyShell attacks in their log and behavior pattern once Exchange is exploited.

ProxyShell is a series of critical vulnerabilities discovered in 2021 that affect on-premises Microsoft Exchange servers. ProxyShell vulnerabilities are especially critical not only because they allow RCE, but because they are relatively easy to execute. The report of an RCE vulnerability within PowerShell Remote is additionally concerning; however, exposure should be limited to internal authenticated users as long as there are no exposed 5985 or 5986 ports to the internet. 

It appears these new Exchange vulnerabilities were created by a specific new group that built new attack methods. However, the attack is no different from ProxyShell in the end as we’ve seen: a threat actor spawns cmd via ProxyShell (e.g., spawned via w3wp.exe) and then uses an environment’s living off the land binaries to execute the attack.

How Bad is This?

At the time of this writing, neither CVE rating can be found in NIST’s National Vulnerability Database or MITRE.

However, an RCE is one of the most dangerous types of flaws because it allows an adversary to execute malicious code on vulnerable servers. While Microsoft has confirmed that these are two new RCE vulnerabilities, they have further clarified that authenticated access to the vulnerable Exchange server is required to exploit either of them.

What Should I Do?

According to Microsoft, Exchange Online customers do not need to take any action. However, customers running Microsoft Exchange on-premises should apply Microsoft’s URL Rewrite Instructions and block any exposed Remote PowerShell ports.

The following mitigation details were provided by Microsoft and derived with support by the original reporter of this vulnerability.

The current mitigation is to add a blocking rule in “IIS Manager > Default Web Site > Autodiscover > URL Rewrite > Actions” to block the known attack patterns. 

Microsoft has confirmed that the following URL Rewrite Instructions, which are currently being discussed publicly, are successful in breaking current attack chains. 

• Open the IIS Manager. 
• Expand the Default Web Site. 
• Select Autodiscover. 
• In the Feature View, click URL Rewrite. 
• 
• In the Actions pane on the right-hand side, click Add Rules.

• Select Request Blocking and click OK. 

• Add String “.*autodiscover\.json.*\@.*Powershell.*” (excluding quotes) and click OK.
• Expand the rule and select the rule with the Pattern “.*autodiscover\.json.*\@.*Powershell.*” and click Edit under Conditions. 

• Change the condition input from {URL} to {REQUEST_URI} 

Impact: There is no known impact to Exchange functionality if the URL Rewrite module is installed as recommended. 

Authenticated attackers who can access PowerShell Remoting on vulnerable Exchange systems will be able to trigger RCE using CVE-2022-41082. Blocking the ports used for Remote PowerShell can limit these attacks. 

• HTTP: 5985 
• HTTPS: 5986 

Microsoft has prioritized getting a fix released for these vulnerabilities, so be prepared to start patching once that becomes available.

Update: 10/3/2022 @ 1:30 PM ET 

• Microsoft has removed the recommendation to block PowerShell remoting ports (HTTP 5985 and HTTPS 5986). Do not consider this a mitigation for CVE-2022-41082.
• If your Exchange server is eligible and equipped with the Exchange Emergency Mitigation Service (EEMS), Microsoft has pushed an automatic update to block the attack. You can confirm whether or not this has been applied by checking the URL rewrite rules on your Exchange server. 
  • Open Administrative Tools and browse to IIS Manager > Sites > Default Website > URL Rewrite. It can be identified by the EEMS label included in the name of the rule.

• If you don’t see URL Rewrite in this panel, you will need to install it manually. It is available for Exchange 2013/2016/2019. It is installed by default on Exchange 2016 CU22+ and Exchange 2019 CU11+. Manual download and install can be performed from this page. Be aware that this install does require an IISRESET.

• Microsoft has updated their URL Rewrite instructions to set Action Type to “Abort Request” instead of the original recommendation of “Send an HTTP 403 (Forbidden) Response”
• Microsoft’s original URL Rewrite recommendation for mitigation has been proven to be ineffective. The updated recommendation is to use this string instead: .*autodiscover\.json.*Powershell.*
• It is also recommended to add an additional condition for {HTTP_COOKIE} input with the pattern Email=autodiscover

• Microsoft has released an updated script to automate the URL Rewrite mitigation. At the moment, this script applies Microsoft’s original (ineffective) URL Rewrite rules. If you want to apply the effective, updated strings, you must do so manually. Microsoft’s automation script can be found here.

How To Detect

Organizations should collect logs with Sysmon on Exchange hosts to identify any malicious activity.

Blumira customers can detect this attack at a number of positions within the kill-chain, keeping in mind that Exchange runs on top of the IIS process itself.

•  Potential Exchange ProxyLogon IIS Webshell Activity (Windows – Sysmon)
  • IIS process (w3wp.exe) spawns cmd or powershell processes
• Malicious Webshell Connection to External IP (NGFW – IPS)
  • A webshell is identified connected outbound
• Webshells by File Write (Windows – Sysmon)
  • IIS process (w3wp.exe) drops an asp, aspx, jsp, or php file.
• Potential IIS Webshell Activity (Windows – Sysmon)
  • IIS Process (w3wp.exe) as %DefaultAppPool% spawns cmd.exe.
• PowerShell Malicious Execution Detection: Posh C2, PowerShell Malicious Execution Detection: Cobalt Strike, PowerShell Malicious Execution Detection: PowerShell Empire, and PowerShell Empire Module (Windows)
  • Looking for patterns of known droppers via PowerShell exploitation
• T1059.001 – PowerShell Fileless Script Execution
  • In memory execution of PowerShell scripts, e.g., IEX
• Rclone Execution via Command Line or PowerShell (Windows)
  • Common attack pattern by groups once foothold is gained to exfiltrate data

For further technical details, see:

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

Sign Up For Your Free Account

Blumira’s cloud SIEM detects and alerts you about suspicious behavior in your environment so that you can stop an incident early enough to prevent damage. Each finding we send is accompanied with a security playbook, giving you clear recommendations on how to remediate an attack. Our support team of security analysts is always available to answer questions on how to interpret a finding, or for other security help.

Blumira’s free SIEM is easy to deploy; IT and security teams can start seeing immediate security value for their organizations.