Microsoft confirms Exchange zero

Microsoft confirmed that two recently disclosed zero-day flaws in Microsoft Exchange are being actively exploited in the wild.

Microsoft confirmed that two zero-day vulnerabilities in Microsoft Exchange recently disclosed by researchers at cybersecurity firm GTSC are being actively exploited in the wild.

The IT giant has promptly started the investigation into the two zero-day vulnerabilities that impacts Microsoft Exchange Server 2013, 2016, and 2019. The first flaw, tracked as CVE-2022-41040, is a Server-Side Request Forgery (SSRF) issue. The second vulnerability, tracked as CVE-2022-41082, allows remote code execution (RCE) when PowerShell is accessible to the attacker.  

Successful exploitation of the CVE-2022-41040 can allow an authenticated attacker to remotely trigger CVE-2022-41082. 

“At this time, Microsoft is aware of limited targeted attacks using the two vulnerabilities to get into users’ systems.  In these attacks, CVE-2022-41040 can enable an authenticated attacker to remotely trigger CVE-2022-41082. It should be noted that authenticated access to the vulnerable Exchange Server is necessary to successfully exploit either of the two vulnerabilities.” reads the advisory published by Microsoft.

Microsoft announced that it is working to accelerate the timeline to release a fix that addresses both issues. Meantime, the company provided the mitigations and detection guidance to help customers protect themselves from these attacks. 

Microsoft states that Microsoft Exchange Online Customers do not need to take any action, while it provided mitigation for on-premises Microsoft Exchange customers which are the same shared by GTSC.

“We are working on an accelerated timeline to release a fix. Until then, we’re providing the mitigations and detections guidance below to help customers protect themselves from these attacks,” Microsoft added.

According to Vietnamese cybersecurity outfit GTSC, who first reported the ongoing attacks, the zero-days are chained to deploy Chinese Chopper web shells for persistence and data theft and to move laterally through the victims’ networks.

GTSC also suspects that a Chinese threat group might be responsible for the ongoing attacks based on the web shells’ code page, a Microsoft character encoding for simplified Chinese.

The threat group also manages the web shells with the Antsword Chinese open-source website admin tool, as revealed by the user agent used to install them on compromised servers.

GTSC recommends adding a rule to block requests with indicators of attacks through the URL Rewrite Rule module on IIS server.

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. 

To allow organizations to check if their Exchange Servers have been compromised by exploiting these flaws, GTSC released guideline and a tool to scan IIS log files (stored by default in the %SystemDrive%\inetpub\logs\LogFiles folder ): 

• Method 1: Use 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, we build a tool to search with much shorter time needed than using powershell. The link to download: https://github.com/ncsgroupvn/NCSE0Scanner

Below is the step by step procedure provided by Microsoft to mitigate the risk of exploitation for the above issues:

1. Open the IIS Manager.
2. Expand the Default Web Site.
3. Select Autodiscover.
4. In the Feature View, click URL Rewrite.
5. In the Actions pane on the right-hand side, click Add Rules.
6. Select Request Blocking and click OK.
7. Add String “.*autodiscover\.json.*\@.*Powershell.*” (excluding quotes) and click OK.
8. Expand the rule and select the rule with the Pattern “.*autodiscover\.json.*\@.*Powershell.*” and click Edit under Conditions.
9. Change the condition input from {URL} to {REQUEST_URI}

Microsoft also recommends customers block the following Remote PowerShell ports:

1. HTTP: 5985
2. HTTPS: 5986

Who is behind the attack?

The GTSC researchers believe that the attacks were conducted by a Chinese threat actor because the webshell codepage is 936, which is a Microsoft character encoding for simplified Chinese.

Follow me on Twitter: @securityaffairs and Facebook

[adrotate banner=”9″]

[adrotate banner=”12″]

Pierluigi Paganini

(SecurityAffairs – hacking, Microsoft Exchange)

[adrotate banner=”5″]

[adrotate banner=”13″]

---

---