Avast Software, Czech Republic
Since August 2018 we have been monitoring a new malware family, which we have named Rietspoof. Rietspoof is a piece of malware that is multi-staged, using different file types throughout its infection chain. It contains several types of stages – both extractors and downloaders; the fourth stage also contains support for remote-control commands. When we began tracking Rietspoof it was being updated approximately once a month. However, in January 2019 we noticed that the frequency of updates had increased to daily.
In this paper we will share a detailed analysis of each stage of the malware, starting from the initial Microsoft Word document serving as stage one. This stage is followed by a rather interestingly built and obfuscated Visual Basic script (VBS) leading to executable files that serve as both bots and downloaders. We will describe all relevant parts of the Visual Basic script, ranging from its unusual anti-behaviour detection tricks to the function which led us to the next stage, a CAB file dropped from the VBS.
The fourth stage is an executable file expanded from the CAB file. This executable file is digitally signed by a valid certificate, usually using Comodo CA. At the end of February, we found samples exhibiting different behaviour: a new VBS file with bot capabilities was dropped from the CAB file. The fourth stage serves as a bot that also supports a downloader functionality. During our investigation, we noticed that the malware author was constantly modifying all the stages. We distilled these changes into a detailed timeline, from which we can observe a lot of changes in the whole concept of this malware family, ranging from a reworked C&C communication protocol to a completely rewritten second stage.
In the fifth stage, the malware author used an interesting dropper technique to deploy fileless malware downloaded from the C&C server. The fifth stage utilized the NTLM protocol to provide authentication and encryption of its communication with the C&C server.
It is not common to see a C&C communication protocol being modified to such an extent, given the level of effort required to change it. Similarly, we rarely see feature regression in malware – we observed that the obfuscation of strings was removed in later versions of the fourth stage. Again, we will look at these changes in detail along with the underlying protocols.
Although we are monitoring Rietspoof very carefully, our hypothesis is that its authors are still developing this malware, and because of this we only have testing samples.
Rietspoof utilizes several stages, combining various file formats throughout its infection chain to deliver a potentially more versatile piece of malware. Our data suggests that the first stage was delivered through email and instant messaging clients such as Outlook and Skype. The first stage consists of a Microsoft Word document which works as a dropper and runner for a highly obfuscated Visual Basic script containing an encrypted and hard-coded encrypted CAB file – the third stage. The Visual Basic script is also digitally signed. The CAB file is expanded into an executable that is digitally signed with a valid signature, generally using Comodo CA or Sectigo RSA. The executable file downloads and installs a downloader in stage 4.
What’s interesting to note is that the fourth stage uses a simple TCP protocol to communicate with its C&C, whose IP address is hard coded in the binary. The protocol is encrypted by AES in CBC mode. In one version we observed the key being derived from the initial handshake. Later on, a second version appeared; in this case the key is derived from a hard-coded string. In version two, the protocol not only supports its own protocol running over TCP, but it also tries to leverage HTTP/HTTPS requests. It is rather uncommon to see a C&C communication protocol being modified to such an extent, given the level of effort required to change it. While it is common to change obfuscation methods, the C&C communication protocol usually remains relatively unmodified in most malware.
This downloader uses a home-brew protocol to retrieve another stage (stage 5) from a hard-coded address. While the stage 4 protocol includes bot capabilities, stage 5 acts as a designated downloader only.
The first stage of the Rietspoof attack is a malformed Microsoft Word document which is spread through email or instant messaging clients. The first stage works as a dropper and runner for a malicious Visual Basic script.
The document uses standard social engineering techniques to persuade victims to run it with macros enabled.
Figure 1: Social engineering.
Once macros are enabled, the information regarding the protected document is deleted and the title ‘Emergency exit map’ is shown.
Figure 2: Emergency exit map.
The attackers use a simple method in which they delete HeaderFooters and show the hidden text.
Figure 3: DeleteAllHeaderFooters.
Figure 4: ShowHiddenText.
Afterwards, the script deobfuscates the VBS and saves it onto the machine. The script is then executed by invoking wscript.exe with a parameter c:\users\NAME\appdata\roaming\microsoft\word\startup\.\.\\Windows\Cookies\wordTemplate.vbs, which is a path leading to the dropped VBS.
The raw Visual Basic script is stored as a Base64-encoded string represented by an array of hex codes.
Figure 5: Execution flow.
The first version of the VBS that we discovered was probably just a test version of Rietspoof as it contained almost no obfuscation. Also, the names of variables and functions correlate with their final functions.
Figure 6: Self explanatory names.
Since version one, each version has been more or less obfuscated and has used different binaryOffset (offset of payload), xorValue (XOR key) and AppName (dropped binary name) values. Nevertheless, all of them – at least until our blog post [1] was released – showed many similarities.
The first part of the Visual Basic script is a function for reading and deobfuscating embedded binaries.
Figure 7: Script reads itself from setup offset.
From the snippet shown in Figure 7 it is immediately obvious that the script starts reading code at a specific offset, deobfuscating the CAB file and readying it for the next stage. The code is converted, character by character, to its ANSI value and added to the counter variable. At every step, the counter is XOR’ed with val_01 (hard coded to 15) and appended to already decoded bytes. Interestingly, at every step, the string var_str_01 is also appended to var_str_02.
Figure 8: CAB deobfuscation.
After this step, var_str_02 is used as a parameter for a new function. The second parameter is TempPath, with the following filename:
Figure 9: Dropper function.
Figure 10: Drop CAB file.
At this stage the CAB file is saved to the machine’s TempPath under the name JSWdhndk.sjk. If we observed one the first versions, the name would be data.log instead. The following stage needs to be extracted from it, which is accomplished by using expand.exe, as shown in Figure 11.
Figure 11: Expand CAB file.
The script checks if the user is logged in as admin by reading the registry key “HKEY_USERS\S-1-5-19\Environment\TEMP”. In case of success, it sets func_read_Registry to True.
Figure 12: Checking if the victim is logged in as admin.
Note that S-1-5-19 belongs to NT Authority and can be accessed only by an admin (as noted in the Microsoft documentation [2]).
When this flag is set to True, the VBS changes the date to 01-01-2109. Again, the first version exhibited slightly different behaviour, using the date 01-01-2099. We can assume this is done to confuse some sandboxes or other behaviour-based detection systems and that the first date didn’t work as intended. The interim date with the year 2109(2099) serves only this purpose as it is not used in any further stage and is reverted once the next stage is dispatched.
Afterwards, as the CAB file has already been expanded, it is deleted from %TEMP%. The expanded executable file is run, and the original script is deleted to cover its tracks. Finally, the date is changed back to the current date.
Figure 13: Spawning more command lines.
An interesting move by the malware authors is to use cmd /c to run commands from the command line, as shown in Figure 13. This is most likely an attempt to break behavioural detections by recursively spawning new command line instances.
Even if the previous step is skipped and the current user is not the admin, the next step is to run the expanded PE file. First, the script deletes a scheduled task, Microsoft Windows DOM object helper. This is done to ensure that a new task in the scheduler, pointing to the expanded PE file, will execute after exactly one minute. Once the task is scheduled, the malware will try to cover its tracks again by deleting the CAB file from the %TEMP% directory.
Figure 14: Creating schtask job.
In the new version of the VBS a new function for securing persistence was added, starting on 22 January 2019. The script creates a new LNK file in Startup with the name WindowsUpdate.lnk. This LNK file runs the expanded PE file after startup to ensure the executable will be run after reboot.
Figure 15: A LNK file is created to add persistence.
All the Visual Basic scripts were digitally signed with a valid signature, which allows them to be started even in protected environments such as a company network.
Figure 16: Valid VBS digital signature.
Figure 17: Valid VBS digital signature.
Our blog post about the malware [1] was published on 16 February 2019. A few hours later, we found the first completely redesigned Visual Basic script. The file size had been reduced to ~ 4-5KB and the script no longer contained a digital signature or any embedded file. Instead, the new VBS works as a bot that downloads and runs the next stage, and can also delete itself on command.
At the beginning, information about the infected device (HW and ID info) is retrieved by the script. A simple GET request with IP address, HW info and ID info as parameters is then used to establish communication with a C&C server.
Figure 18: Get information about targeted device.
Figure 19: Communication with C&C.
All IP addresses used in the scripts are hosted on hostings belonging to DigitalOcean, LLC.
If the d command is received from the C&C server, the VBS deletes itself, sleeps for a while and kills WScript.
Figure 20: Delete command.
If the pr command is received, the script checks for two additional parameters: a URL and a file name. The function then tries to download the file from the provided URL, saves the file and runs it afterwards.
Figure 21: Download and run command.
This stage was eliminated in the latest version of the malware. The CAB file was used to reduce the size of embedded code inside the VBS. The CAB format has several nice features, e.g. it can easily be unpacked on Windows out of the box without any additional tooling.
As mentioned previously, the CAB file is extracted into %TEMP% using expand.exe.
Figure 22: CAB file expand.
We have seen two versions of the fourth stage of Rietspoof so far. They differ mostly in terms of the communication protocol. This stage has the capabilities of a simple bot: it can download/upload files, start processes, or initiate a self-destruct function. The C&C server also seems to have implemented basic geolocation based on IP address. We didn’t receive any ‘interesting’ commands when we tried to communicate with it from our lab network; however, when we moved our fake client (virtually) to the USA, we received a command containing the next stage.
We noticed that the development of this fourth stage is rapidly evolving, sometimes running two different branches at once. During our analysis, the communication protocol was modified several times and other new features were added. For example, string obfuscation was supported in earlier versions, implemented several days later, and then on 23 January we saw samples that rolled back some of these changes. Newer versions also support the command line switch /s, used to install themselves as a service named windmhlp.
If either the bot is blocked by geolocation or there is currently no ongoing distribution, the communication has a simple structure:
Req: client_hello (deprecated in version 2)
Res: client_hello (deprecated in version 2)
Req: ID
Res: OK or HARDWARE
Req: HW (if previous response was HARDWARE)
Res: OK
The command HARDWARE is sent only if the sent client ID is seen for the first time. The command OK always results in termination of the communication. This simple protocol is executed periodically every several minutes.
The first version of the fourth-stage communication uses a rather simplistic protocol. At first, a key and initialization vector are generated by a handshake that consists of a message and a response, both 32 random bytes, and a four-byte CRC32 checksum. Afterwards, the random bytes are XOR’ed together, and applying SHA256 on the result yields the key. Similarly, applying MD5 on the SHA256 digest yields the initialization vector. From now on, these parameters are used to encrypt messages by AES-CBC. Note that the padding function is strangely designed: the last block is padded to 16 bytes, if necessary, and another 16 zero-bytes are always appended after the last block.
Figure 23: Initial handshake and the subsequent key generation. Note that there is a check for port selector in between these two blocks, which is not shown.
Figure 24: String “HELLO\n”, which is obfuscated and subsequently deobfuscated – obfuscation placeholder.
The communication starts with client_hello, a message simply containing “HELLO\n” that expects “HELLO\n” as a reply (actually “HELLO\n\n\n\n\n\n…” was always the reply). Then, the client sends a command “ID:<MD5 of adapter MAC address>2.10\n”. The response OK, HARDWARE, or a more powerful command is received. In the former, the communication ends and the communication loop sleeps for two to five minutes. The response HARDWARE induces the request “HW:<OS info> CPU<CPU info> RAM: <RAM info> USER: <process privileges>”, with process privileges being either ‘admin’ (the process has administrator privileges) or ‘user’ (otherwise). Again, after this message the response OK is received, similarly ending the communication.
Figure 25: Communication with C&C.
One of six alternative commands may follow instead of OK:
| DEL:<filename> | Delete file, the filename is prefixed with the location of %TEMP% |
| RUN:<filename> | Create process with the file as lpCommandLine, the filename is prefixed with the location of %TEMP% |
| DWN:<filename> | Download a file, if the filename has the suffix .upgrade then dump VBS update script which replaces the malware with a newer version |
| UPL:<filename> | Upload file from %TEMP% |
| DAR:<filename> | Download, save to %TEMP%/<filename> and execute |
| DSF:\n | Delete itself |
The second version of the fourth stage of Rietspoof also uses a rather similar protocol with a few new additions. The second version tries to communicate over HTTP/HTTPS unless a proxy is set up, in which case it resorts to raw TCP. This new version also eschews the initial handshake as it uses a hard-coded string, M9h5an8f8zTjnyTwQVh6hYBdYsMqHiAz, instead of XOR’ing two random strings. Again, this string is put through SHA256, yielding a key, and SHA256 composed with MD5, yielding an initialization vector. These parameters are used to encrypt messages by AES-CBC.
Figure 26: Obfuscated “HELLO\n” string.
The HTTP GET requests generated by the malware are more or less ordinary with the exception of three headers that may be present. An example of the HTTP request is below. Note that the Content‑MD5 header is not mandatory; moreover, the Content-MD5 header is used in a custom and standard non-compliant way. Also, the User-agent string is hard coded in the binary.
GET /<path>?<GET data> HTTP/1.1
Host:<domain>
Connection:close
Content-MD5:<base64 encoded message>
User-agent:Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1
Fortunately for us, the old protocol is still present for cases in which an HTTP proxy is used. We believe that this may serve as a protection against trivial man-in-the-middle attacks that could be utilized during analysis of the malware. However, in our case, it allows us to deploy a new tracking script with very few modifications, as only the key agreement protocol has been changed.
This stage tries to establish an authenticated channel through NTLM protocol over TCP with the C&C server, the IP address of which is hard coded.
Figure 27: Initiate NTLM authentication.
Figure 28: Main authentication and communication loop.
Afterwards, a communication with the C&C server over the aforementioned channel is established and two pipes are created.
The fileless process is created with the API function CreateProcessW. This API function’s attributes are filled with command line cmd and special structure StartupInfo.
The attribute StartupInfo.hStdInput, a standard input handle for the created process, has the handle of the first pipe’s ReadPipe assigned. StartupInfo.hStdOutput and StartupInfo.hStdError, corresponding to the standard output handle and standard error output handle, have the handle of the second pipe’s WritePipe assigned. This allows the downloader to execute the next payload filelessly.
Figure 29: A process is created from the first pipe.
Therefore, the received data from the C&C server is written to the first pipe. This data is then read from the second pipe, which sends it back to the C&C server.
Figure 30: Received data is written to the first pipe and read from the second pipe.
Figure 31: Data is read from the second pipe, which sends it back to the C&C server.
The Rietspoof family was discovered in August 2018 and saw a significant increase in its activity during January 2019. During this time, the developer has used several valid and trusted certificates to sign related files. The payloads have also gone through rather rapid development, namely the implementation of the stage 4 communication protocol has been changed several times. While the data on Rietspoof is extensive, motives and modus operandi are still unknown, as are the intended targets.
From the reaction of Rietspoof’s authors to our blog post and posts on Twitter we can conjecture that they are monitoring security companies, or at least Twitter, as they completely changed the design and infection chain just the day after our blog post was released.
Our research hasn’t revealed whether we’ve uncovered the entire infection chain. Even though there are stages with bot capabilities, they seem to have primarily been designed as droppers. Additionally, the low prevalence and use of geolocation presents other possible unknowns. For instance, we may have missed other samples that are distributed only to a specific IP address range.
[1] Camastra, L.; Širmer, J.; Streda, A.; Obrdlík, L. We’re tracking a new cyberthreat that combines file formats to create a more versatile malware. https://blog.avast.com/rietspoof-malware-increases-activity.
[2] Well-known security identifiers in Windows operating systems. https://support.microsoft.com/en-us/help/243330/well-known-security-identifiers-in-windows-operating-systems.
