As we've mentioned in previous blogs, cybercriminals will often tie their attacks to current events. So, it isn't surprising that we noticed another one of these, with this particular one using tech events in London as the bait.
In February 2020 and May 2020, we observed four malicious macro-based Microsoft Word documents hosted on newly registered sites with top-level domains of .space and .xyz. We attribute these attacks to the same threat actor due to the similar tactics, techniques and procedures (TTPs) used to deploy the final payload.
The final .NET payload, to the best of our knowledge, has not been observed in the wild before. It has a small code section in it that overlaps with the QuasarRAT. However, this code was not used at runtime. We have assigned the name - ShellReset to this RAT based on the unique strings found inside the final payload.
Due to the limited instances we have observed in the wild, we suspect this to be a low-volume targeted attack. Some of the themes used in these attacks by the threat actor are related to important events that were originally scheduled to take place in London earlier this year, including the 5G Expo and Futurebuild.
The infection chain involves interesting techniques, such as compiling the payload at runtime on the endpoint using trusted Windows utilities to bypass security mechanisms and downloading the next stages in the form of obfuscated source code from the attacker’s server.
In this blog, we provide a detailed description of the distribution strategy and the technical analysis of the attack.
The first instance of the document related to this campaign was found on February 24, 2020. It was hosted at the URL: hxxps://documentsharing.space/files/5G%20Expo.doc?clientEmail=
MD5 hash: 93f913f3b9e0ef3f5cedd196eae3f2ae
File name: 5G Expo.doc
The content of this document was related to 5G Expo event, which was scheduled to take place on March 17-18, 2020 in London as shown in Figure 1.
Figure 1: This document displays the 5G Expo 2020 theme after macros are enabled.
On the same day, we observed another instance of a document hosted on the same domain at the URL: hxxps://documentsharing.space/files/FutureBuild.doc?clientEmail=
MD5 hash: b34b74effbd8647c4f5dc61358e1555f
File name: FutureBuild.doc
The content of this document was related to Futurebuild 2020 conference, which was supposed to take place between March 3-5, 2020 in London. The document spoofed the contents to look like an admission voucher for this conference as shown in Figure 2.
Figure 2: The document displays the Futurebuild 2020 theme after macros are enabled.
In both cases, the domain used to host the file was documentsharing[.]space. As per the Whois records of the domain, it was registered on October 21, 2019.
The next two instances of the documents from the same threat actor were observed in May 2020.
On May 19, 2020, we found a malicious macro-based Word document hosted at the URL: hxxps://misrmarket[.]xyz/files/Get%20Stared.doc?clientEmail=
MD5 hash: 7bebf686b6e1d3fa537e8a0c2e5a4bdc
File name: Get%20Stared.doc
The content of this document was a message about a personal data revolution and included a list of legitimate sites as shown in Figure 3.
Figure 3: The document displays a message about a personal data revolution.
Upon further research, we found that this text was copied from a legitimate site, datacoup.com, as shown in Figure 4. Attackers use such tactics for social engineering purposes to make the content of the file look relevant and legitimate.
Figure 4: The message displayed in the document was copied from datacoup.com.
The site that was used to host this document is a spoof of the popular site, anonfiles.com, which allows the users to upload their files anonymously. There is a slight difference between the user interface of this spoofed site and the original site.
Figure 5 shows the user interface of the spoofed site.
Figure 5: The web user interface of the spoofed version of anonfiles.com.
Figure 6 shows the user interface of the original site.
Figure 6: The original site, anonfiles.com, and the differences with the spoofed version.
The regions of the site marked in red were not present in the spoofed domain. As per Whois data, the spoofed site, misrmarket[.]xyz, was registered on February 26, 2020.
A common pattern we observed in all the URLs hosting the documents was: “?clientEmail=”
This parameter of the URL contained the email address of the targeted user.
Technical analysis of the macro
When the macro-based document is opened, it will display a message that asks the user to enable macros to view the contents as shown in Figure 7.
Figure 7: The message displayed by the document, which asks the user to enable macros.
When the macros are enabled, the Auto_Open() subroutine of the macro is called, which will hide the above image and display the image corresponding to the theme of the document (5G Expo, Future Build 2020, and others) as described in previous section.
The relevant macro code section, which unhides the image after macros are enabled, is shown in Figure 8.
Figure 8: The macro code used to unhide the image.
For the purpose of analysis, we will take the file with MD5 hash: 7bebf686b6e1d3fa537e8a0c2e5a4bdc
The contents of the macro are shown in Figure 9.
Figure 9: The macro code in the document.
The main functions performed by this macro code are:
- It sets the working directory and the name of the dropped file to ServiceHostV1000.
- It contains the complete C# code embedded inside the macro, which will be written at runtime to the file: ServiceHostV1000.cs in the working directory. The C# code is obfuscated at the source level. The obfuscation is simple. Only the variable, class and method names are obfuscated.
- It sets the compiler directory to the location of the file, csc.exe, on the machine. Csc.exe is the command line compiler for C# code and is installed by default with Microsoft .NET framework. The macro searches for versions 3.5 and 4.0.x on the machine. It sets the compiler directory accordingly based on the version of .NET framework installed on the machine as shown in Figure 10.
Figure 10: The macro code used to compile C# code on the machine.
- It compiles the code using csc.exe and the command line parameter:”-target:winexe -out:”. The compiled binary will be present in the Startup directory.
- It deletes the working directory that contained the source code.
- It executes the compiled binary.
MSbuild.exe was used in this case to compile the code on the machine using a .csproj file as a method to bypass Windows security mechanisms, such as AppLocker and Device Guard. This technique was made public for the first time by Casey Smith a few years ago.
Analysis of .NET binary
MD5 hash: 4e0f9f47849949b14525c844005bb567
File name: ServiceHostV1000.exe
The main subroutine of the .NET binary is shown in Figure 11.
Figure 11: The main subroutine of .NET binary.
Below are the main operations performed by this .NET binary.
It sends an HTTP GET request to the URL: misrmarket[.]xyz/files/app-provider/getApp and sets the Content-type request header field to: “application/json”.
Figure 12 shows the contents of the response from the server, which contains a JSON file.
Figure 12: The server response containing the JSON data.
This JSON file contains three keys:
Version: Set to null.
csproj: Contains project file used by msbuild.exe at the time of compiling the C# project.
cs: Contains the C# code that needs to be compiled at runtime.
- The C# code used DataContractJsonSerializer class to parse the JSON response from the server and extract the individual members. The .cs and .csproj files were dropped in the location: %USERPROFILE%\ServiceTaskV1001 with the file names, w.cs and w.csproj.
- For compiling the C# code, it uses msbuild.exe. The versions of .NET framework checked on the machine to find msbuild.exe are version 3.5 and 4.0.x as shown in Figure 13.
Figure 13: Code section which checks version of .NET framework on the machine.
Analysis of .NET-based RAT
MD5 hash of the payload: 8f62d7499d5599b9db7eeddf9c01a061
System information gathering
The first activity performed by the payload is to gather information about the system as shown in Figure 14.
Figure 14: The code section used to gather system information.
Information about the following properties are collected from the machine:
- Bot ID: A unique identifier for the machine. The calculation of this field is detailed later in this blog.
- CPU name: Processor details.
- RAM – The total amount of RAM installed on the machine.
- User name
- Host name
- System drive name
- System directory path
- Operating system type: This field is set to windows.
Calculation of unique bot ID: The payload first calculates a unique identifier for the machine which will be used to identify the bot. It calculates this ID using various properties of the machine as detailed below.
a = “SerialNumber” field from the output of WMI query: SELECT * FROM Win32_DiskDrive
b = “Name” field from the output of WMI query: SELECT * FROM Win32_Processor
c = “Manufacturer” and “SerialNumber” field from the output of WMI query: SELECT * FROM Win32_BaseBoard
d = “Manufacturer” field from the output of WMI query: SELECT * FROM Win32_BIOS
The final ID is calculated by linking all the above values (a, b, c and d), then calculating the MD5 hash and using the first 12 characters of the resulting MD5 hash.
This can be represented as: MD5(a+b+c+d)[0:12]
A unique integer value of 15 is appended to it to generate the final ID.
Once the above information is collected from the machine, it is sent to the server in an HTTP POST request as shown in Figure 15.
Figure 15: The code section used to register the bot with the Command and Control (C&C) server.
The request is sent to the URL: hxxp://theashyggdrasil[.]xyz/api/clients/identifyClient and the Content-Type field is set to “application/json”. This first network request post-infection is used to register the bot with the attacker’s server with a unique identifier.
The network request is shown in Figure 16.
Figure 16: The system information sent to C&C server in an HTTP POST request.
Once the bot is registered with the server, it sends a GET request to the path: /api/orders/getOrders/<bot_id> to fetch the command that needs to be executed on the machine. The response from the server will be in JSON format that will be parsed by the bot.
The subroutine that handles the C&C communication is shown in Figure 17.
Figure 17: The subroutine that handles the C&C communication.
There are four operations supported by the bot, which are described below.
cmdExec: This operation allows the attacker to execute code on the machine. By parsing the JSON response, a CmdReq structure is retrieved which has two members:
The subroutine for cmdExec operation is shown in Figure 18.
Figure 18: The subroutine that handles the cmdExec command.
If the command is equal to “***reset*shell***”, then a new instance of cmd.exe is spawned on the machine as shown in Figure 19.
Figure 19: The subroutine used to spawn a new shell.
For any other command, the same shell will be used to execute.
getDir: This command can retrieve the complete list of all the files present in a specific path on the machine.
Figure 20: The subroutine that handles the getDir command.
This information will be exfiltrated to the server in an HTTP GET request to the path: /api/files/onGetDirRun
uploadFile: This command is used to upload a file from a given path on the machine to the attacker’s server as shown in Figure 21.
Figure 21: The subroutine that handles the uploadFile C&C command.
AwsInfoRes is a class with two members:
This information is retrieved from the server by sending an HTTP GET request to the path: /api/assets/getAwsUploadUrl
From the JSON response, the uploadURL and fileKey values are extracted.
The file will be exfiltrated by sending an HTTP PUT request to the URL defined in the uploadURL member of the AwsInfoRes object.
getScreenshot: This command allows the attacker to remotely take screenshots of the machine as shown in Figure 22.
Figure 22: The subroutine that handles the getScreenshot command.
QuasarRAT code overlap
There is a small code section in this .NET binary that has a code overlap with the QuasarRAT. The overlap is only with the StringHelper class of the QuasarRAT.
Figure 23 shows this section of code from the .NET binary.
Figure 23: The code section that has overlap with the QuasarRAT.
These functions are similar to the ones defined in the StringHelper class of QuasarRAT. However, most of these functions are not called in the .NET binary in this case.
Cloud Sandbox detection
Figure 24 shows the Zscaler Cloud Sandbox successfully detecting this document-based threat.
Figure 24: The Zscaler Cloud Sandbox detection.
In addition to sandbox detections, Zscaler’s multilayered cloud security platform detects indicators at various levels, as seen here: Win32.RAT.ShellReset
This threat actor leverages themes relevant to current events, such as conferences and exhibitions, to spread malicious macro-based documents. Users should verify the source of such documents before opening them.
As an extra precaution, users should not enable macros for Microsoft Office files that are received from untrusted sources since these macros have the capability to run malicious code on the machine.
The Zscaler ThreatLabZ team will continue to monitor this attack, as well as others, to help keep our customers safe.
MITRE ATT&CK TTP Mapping
||Macros in document used for code execution.
||Uses MSBuild.exe to proxy execution of code through a trusted Windows Utility.
||Startup directory-based persistence.
||Takes screen captures of the desktop.
||Data exfiltrated from the machine to the server.
||File and Directory discovery.
||Uses cmd.exe to execute commands remotely on the machine.
Indicators of Compromise (IOCs)
Hashes of the macro-based documents
URLs hosting the documents
URLs used to download next stage
API endpoints used in post-infection domains