{
	"id": "ba48481d-0552-4b21-8010-1a0f9d6d9f7a",
	"created_at": "2026-04-10T03:21:45.202837Z",
	"updated_at": "2026-04-10T03:22:18.847812Z",
	"deleted_at": null,
	"sha1_hash": "d5a0d56a9038cbfcd076c031ae89438b10089224",
	"title": "Spoofing in the reeds with Rietspoof",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 798060,
	"plain_text": "Spoofing in the reeds with Rietspoof\r\nArchived: 2026-04-10 02:33:18 UTC\r\nJan Sirmer, Luigino Camastra \u0026 Adolf Středa\r\nAvast Software, Czech Republic\r\nTable of contents\r\nAbstract\r\nSince August 2018 we have been monitoring a new malware family, which we have named Rietspoof. Rietspoof is\r\na piece of malware that is multi-staged, using different file types throughout its infection chain. It contains several\r\ntypes of stages – both extractors and downloaders; the fourth stage also contains support for remote-control\r\ncommands. When we began tracking Rietspoof it was being updated approximately once a month. However, in\r\nJanuary 2019 we noticed that the frequency of updates had increased to daily.\r\nIn this paper we will share a detailed analysis of each stage of the malware, starting from the initial Microsoft\r\nWord document serving as stage one. This stage is followed by a rather interestingly built and obfuscated Visual\r\nBasic script (VBS) leading to executable files that serve as both bots and downloaders. We will describe all\r\nrelevant parts of the Visual Basic script, ranging from its unusual anti-behaviour detection tricks to the function\r\nwhich led us to the next stage, a CAB file dropped from the VBS.\r\nThe fourth stage is an executable file expanded from the CAB file. This executable file is digitally signed by a\r\nvalid certificate, usually using Comodo CA. At the end of February, we found samples exhibiting different\r\nbehaviour: a new VBS file with bot capabilities was dropped from the CAB file. The fourth stage serves as a bot\r\nthat also supports a downloader functionality. During our investigation, we noticed that the malware author was\r\nconstantly modifying all the stages. We distilled these changes into a detailed timeline, from which we can\r\nobserve a lot of changes in the whole concept of this malware family, ranging from a reworked C\u0026C\r\ncommunication protocol to a completely rewritten second stage.\r\nIn the fifth stage, the malware author used an interesting dropper technique to deploy fileless malware\r\ndownloaded from the C\u0026C server. The fifth stage utilized the NTLM protocol to provide authentication and\r\nencryption of its communication with the C\u0026C server.\r\nIt is not common to see a C\u0026C communication protocol being modified to such an extent, given the level of effort\r\nrequired to change it. Similarly, we rarely see feature regression in malware – we observed that the obfuscation of\r\nstrings was removed in later versions of the fourth stage. Again, we will look at these changes in detail along with\r\nthe underlying protocols.\r\nAlthough we are monitoring Rietspoof very carefully, our hypothesis is that its authors are still developing this\r\nmalware, and because of this we only have testing samples.\r\nhttps://www.virusbulletin.com/virusbulletin/2020/01/vb2019-paper-spoofing-reeds-rietspoof/\r\nPage 1 of 18\n\nIntroduction\r\nRietspoof utilizes several stages, combining various file formats throughout its infection chain to deliver a\r\npotentially more versatile piece of malware. Our data suggests that the first stage was delivered through email and\r\ninstant messaging clients such as Outlook and Skype. The first stage consists of a Microsoft Word document which\r\nworks as a dropper and runner for a highly obfuscated Visual Basic script containing an encrypted and hard-coded\r\nencrypted CAB file – the third stage. The Visual Basic script is also digitally signed. The CAB file is expanded\r\ninto an executable that is digitally signed with a valid signature, generally using Comodo CA or Sectigo RSA. The\r\nexecutable file downloads and installs a downloader in stage 4.\r\nWhat’s interesting to note is that the fourth stage uses a simple TCP protocol to communicate with its C\u0026C,\r\nwhose IP address is hard coded in the binary. The protocol is encrypted by AES in CBC mode. In one version we\r\nobserved the key being derived from the initial handshake. Later on, a second version appeared; in this case the\r\nkey is derived from a hard-coded string. In version two, the protocol not only supports its own protocol running\r\nover TCP, but it also tries to leverage HTTP/HTTPS requests. It is rather uncommon to see a C\u0026C communication\r\nprotocol being modified to such an extent, given the level of effort required to change it. While it is common to\r\nchange obfuscation methods, the C\u0026C communication protocol usually remains relatively unmodified in most\r\nmalware.\r\nThis downloader uses a home-brew protocol to retrieve another stage (stage 5) from a hard-coded address. While\r\nthe stage 4 protocol includes bot capabilities, stage 5 acts as a designated downloader only.\r\nStage 1: Microsoft Word document\r\nThe first stage of the Rietspoof attack is a malformed Microsoft Word document which is spread through email or\r\ninstant messaging clients. The first stage works as a dropper and runner for a malicious Visual Basic script.\r\nThe document uses standard social engineering techniques to persuade victims to run it with macros enabled.\r\nFigure 1: Social engineering.\r\nhttps://www.virusbulletin.com/virusbulletin/2020/01/vb2019-paper-spoofing-reeds-rietspoof/\r\nPage 2 of 18\n\nOnce macros are enabled, the information regarding the protected document is deleted and the title ‘Emergency\r\nexit map’ is shown.\r\nFigure 2:\r\nEmergency exit map.\r\nThe attackers use a simple method in which they delete HeaderFooters and show the hidden text.\r\nFigure 3: DeleteAllHeaderFooters.\r\n \r\nFigure 4: ShowHiddenText.\r\nAfterwards, the script deobfuscates the VBS and saves it onto the machine. The script is then executed by\r\ninvoking wscript.exe with a parameter\r\nhttps://www.virusbulletin.com/virusbulletin/2020/01/vb2019-paper-spoofing-reeds-rietspoof/\r\nPage 3 of 18\n\nc:\\users\\NAME\\appdata\\roaming\\microsoft\\word\\startup\\.\\.\\\\Windows\\Cookies\\wordTemplate.vbs, which is a path\r\nleading to the dropped VBS.\r\nThe raw Visual Basic script is stored as a Base64-encoded string represented by an array of hex codes.\r\nFigure 5: Execution flow.\r\nStage 2: Visual Basic script\r\nTimeline of development\r\nFirst version: 7 August 2018\r\nThe first version of the VBS that we discovered was probably just a test version of Rietspoof as it contained\r\nalmost no obfuscation. Also, the names of variables and functions correlate with their final functions.\r\n Figure 6: Self explanatory names.\r\nSince version one, each version has been more or less obfuscated and has used different binaryOffset (offset of\r\npayload), xorValue (XOR key) and AppName (dropped binary name) values. Nevertheless, all of them – at least\r\nuntil our blog post [1] was released – showed many similarities.\r\nVisual Basic functionality\r\nThe first part of the Visual Basic script is a function for reading and deobfuscating embedded binaries.\r\nFigure 7: Script reads itself from setup offset.\r\nFrom the snippet shown in Figure 7 it is immediately obvious that the script starts reading code at a specific offset,\r\ndeobfuscating the CAB file and readying it for the next stage. The code is converted, character by character, to its\r\nANSI value and added to the counter variable. At every step, the counter is XOR’ed with val_01 (hard coded to\r\nhttps://www.virusbulletin.com/virusbulletin/2020/01/vb2019-paper-spoofing-reeds-rietspoof/\r\nPage 4 of 18\n\n15) and appended to already decoded bytes. Interestingly, at every step, the string var_str_01 is also appended to\r\nvar_str_02.\r\nFigure 8: CAB\r\ndeobfuscation.\r\nAfter this step, var_str_02 is used as a parameter for a new function. The second parameter is TempPath, with the\r\nfollowing filename:\r\nFigure 9: Dropper function.\r\nFigure 10: Drop CAB file.\r\nAt this stage the CAB file is saved to the machine’s TempPath under the name JSWdhndk.sjk. If we observed one\r\nthe first versions, the name would be data.log instead. The following stage needs to be extracted from it, which is\r\naccomplished by using expand.exe, as shown in Figure 11.\r\nFigure 11: Expand CAB file.\r\nExecuting PE and covering tracks\r\nThe script checks if the user is logged in as admin by reading the registry key “HKEY_USERS\\S-1-5-\r\n19\\Environment\\TEMP”. In case of success, it sets func_read_Registry to True.\r\nhttps://www.virusbulletin.com/virusbulletin/2020/01/vb2019-paper-spoofing-reeds-rietspoof/\r\nPage 5 of 18\n\nFigure 12: Checking if the victim is logged in as admin.\r\nNote that S-1-5-19 belongs to NT Authority and can be accessed only by an admin (as noted in the Microsoft\r\ndocumentation [2]).\r\nWhen this flag is set to True, the VBS changes the date to 01-01-2109. Again, the first version exhibited slightly\r\ndifferent behaviour, using the date 01-01-2099. We can assume this is done to confuse some sandboxes or other\r\nbehaviour-based detection systems and that the first date didn’t work as intended. The interim date with the year\r\n2109(2099) serves only this purpose as it is not used in any further stage and is reverted once the next stage is\r\ndispatched.\r\nAfterwards, as the CAB file has already been expanded, it is deleted from %TEMP%. The expanded executable\r\nfile is run, and the original script is deleted to cover its tracks. Finally, the date is changed back to the current date.\r\nFigure 13: Spawning more command lines.\r\nAn interesting move by the malware authors is to use cmd /c to run commands from the command line, as shown\r\nin Figure 13. This is most likely an attempt to break behavioural detections by recursively spawning new\r\ncommand line instances.\r\nEven if the previous step is skipped and the current user is not the admin, the next step is to run the expanded PE\r\nfile. First, the script deletes a scheduled task, Microsoft Windows DOM object helper. This is done to ensure that a\r\nnew task in the scheduler, pointing to the expanded PE file, will execute after exactly one minute. Once the task is\r\nscheduled, the malware will try to cover its tracks again by deleting the CAB file from the %TEMP% directory.\r\nFigure 14: Creating schtask job.\r\nAdding persistence\r\nhttps://www.virusbulletin.com/virusbulletin/2020/01/vb2019-paper-spoofing-reeds-rietspoof/\r\nPage 6 of 18\n\nIn the new version of the VBS a new function for securing persistence was added, starting on 22 January 2019.\r\nThe script creates a new LNK file in Startup with the name WindowsUpdate.lnk. This LNK file runs the expanded\r\nPE file after startup to ensure the executable will be run after reboot.\r\nFigure 15: A LNK file is created to add persistence.\r\nDigital signature\r\nAll the Visual Basic scripts were digitally signed with a valid signature, which allows them to be started even in\r\nprotected environments such as a company network.\r\n Figure 16: Valid VBS digital signature.\r\nhttps://www.virusbulletin.com/virusbulletin/2020/01/vb2019-paper-spoofing-reeds-rietspoof/\r\nPage 7 of 18\n\nFigure 17: Valid VBS digital signature.\r\nReaction to our blog post\r\nOur blog post about the malware [1] was published on 16 February 2019. A few hours later, we found the first\r\ncompletely redesigned Visual Basic script. The file size had been reduced to ~ 4-5KB and the script no longer\r\ncontained a digital signature or any embedded file. Instead, the new VBS works as a bot that downloads and runs\r\nthe next stage, and can also delete itself on command.\r\nAt the beginning, information about the infected device (HW and ID info) is retrieved by the script. A simple GET\r\nrequest with IP address, HW info and ID info as parameters is then used to establish communication with a C\u0026C\r\nserver.\r\nFigure 18: Get information about targeted device.\r\nFigure 19: Communication with C\u0026C.\r\nAll IP addresses used in the scripts are hosted on hostings belonging to DigitalOcean, LLC.\r\nIf the d command is received from the C\u0026C server, the VBS deletes itself, sleeps for a while and kills WScript.\r\nFigure 20: Delete command.\r\nIf the pr command is received, the script checks for two additional parameters: a URL and a file name. The\r\nfunction then tries to download the file from the provided URL, saves the file and runs it afterwards.\r\nFigure\r\n21: Download and run command.\r\nStage 3: CAB file\r\nThis stage was eliminated in the latest version of the malware. The CAB file was used to reduce the size of\r\nembedded code inside the VBS. The CAB format has several nice features, e.g. it can easily be unpacked on\r\nWindows out of the box without any additional tooling.\r\nhttps://www.virusbulletin.com/virusbulletin/2020/01/vb2019-paper-spoofing-reeds-rietspoof/\r\nPage 8 of 18\n\nAs mentioned previously, the CAB file is extracted into %TEMP% using expand.exe.\r\nFigure 22: CAB file expand.\r\nStage 4: Dropped bot\r\nWe have seen two versions of the fourth stage of Rietspoof so far. They differ mostly in terms of the\r\ncommunication protocol. This stage has the capabilities of a simple bot: it can download/upload files, start\r\nprocesses, or initiate a self-destruct function. The C\u0026C server also seems to have implemented basic geolocation\r\nbased on IP address. We didn’t receive any ‘interesting’ commands when we tried to communicate with it from\r\nour lab network; however, when we moved our fake client (virtually) to the USA, we received a command\r\ncontaining the next stage.\r\nWe noticed that the development of this fourth stage is rapidly evolving, sometimes running two different\r\nbranches at once. During our analysis, the communication protocol was modified several times and other new\r\nfeatures were added. For example, string obfuscation was supported in earlier versions, implemented several days\r\nlater, and then on 23 January we saw samples that rolled back some of these changes. Newer versions also support\r\nthe command line switch /s, used to install themselves as a service named windmhlp.\r\nTimeline\r\n15 January: Obfuscation placeholders, communication protocol v1\r\n18 January: Implemented obfuscation, service installation, communication protocol v2\r\n22 January: Obfuscation scrapped, communication protocol v1\r\n23 January: Obfuscation scrapped, communication protocol v1, service installation\r\nIf either the bot is blocked by geolocation or there is currently no ongoing distribution, the communication has a\r\nsimple structure:\r\nReq: client_hello (deprecated in version 2)\r\nRes: client_hello (deprecated in version 2)\r\nReq: ID\r\nRes: OK or HARDWARE\r\nReq: HW (if previous response was HARDWARE)\r\nRes: OK\r\nThe command HARDWARE is sent only if the sent client ID is seen for the first time. The command OK always\r\nresults in termination of the communication. This simple protocol is executed periodically every several minutes.\r\nCommunication protocol v1\r\nhttps://www.virusbulletin.com/virusbulletin/2020/01/vb2019-paper-spoofing-reeds-rietspoof/\r\nPage 9 of 18\n\nThe first version of the fourth-stage communication uses a rather simplistic protocol. At first, a key and\r\ninitialization vector are generated by a handshake that consists of a message and a response, both 32 random\r\nbytes, and a four-byte CRC32 checksum. Afterwards, the random bytes are XOR’ed together, and applying\r\nSHA256 on the result yields the key. Similarly, applying MD5 on the SHA256 digest yields the initialization\r\nvector. From now on, these parameters are used to encrypt messages by AES-CBC. Note that the padding function\r\nis strangely designed: the last block is padded to 16 bytes, if necessary, and another 16 zero-bytes are always\r\nappended after the last block.\r\nFigure 23: Initial handshake and the subsequent\r\nkey generation. Note that there is a check for port selector in between these two blocks, which is not shown.\r\nhttps://www.virusbulletin.com/virusbulletin/2020/01/vb2019-paper-spoofing-reeds-rietspoof/\r\nPage 10 of 18\n\nFigure 24: String “HELLO\\n”, which is obfuscated and subsequently deobfuscated – obfuscation placeholder.\r\nThe communication starts with client_hello, a message simply containing “HELLO\\n” that expects “HELLO\\n” as\r\na reply (actually “HELLO\\n\\n\\n\\n\\n\\n…” was always the reply). Then, the client sends a command “ID:\u003cMD5 of\r\nadapter MAC address\u003e2.10\\n”. The response OK, HARDWARE, or a more powerful command is received. In the\r\nformer, the communication ends and the communication loop sleeps for two to five minutes. The response\r\nHARDWARE induces the request “HW:\u003cOS info\u003e CPU\u003cCPU info\u003e RAM: \u003cRAM info\u003e USER: \u003cprocess\r\nprivileges\u003e”, with process privileges being either ‘admin’ (the process has administrator privileges) or ‘user’\r\n(otherwise). Again, after this message the response OK is received, similarly ending the communication.\r\nFigure 25: Communication with C\u0026C.\r\nOne of six alternative commands may follow instead of OK:\r\nhttps://www.virusbulletin.com/virusbulletin/2020/01/vb2019-paper-spoofing-reeds-rietspoof/\r\nPage 11 of 18\n\nDEL:\r\n\u003cfilename\u003e\r\nDelete file, the filename is prefixed with the location of %TEMP%\r\nRUN:\r\n\u003cfilename\u003e\r\nCreate process with the file as lpCommandLine, the filename is prefixed with the location\r\nof %TEMP%\r\nDWN:\r\n\u003cfilename\u003e\r\nDownload a file, if the filename has the suffix .upgrade then dump VBS update script\r\nwhich replaces the malware with a newer version\r\nUPL:\r\n\u003cfilename\u003e\r\nUpload file from %TEMP%\r\nDAR:\r\n\u003cfilename\u003e\r\nDownload, save to %TEMP%/\u003cfilename\u003e and execute\r\nDSF:\\n Delete itself\r\nCommunication protocol v2\r\nThe second version of the fourth stage of Rietspoof also uses a rather similar protocol with a few new additions.\r\nThe second version tries to communicate over HTTP/HTTPS unless a proxy is set up, in which case it resorts to\r\nraw TCP. This new version also eschews the initial handshake as it uses a hard-coded string,\r\nM9h5an8f8zTjnyTwQVh6hYBdYsMqHiAz, instead of XOR’ing two random strings. Again, this string is put\r\nthrough SHA256, yielding a key, and SHA256 composed with MD5, yielding an initialization vector. These\r\nparameters are used to encrypt messages by AES-CBC.\r\nFigure 26: Obfuscated “HELLO\\n” string.\r\nThe HTTP GET requests generated by the malware are more or less ordinary with the exception of three headers\r\nthat may be present. An example of the HTTP request is below. Note that the Content‑MD5 header is not\r\nmandatory; moreover, the Content-MD5 header is used in a custom and standard non-compliant way. Also, the\r\nUser-agent string is hard coded in the binary.\r\nhttps://www.virusbulletin.com/virusbulletin/2020/01/vb2019-paper-spoofing-reeds-rietspoof/\r\nPage 12 of 18\n\nGET /\u003cpath\u003e?\u003cGET data\u003e HTTP/1.1\r\nHost:\u003cdomain\u003e\r\nConnection:close\r\nContent-MD5:\u003cbase64 encoded message\u003e\r\nUser-agent:Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1\r\nFortunately for us, the old protocol is still present for cases in which an HTTP proxy is used. We believe that this\r\nmay serve as a protection against trivial man-in-the-middle attacks that could be utilized during analysis of the\r\nmalware. However, in our case, it allows us to deploy a new tracking script with very few modifications, as only\r\nthe key agreement protocol has been changed.\r\nStage 5: Downloader\r\nThis stage tries to establish an authenticated channel through NTLM protocol over TCP with the C\u0026C server, the\r\nIP address of which is hard coded.\r\nFigure 27: Initiate NTLM\r\nauthentication.\r\nhttps://www.virusbulletin.com/virusbulletin/2020/01/vb2019-paper-spoofing-reeds-rietspoof/\r\nPage 13 of 18\n\nFigure 28: Main authentication and communication loop.\r\nAfterwards, a communication with the C\u0026C server over the aforementioned channel is established and two pipes\r\nare created.\r\nThe fileless process is created with the API function CreateProcessW. This API function’s attributes are filled with\r\ncommand line cmd and special structure StartupInfo.\r\nThe attribute StartupInfo.hStdInput, a standard input handle for the created process, has the handle of the first\r\npipe’s ReadPipe assigned. StartupInfo.hStdOutput and StartupInfo.hStdError, corresponding to the standard output\r\nhandle and standard error output handle, have the handle of the second pipe’s WritePipe assigned. This allows the\r\ndownloader to execute the next payload filelessly.\r\nhttps://www.virusbulletin.com/virusbulletin/2020/01/vb2019-paper-spoofing-reeds-rietspoof/\r\nPage 14 of 18\n\nFigure 29: A process is created\r\nfrom the first pipe.\r\nTherefore, the received data from the C\u0026C server is written to the first pipe. This data is then read from the\r\nsecond pipe, which sends it back to the C\u0026C server.\r\nhttps://www.virusbulletin.com/virusbulletin/2020/01/vb2019-paper-spoofing-reeds-rietspoof/\r\nPage 15 of 18\n\nFigure 30: Received data is written to\r\nthe first pipe and read from the second pipe.\r\nhttps://www.virusbulletin.com/virusbulletin/2020/01/vb2019-paper-spoofing-reeds-rietspoof/\r\nPage 16 of 18\n\nFigure 31: Data is read from the second pipe,\r\nwhich sends it back to the C\u0026C server.\r\nConclusion\r\nThe Rietspoof family was discovered in August 2018 and saw a significant increase in its activity during January\r\n2019. During this time, the developer has used several valid and trusted certificates to sign related files. The\r\npayloads have also gone through rather rapid development, namely the implementation of the stage 4\r\ncommunication protocol has been changed several times. While the data on Rietspoof is extensive, motives and\r\nmodus operandi are still unknown, as are the intended targets.\r\nFrom the reaction of Rietspoof’s authors to our blog post and posts on Twitter we can conjecture that they are\r\nmonitoring security companies, or at least Twitter, as they completely changed the design and infection chain just\r\nthe day after our blog post was released.\r\nOur research hasn’t revealed whether we’ve uncovered the entire infection chain. Even though there are stages\r\nwith bot capabilities, they seem to have primarily been designed as droppers. Additionally, the low prevalence and\r\nuse of geolocation presents other possible unknowns. For instance, we may have missed other samples that are\r\ndistributed only to a specific IP address range.\r\nReferences\r\n[1] Camastra, L.; Širmer, J.; Streda, A.; Obrdlík, L. We’re tracking a new cyberthreat that combines file formats to\r\ncreate a more versatile malware. https://blog.avast.com/rietspoof-malware-increases-activity.\r\n[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.\r\nhttps://www.virusbulletin.com/virusbulletin/2020/01/vb2019-paper-spoofing-reeds-rietspoof/\r\nPage 17 of 18\n\nSource: https://www.virusbulletin.com/virusbulletin/2020/01/vb2019-paper-spoofing-reeds-rietspoof/\r\nhttps://www.virusbulletin.com/virusbulletin/2020/01/vb2019-paper-spoofing-reeds-rietspoof/\r\nPage 18 of 18",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.virusbulletin.com/virusbulletin/2020/01/vb2019-paper-spoofing-reeds-rietspoof/"
	],
	"report_names": [
		"vb2019-paper-spoofing-reeds-rietspoof"
	],
	"threat_actors": [],
	"ts_created_at": 1775791305,
	"ts_updated_at": 1775791338,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/d5a0d56a9038cbfcd076c031ae89438b10089224.pdf",
		"text": "https://archive.orkl.eu/d5a0d56a9038cbfcd076c031ae89438b10089224.txt",
		"img": "https://archive.orkl.eu/d5a0d56a9038cbfcd076c031ae89438b10089224.jpg"
	}
}