image not found image not found
image not found
image not found

The Exploitation of CVE-2020-0688 in the UAE

9 NOV 2020 | Ahmed Al Hashmi, Joseph Francis, and Mylene Villacorte

Introduction

During a recent incident, the Digital14 Incident Response team came across two notable pieces of malware related to recent APT activity in the MENA region. The incident started with the exploitation of CVE-2020-0688, which the attacker used to drop two DLL artefacts into a folder on the victim’s Exchange servers. The first piece of malware was first publicly disclosed by RSA on March 24th, 2020. While RSA covered the ‘System.Web.TransportClient.dll’ malware in detail, our main focus will be to discuss the second artefact, ‘System.Web.ServiceAuthentication.dll’, which at this time has not been publicly disclosed. This malware is particularly interesting because it shows the evolution and change in techniques and capabilities demonstrated by specific threat actors, and their ability to create malware giving them a stronger foothold in their target network.

System.Web.TransportClient .dll

The first DLL webshell we will examine is the ‘System.Web.TransportClient.dll.’ After the initial exploitation of the public-facing web server using CVE-2020-0688, the threat actor saved the webshell to ‘C:\windows\temp’ and then installed it at the ‘C:\windows\Microsoft.NET\assembly\GAC_MSIL\
system.web.transportclient\v4.0_1.0.0.0_9cbc’ directory. They used a PowerShell script to register the webshell in the Global Assemblies Cache (GAC) folder and used the IIS command line tool appcmd.exe to register it as a managed IIS module on the Exchange server. Once registered, the webshell had the functionality to execute commands over an encrypted transmission via cmd.exe as well as to send commands to a named pipe called “splsvc.” The named pipe was initially set up by another PowerShell script found running in memory and provided the functionality to receive and execute commands sent to it by the webshell.

Named Pipe “splsvc”

The attacker could issue commands to the webshell by sending a specially crafted HTTP POST request containing two variables to the /ews/exchange.asmx page. The first variable contains the first octet of the hardcoded AES key (9g6f4tKp) followed by the encoded payload data. The payload carries the commands to be executed. The second variable contains the third octet of the hardcoded AES key (K0IzA79Y) followed by further encoded data which identifies the target device. If the second variable is not present in the HTTP request, the command will execute on the local system, in this case, the Exchange server. Lastly, the data is decrypted using base64 and the hardcoded AES key (9g6f4tKp****K0IzA79Y****) and then executes using cmd.exe.


DLL Code Snippet


AES Key Octets

Crafted HTTP Request

Decrypted Payload Data (1st variable)t

System.Web.ServiceAuthentication
.dll

The second DLL webshell that we identified was ‘System.Web.ServiceAuthentication.dll’ and was used by the threat actor during the escalation phase of their attack. The webshell was also located in the GAC folder, and it contained three mechanisms which are: 1) form authentication capture, 2) basic authentication capture, and 3) command and control. With the first mechanism, the webshell monitors HTTP traffic and then captures credentials from webform data as victims submit their usernames and passwords. Then it places the captured username and password into a memory object for crosschecking. If the credentials are found in the memory object, the malware appends "exists in cache" to the output log file or else it appends “add to cache” along with the newly captured username and password to the output log file.


Form Authentication Capture Mechanism

The malware also employed a secondary mechanism to capture credentials by looking at the HTTP header for basic access authentication. If the header contains “Authorization” with the text “header:” and “basic”, then the base64 data is captured and decoded to reveal the cleartext username and password. Next, it puts the username and password into a memory object for crosschecking. If the username and password already exist, it will append “exists in cache” to the output log file, else it will append “add to cache”, and finally it adds the DateTime, username, password, and HTTP status code. The log file containing the captured credentials from both the form and basic authentication mechanisms is stored in the C:\windows\temp folder.


Basic Authentication Capture Mechanism

Lastly, with the third mechanism, the webshell acts as a command and control agent. It waits and listens for specific cookies and their respective values in the HTTP response header and then executes the corresponding function. Below is a table with the cookies, values, and functions.


Table 1: Cookies, Values, and Functions


HTTP Header with Cookies and Values

Conclusion

In this incident, the threat actor was able to conceal their malware on the Exchange servers by imitating legitimate IIS file naming conventions. Then they leveraged these modules to gain access to the target system, harvest credentials, and execute commands within the network. Early detection is vital to prevent attackers from securing a stronger foothold in the network and using legitimate accounts to mask their activity. Detection can be achieved by monitoring for encoded PowerShell commands, verifying newly loaded IIS modules, and using secure module authentication.

While the Digital14 Incident Response team will not be discussing attribution of these samples, it is interesting to watch the evolution of this threat actor as they mature aspects of their tradecraft.

IOCs

Table 2: File Names and Hashes

Yara Rules

We Are Digital14

Connect with us

© Digital14. All rights reserved.