New Zero-day on Microsoft Exchange Server exploited in the wild

0

Security researchers from GTSC Network Security have discovered a new zero-day vulnerability in Microsoft Exchange Server that is being exploited in the wild.

According to the GTSC report, in early August 2022, they discovered that critical infrastructure was under attack, specifically their Microsoft Exchange application. While investigating the incident, they discovered that the attack used 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 perform remote code execution (RCE) on the compromised system.

Reported to Microsoft via ZDI

The researcher began researching and debugging the decompiled code of Exchange to find the vulnerability and exploit code. When the researcher succeeded in discovering the vulnerability and developing the exploit code for the new zero-day vulnerability, he submitted the vulnerability to the Zero Day Initiative (ZDI) work with Microsoft so that a fix can be prepared as soon as possible.

ZDI quickly checked and acknowledged 2 bugs, with CVSS scores of 8.8 and 6.3, regarding the exploit.

MS Exchange RCE Bug

Another MS Exchange 0day Vulnerability

The exploit process consists of two parts as follows:

  1. Requests with a format similar to the ProxyShell VulnerabilityđŸ˜”:
    autodiscover/[email protected]/Email=autodiscover/autodiscover.json%[email protected] 

  2. Using 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 its report that hackers used various techniques to create backdoors on the affected system and perform lateral movements to other servers in the system. They also found obfuscated webshells dropped on Exchange servers. Using the user agent, they discovered that the attacker was using Antsword, an active China-based cross-platform open-source website administration tool that supports webshell management.

The Chinese hackers behind the attack

While digging through the attacker’s backdoors, the researcher suspected that the attacker may have come from a Chinese attack group, as the Webshell codepage is 936, which is a Microsoft character encoding for Simplified Chinese .

Moreover, the hacker also modifies the contents of the RedirSuiteServiceProxy.aspx file into Webshell contents. RedirSuiteServiceProxy.aspx is a legitimate file name available on the Exchange server.

Exchange web shell

Temporary attenuation

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 fix from Microsoft, GTSC is providing an interim fix or patch to reduce the vulnerability of attacks by adding a rule to block requests with attack flags through the URL Rewrite Rule module on the IIS server.

  • In Autodiscover at FrontEnd, select the URL Rewrite tab, select Request Blocking
    patch or interim fix

  • Add the string “.*autodiscover.json.*@.*Powershell.*” to the URL path:
    patch or interim fix

  • Condition entry: choose {REQUEST_URI}
    patch or interim fix

It is strongly recommended that all organizations/companies that use Microsoft Exchange Server check, review and apply the above temporary remedy as soon as possible to avoid possible serious harm.

Detection:

To help organizations verify whether their Exchange servers have been exploited by this 0day vulnerability, follow the guidelines published by GTSC and a tool to analyze IIS log files (stored by default in the %SystemDrive%inetpublogsLogFiles case ):

Method 1: Use the following PowerShell command:

Get-ChildItem -Recurse -Path  -Filter "*.log" | Select-String -Pattern 'powershell.*autodiscover.json.*@.*200
Method 2: Use the tool developed by GTSC: Based on the exploit signature, GTSC has developed a tool to automate the task rather than searching with a much shorter time required than using Powershell.
Share.

Comments are closed.