New Zero-day on Microsoft Exchange Server Exploited in Wild

Update: 

1. Microsoft acknowledges these new Exchange Zero-days vulnerabilities affecting Exchange Server 2013, 2016, and 2019, which are now identified as CVE-2022-41040 and CVE-2022-41082.
2. ZDI has published a quick demonstration of the bug. 
3. Microsoft released a script for the URL Rewrite mitigation.
4. Update with Microsoft Analysis report and security measures in mitigation section.

Security researchers from GTSC Network Security firm have found a new zero-day vulnerability in Microsoft Exchange Server which is exploiting in wild.

According to the GTSC report, at the beginning of August 2022, they discovered a critical infrastructure was being attacked, specifically their Microsoft Exchange application. On investigating the incident, they found that the attack utilized an unpublished Exchange security vulnerability, i.e., a 0-day vulnerability on Microsoft Exchange Server. 

The researcher noted that the vulnerability turns out to be so critical that it allows the attacker to execute code remotely  (RCE ) on the compromised system. 

Reported To Microsoft via ZDI

The researcher started researching and debugging Exchange de-compiled code to find the vulnerability and exploit code. As the researcher successfully uncover the vulnerability and developed the exploit code for the new zero-day vulnerability, they submitted the vulnerability to the Zero Day Initiative (ZDI) to work with Microsoft so that a patch could be prepared as soon as possible. 

ZDI quickly verified and acknowledged 2 bugs, whose CVSS scores are 8.8 and 6.3, concerning the exploit. 

Another MS Exchange 0day Vulnerability

The exploit process comprises two parts as follows:

1. Requests with a similar format to the ProxyShell vulnerability😵:
   

   autodiscover/[email protected]/<Exchange-backend-endpoint>Email=autodiscover/autodiscover.json%[email protected] 

   
   
2. The use of the link above to access a component in the backend where the RCE could be implemented. 

However, at this time, GTSC has NOT released any technical details regarding this new zero-day vulnerability.

GTSC noted in their report that the hackers have used various techniques to create backdoors on the affected system and perform lateral movements to other servers in the system. They have also found obfuscated webshells, being dropped to Exchange servers. Using the user-agent, they found that the attacker uses Antsword, an active Chinese-based open-source cross-platform website administration tool that supports webshell management.

Chinese hackers Behind the Attack

On digging into the attacker's backdoors and researcher suspected that the attacker may come from a Chinese attack group because the webshell codepage is 936, which is a Microsoft character encoding for simplified Chinese.

Additionally, the hacker also changes the content of the file RedirSuiteServiceProxy.aspx to webshell content. RedirSuiteServiceProxy.aspx is a legitimate file name available in the Exchange server.

Microsoft Analysis Report

According to the analysis report, Microsoft observed activity related to the single activity group, which is likely to be a state-sponsored organization. Attackers achieved initial access and compromised Exchange servers by chaining CVE-2022-41040 and CVE-2022-41082 in fewer than 10 organizations globally. 

These attacks installed the Chopper web shell to facilitate hands-on-keyboard access, which the attackers used to perform Active Directory reconnaissance and data exfiltration. 

Attacks using Exchange vulnerabilities CVE-2022-41040 and CVE-2022-21082 (via Microsoft)

Temporary Mitigation

GTSC wrote that there may be many other organizations that have been exploited by this 0-day vulnerability but have not been discovered. While waiting for the official patch from Microsoft, GTSC provides a temporary fix or patch to reduce the vulnerability of attacks by adding a rule to block requests with indicators of attack through the URL Rewrite Rule module on the IIS server.

• In Autodiscover at FrontEnd select tab URL Rewrite, select Request Blocking
  
  
  
• Add string “.*autodiscover\.json.*\@.*Powershell.*“ to the URL Path:   
  
  
  
• Condition input: Choose {REQUEST_URI}
  

Microsoft strongly recommended all organizations/enterprises that are using On-premises Microsoft Exchange customers to check, review, and apply the above temporary remedy as soon as possible to avoid potential serious damages.

Additionally, Microsoft Exchange Server customers using Microsoft 365 Defender are advised to follow this checklist:

• Turn on cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to cover rapidly evolving attacker tools and techniques. Cloud-based machine learning protections block a huge majority of new and unknown variants.
• Turn on tamper protection features to prevent attackers from stopping security services.
• Run EDR in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus doesn’t detect the threat or when Microsoft Defender Antivirus is running in passive mode. EDR in block mode works behind the scenes to remediate malicious artifacts that are detected post-breach.
• Enable network protection to prevent applications or users from accessing malicious domains and other malicious content on the internet.
• Enable investigation and remediation in full automated mode to allow Microsoft Defender for Endpoint to take immediate action on alerts to resolve breaches, significantly reducing alert volume.
• Use device discovery to increase your visibility into your network by finding unmanaged devices on your network and onboarding them to Microsoft Defender for Endpoint.

Furthermore, it is also recommended to implement MFA on all accounts in all locations, at all times. Users can also opt to enable passwordless authentication methods (like Windows Hello, FIDO keys, or Microsoft Authenticator) for accounts that support passwordless.

Detection:

To help organizations check if their Exchange Servers have been exploited by this 0day vulnerability, follow the guideline released by GTSC and a tool to scan IIS log files (stored by default in the %SystemDrive%\inetpub\logs\LogFiles folder ): 

Method 1: Use the following PowerShell command:

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

Method 2: Use the tool developed by GTSC: Based on the exploit signature, GTSC developed a tool to automate the task rather than search with a much shorter time needed than using Powershell.