VB2019 paper: Spoofing in the reeds with Rietspoof

Jan Sirmer, Luigino Camastra & Adolf Středa

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.


Stage 1: Microsoft Word document

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.

Figure1.png Figure 1: Social engineering.

Once macros are enabled, the information regarding the protected document is deleted and the title ‘Emergency exit map’ is shown.

Figure2.pngFigure 2: Emergency exit map.

The attackers use a simple method in which they delete HeaderFooters and show the hidden text.

Figure3.pngFigure 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.


Stage 2: Visual Basic script

Timeline of development

First version: 7 August 2018

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.

Figure6.png 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.


Visual Basic functionality

The first part of the Visual Basic script is a function for reading and deobfuscating embedded binaries.

Figure7.png 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.

Figure8.pngFigure 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.


Executing PE and covering tracks

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.

Figure13.png 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.


Adding persistence

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.


Digital signature

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.

Figure16.png Figure 16: Valid VBS digital signature.


Figure 17: Valid VBS digital signature.


Reaction to our blog post

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.

Figure18.pngFigure 18: Get information about targeted device.

Figure19.pngFigure 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.

Figure20.pngFigure 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.

Figure21.pngFigure 21: Download and run command.


Stage 3: CAB file

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.


Stage 4: Dropped bot

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.



  • 15 January: Obfuscation placeholders, communication protocol v1
  • 18 January: Implemented obfuscation, service installation, communication protocol v2
  • 22 January: Obfuscation scrapped, communication protocol v1
  • 23 January: Obfuscation scrapped, communication protocol v1, service installation

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


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.


Communication protocol v1

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.

Figure23.pngFigure23.1.pngFigure 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.

Figure25.pngFigure 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


Communication protocol v2

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.

Figure26.pngFigure 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
Content-MD5:<base64 encoded message>
User-agent:Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20061204 Firefox/

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.


Stage 5: Downloader

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.

Figure27.pngFigure 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.

Figure29.pngFigure 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.

Figure30.0.pngFigure30.1.pngFigure 30: Received data is written to the first pipe and read from the second pipe.

Figure31.0.pngFigure31.1.pngFigure 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.

Download PDF



Latest articles:

Nexus Android banking botnet – compromising C&C panels and dissecting mobile AppInjects

Aditya Sood & Rohit Bansal provide details of a security vulnerability in the Nexus Android botnet C&C panel that was exploited to compromise the C&C panel in order to gather threat intelligence, and present a model of mobile AppInjects.

Cryptojacking on the fly: TeamTNT using NVIDIA drivers to mine cryptocurrency

TeamTNT is known for attacking insecure and vulnerable Kubernetes deployments in order to infiltrate organizations’ dedicated environments and transform them into attack launchpads. In this article Aditya Sood presents a new module introduced by…

Collector-stealer: a Russian origin credential and information extractor

Collector-stealer, a piece of malware of Russian origin, is heavily used on the Internet to exfiltrate sensitive data from end-user systems and store it in its C&C panels. In this article, researchers Aditya K Sood and Rohit Chaturvedi present a 360…

Fighting Fire with Fire

In 1989, Joe Wells encountered his first virus: Jerusalem. He disassembled the virus, and from that moment onward, was intrigued by the properties of these small pieces of self-replicating code. Joe Wells was an expert on computer viruses, was partly…

Run your malicious VBA macros anywhere!

Kurt Natvig wanted to understand whether it’s possible to recompile VBA macros to another language, which could then easily be ‘run’ on any gateway, thus revealing a sample’s true nature in a safe manner. In this article he explains how he recompiled…

Bulletin Archive

We have placed cookies on your device in order to improve the functionality of this site, as outlined in our cookies policy. However, you may delete and block all cookies from this site and your use of the site will be unaffected. By continuing to browse this site, you are agreeing to Virus Bulletin's use of data as outlined in our privacy policy.