{
	"id": "67aa4863-b466-4f2a-addb-17ae595fd62a",
	"created_at": "2026-04-06T00:12:32.820028Z",
	"updated_at": "2026-04-10T03:20:16.076853Z",
	"deleted_at": null,
	"sha1_hash": "aa17232bea898ce8b064e36eec08cbef6161c482",
	"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": 1765299,
	"plain_text": "Spoofing in the reeds with Rietspoof\r\nBy Threat Research TeamThreat Research Team\r\nArchived: 2026-04-05 15:08:02 UTC\r\nWe’re tracking a new cyberthreat that combines file formats to create a more versatile malware.\r\nAuthored by: Luigino Camastra, Jan Širmer, Adolf Středa and Lukáš Obrdlík\r\nSince August 2018, we have been monitoring a new malware family we’re calling Rietspoof.  Rietspoof is a new\r\nmulti-stage malware that exhibits some very striking features and capabilities. When we began tracking Rietspoof,\r\nit was updated about once a month. However, in January 2019, we noticed the update cadence change to daily.\r\nRietspoof utilizes several stages, combining various file formats, to deliver a potentially more versatile malware.\r\nOur data suggests that the first stage was delivered through instant messaging clients, such as Skype or Live\r\nMessenger. It delivers a highly obfuscated Visual Basic Script with a hard-coded and encrypted second stage  — a\r\nCAB file. The CAB file is expanded into an executable that is digitally signed with a valid signature, mostly using\r\nComodo CA. The .exe installs a downloader in Stage 4.\r\nWhat’s interesting to note, is that the third stage uses a simple TCP protocol to communicate with its C\u0026C, whose\r\nIP address is hardcoded 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, and in a second version it was 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\r\nleverage HTTP/HTTPS requests. It is uncommon to see a C\u0026C communication protocol being modified to such\r\nan extent, given the level of effort required to change the communication protocol. While it is common to change\r\nobfuscation methods, C\u0026C communication usually remains relatively constant in most malware.\r\nThis downloader uses a homegrown protocol to retrieve another stage (Stage 4) from a hard-coded address. While\r\nStage 3 protocol includes bot capabilities, Stage 4 acts as a designated downloader only.\r\nAdditionally, the C\u0026C server communicates only with IP addresses set to USA which leads us to the hypothesis\r\nthat we are working with a specifically targeted attack or the attackers are using the USA IP range only for testing\r\nreasons.  And, it is possible that there are more stages that haven’t been revealed yet. Here are the results of our\r\nfull analysis to date.\r\nVBS deobfuscate \u0026 drop embedded file\r\nThe first part of the Visual Basic script is a function for reading and deobfuscating embedded binaries.\r\nhttps://decoded.avast.io/threatintel/spoofing-in-the-reeds-with-rietspoof/\r\nPage 1 of 10\n\nFrom this snippet, it is immediately obvious that the script starts reading code at a specific offset deobfuscating\r\nthe CAB file and readying it for the next stage. The code is, character by character, converted to its ANSI value\r\nand added to the countervariable. At every step, the counter is XORed with val_01 (hard-coded to 15) and\r\nappended to already decoded bytes. Interestingly, at every step, the string var_str_01is also appended\r\nto var_str_02.\r\nAfter this step, the var_str_02  is used as a parameter for a new function. The second parameter is TempPath with\r\nthe following filename:\r\nIn this stage, the CAB file is saved to the machine’s Temp folder under the name “JSWdhndk.sjk.” The following\r\nstage needs to be extracted from it, which is accomplished by using expand.exe:\r\n \r\nExecuting PE and covering tracks\r\nThe script first checks if the logged user is an Admin by simply reading the registry key “HKEY_USERS\\S-1-5-\r\n19\\Environment\\TEMP”. In case of success it set func_read_Registry to True\r\nWhen this flag is set to True, the VBS changes the date to 01-01-2109, deletes the CAB file from %TEMP%, runs\r\nthe expanded executable file, and deletes the original script to cover its tracks. And, then, it change the date back\r\nto the actual date. This interim date with the year 2109 is not used in the script not dropped files. At the beginning,\r\nwe thought this was just a typo and the intended interim date was 01-01-2019 but this hypothesis was not\r\nconfirmed.\r\nAn interesting move from the malware authors is to use cmd /c to run commands from the command line.  Look at\r\nthe description of this command:\r\nhttps://decoded.avast.io/threatintel/spoofing-in-the-reeds-with-rietspoof/\r\nPage 2 of 10\n\nThis is most likely an attempt to break behavior detections by spawning more command lines with carried out\r\ncommands.\r\nEven if the previous step is skipped, if the current user is not the admin, the next step is to run the expanded PE\r\nfile. At first, the script deletes a scheduled task Microsoft Windows DOM object helper.  This is done by the\r\nmalware authors to be sure that they can create a new value in schedule tasks pointing to the expanded PE file\r\nwhich was expanded from the previous stage; it is set to execute after one minute. Then the CAB file is deleted\r\nfrom %TEMP% directory.\r\nAdding persistence\r\nIn the new version of the VBS, , the malware authors added a new function for persistence starting on January 22,\r\n2019. The script creates a new LNK file in startup with the name WindowsUpdate.lnk. This lnk file runs an\r\nexpanded PE file after startup to ensure the executable will run if the machine is rebooted.\r\n \r\nSignature\r\nAlmost every version of the VBS file contains a new certificate, for example:\r\nWhen we simply transform this block of code from base64 to hex, and then parse this ASN.1 hex string, we obtain\r\nthe serial number of this certificate:\r\nhttps://decoded.avast.io/threatintel/spoofing-in-the-reeds-with-rietspoof/\r\nPage 3 of 10\n\nMost certificates are issued by COMODO or Sectigo\r\nStage 3 – Dropped bot\r\nSo far, we have seen two versions of the third stage of Rietspoof, observing they differ mostly in terms of\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 geofencing\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 virtually moved our fake client to the USA, we received a command\r\ncontaining the next stage.\r\nWe noticed that development of this third stage is rapidly evolving, sometimes running two different branches at\r\nonce. During our analysis, the communication protocol was modified several times and new features were added.\r\nFor example, string obfuscation was supported in earlier versions, implemented several days later, and then on the\r\n23rd of January, we saw samples that rolled back some of these changes. Newer versions also support the\r\ncommand line switch “/s,” used to install themselves as a service named “windmhlp”.\r\nTimeline\r\n15.1. Obfuscation placeholders, communication protocol v1\r\n18.1. Implemented obfuscation, service installation, communication protocol v2\r\n22.1. Obfuscation scrapped, communication protocol v1\r\n23.1. Obfuscation scrapped, communication protocol v1, service installation\r\nThe bot is either blocked by geofencing or there’s 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\nhttps://decoded.avast.io/threatintel/spoofing-in-the-reeds-with-rietspoof/\r\nPage 4 of 10\n\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”\r\nalways results in communication termination. This simple protocol is executed periodically every several minutes.\r\nCommunication protocol v1\r\nThe first version of the third-stage communication uses a rather simplistic protocol. At first, a key and\r\ninitialization vector is generated by a handshake that consists of a message and a response, both 32 random bytes\r\nand a 4-byte CRC32 checksum. Afterwards, the random bytes are xor-ed together, and applying SHA256 on the\r\nresult yields the key. Similarly, applying MD5 on the SHA256 digest yields the initialization vector. From now on,\r\nthese parameters are used to encrypt messages by AES-CBC. Note that the padding function is strangely designed:\r\nthe last block is padded to 16 bytes, if necessary, and another 16 zero-bytes are always appended after the last\r\nblock.\r\nInitial handshake and the subsequent key generation: there’s a check for port array, which is not shown, overflow\r\nin-between these two blocks.\r\nhttps://decoded.avast.io/threatintel/spoofing-in-the-reeds-with-rietspoof/\r\nPage 5 of 10\n\nString “HELLO\\n” that 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”. Either a response “OK”, “HARDWARE”, or a more powerful command is\r\nreceived. In the former, the communication ends and the communication loop sleeps for two to five minutes. The\r\nresponse “HARDWARE” induces a request “HW:\u003cOS info\u003e CPU\u003cCPU info\u003e RAM: \u003cRAM info\u003e USER:\r\n\u003cprocess privileges\u003e”, process privileges being either “admin” (the process has administrator privileges) or “user”\r\n(otherwise). Again, after this message a response “OK” is received, similarly ending the communication.\r\nOne of six alternative commands may follow instead of OK:\r\n \r\nCommunication protocol v2\r\nThe second version of the third 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 hardcoded string\r\n“M9h5an8f8zTjnyTwQVh6hYBdYsMqHiAz” instead of XORing 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\nhttps://decoded.avast.io/threatintel/spoofing-in-the-reeds-with-rietspoof/\r\nPage 6 of 10\n\nObfuscated “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 Content-MD5 header is not mandatory;\r\nmoreover, the Content-MD5 header is used in a custom and standard non-compliant way. Also, the User-agent\r\nstring is hard-coded in the binary.GET  /\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\n \r\nFortunately for us, the old protocol is still present for cases when an HTTP proxy is used. We believe that this may\r\nserve 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 4 – Downloader\r\nThis stage tries to establish an authenticated channel through NTLM protocol over TCP with its C\u0026C whose IP\r\naddress is hardcoded.\r\nInitiate NTLM authentication\r\nhttps://decoded.avast.io/threatintel/spoofing-in-the-reeds-with-rietspoof/\r\nPage 7 of 10\n\nMain loop of authentication and receiving data from C\u0026C server\r\nAfterwards it starts communicating with the C\u0026C over the aforementioned channel with the intent of recovering\r\neither another stage or possibly the final payload.\r\nConclusion\r\nAs you have read above, this new malware, Rietspoof, has had a significant increase in its activity during January\r\n2019. During this time, the developer has used several valid certificates to sign related files. Also, the payloads\r\nwent through development, namely changing the implementation of the Stage 3 communication protocol several\r\ntimes. While the data on Rietspoof is extensive, motives and modus operandi are still unknown, as are the\r\nintended targets. And, to date, the malware-infected files are rarely being detected by most antivirus software.\r\nOur research still cannot confirm if we’ve uncovered the entire infection chain. While the malware has bot\r\ncapabilities, it seems to have been primarily designed as a dropper. Additionally, the low prevalence and use of\r\ngeofencing signifies other possible unknowns. For instance, we may have missed other samples that are\r\ndistributed only to a specific IP address range.\r\nWe are not sharing IoCs publicly, but, if you are able to prove to Avast that you are an anti-malware analyst or\r\nresearcher, we will make the IoCs available to you. In this case feel free to contact\r\n @n3ph8t3r, @StredaAdolf and @sirmer_jan on Twitter.\r\nUpdate 2/20/19:\r\nThanks to the Malware Hunter Team, we received information about the first stage of Rietspoof. It seems that\r\nRietspoof was spread using a Microsoft Word document with macros. The document acts as a dropper and a\r\nrunner for the aforementioned VBS. Upon initial inspection the document shows an almost traditional image that\r\nis used to persuade users to enable macros, as can be seen below:\r\nhttps://decoded.avast.io/threatintel/spoofing-in-the-reeds-with-rietspoof/\r\nPage 8 of 10\n\nOnce macros are enabled, the information regarding the protected document is deleted and a Title “Emergency exit\r\nmap” is shown.\r\nOnce macros are enabled, the information regarding the protected document is deleted and a title “Emergency exit\r\nmap” is shown.\r\nAfterwards, this part of the script deobfuscates the VBS and saves it onto the machine, executing wscript.exe with\r\na parameter\r\nc:\\users\\NAME\\appdata\\roaming\\microsoft\\word\\startup\\.\\.\\\\Windows\\Cookies\\wordTemplate.vbs, that is a path\r\nleading to the dropped VBS, to execute the payload.\r\nThe Visual Basic script, that we described earlier, is embedded in the document as a base64 string encoded in hex.\r\nhttps://decoded.avast.io/threatintel/spoofing-in-the-reeds-with-rietspoof/\r\nPage 9 of 10\n\nA group of elite researchers who like to stay under the radar.\r\nSource: https://decoded.avast.io/threatintel/spoofing-in-the-reeds-with-rietspoof/\r\nhttps://decoded.avast.io/threatintel/spoofing-in-the-reeds-with-rietspoof/\r\nPage 10 of 10",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://decoded.avast.io/threatintel/spoofing-in-the-reeds-with-rietspoof/"
	],
	"report_names": [
		"spoofing-in-the-reeds-with-rietspoof"
	],
	"threat_actors": [],
	"ts_created_at": 1775434352,
	"ts_updated_at": 1775791216,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/aa17232bea898ce8b064e36eec08cbef6161c482.pdf",
		"text": "https://archive.orkl.eu/aa17232bea898ce8b064e36eec08cbef6161c482.txt",
		"img": "https://archive.orkl.eu/aa17232bea898ce8b064e36eec08cbef6161c482.jpg"
	}
}