Advancements in delivery: Scripting with Nietzsche

Authors:

Jozsef Gegeny, Senior Security Researcher

Norbert Biro, Senior Security Researcher

Robert Neumann, Head, Acronis TRU Labs

The role of delivery chains has become ever so important in the past decade. Threat actors went from simple delivery via a malicious email attachment or drive-by download to having multiple intermediate steps prior to deploying their final payload. These additional steps were all intended to get around the deployed security solutions and make delivery of that payload uninterrupted; however, due to their often-unnecessary complexity, they also pose additional risks. Just like traditional chains, if they break at any point, continuity is forever lost.

We’ve recently come across a complex delivery chain utilizing multiple script languages with the ultimate goal of deploying high-profile malware families such as the open-source-made DCRat or the Rhadamanthys infostealer.

Our investigation started with the arrival of an email message with an attachment in the form of a RAR archive. The archive — as expected — contains no legitimate content, but a Visual Basic script (VBS) file called "Citación por embargo de cuenta." The filename, while clearly aimed at a Spanish speaking audience, roughly translates to "Summons for account garnishment" in English. It refers to a legal notice related to the seizure or freezing of a bank account due to debt or other financial obligations. The intention is clear: Whoever receives the email shall not hesitate but open the attachment immediately, and with that, the execution of a malicious delivery chain will start.

The malicious VBS file employs nested droppers, resulting in a multistage delivery process. We have divided our analysis into four distinct stages, as shown in the figure below.

The Visual Basic script comes at around 200 KB in size, which is an indication that we are not dealing with some basic, in-house automation script. When we take a closer look, it also immediately becomes evident that we are dealing with obfuscation. The rather unusual size is only partly due to obfuscation, as later analysis will show — it also contains an encoded payload, which will be extracted only in stage three.    

There are different ways to deal with obfuscation: One could manually de-obfuscate, take advantage of Microsoft’s AMSI support, or just ignore it with the promise of being able to catch the final payload when execution reaches that stage. At Acronis, we strongly believe in a multilayered approach when it comes to threat detection. As such, we prefer to neutralize malicious content prior to its execution whenever feasible. Besides our own AMSI support, we also utilize an in-house-developed generic script emulator — based on an abstract syntax tree (AST) concept — to automate de-obfuscation for similar scenarios.

After de-obfuscation, the script becomes much more interpretable by human eyes. The primary function of the initial VBS script is to generate a Windows batch file (BAT) and transfer execution to it. The malicious BAT file will be placed in the user's profile directory:

The VBS script also creates a copy of itself in the same directory:

It comes without surprise that our second stage batch script also employs obfuscation — consistently with the preceding layer.

When executed, the batch file will construct a Base64 encoded string from numerous environment variables with the help of the “set” command. This Base64 string represents a compact PowerShell script, which will be executed using the “-command” argument as if it was typed at the Windows PowerShell command prompt:

Essentially, it drops the decoded Base64 data representing a PowerShell script in the user profile directory as:

and executes it with the following command:

Interestingly, it appears that threat actors made no significant effort to obfuscate this layer, as all text is plain and easily readable:

However, it does contain a few notable quotes, such as:

Most, if not all, of the quotes are from Friedrich Nietzsche, a German philosopher. The quotes are added as comments into the PowerShell script and have no functional purpose. Malware authors might be philosophical after all.

The primary function of this script is to locate the aguwDl.bat file from the previous stages in the user's profile directory, read the last (very lengthy) line of it, remove the marker bytes, and then finally decode and load the resulting payload into memory:

The payload is packed using a custom .NET packer and is heavily obfuscated. During analysis, we identified that it contains two encrypted data blobs within its resource structure.

These data blobs utilize only basic encryption and can be easily decrypted using a byte-by-byte XOR operation with the key 0x78. The decoding of these resources uncovers two additional executables:

One is the main DCRat executable, and the other is a library that supports the packer module in loading and executing the DCRat sample directly in memory, without writing it to disk. This is achieved through a technique known as RunPE, implemented in the helper library. The main DCRat binary is rather outdated by now, but a successful infection is still possible with the help of similar delivery methods.

Delivery chains used in malicious campaigns are continuously evolving and getting more complex. Threat actors are seeking ways to hide their final payload — even if it is just another variant of a popular malware family known to the security industry for years. If they succeed, even dated malware binaries could be executed without intervention, unless the deployed security solution is capable of detecting the presence from memory.

At the same time, the more complex these delivery chains get, there lies additional risk and the opportunity to break them at every step they add, ultimately preventing the loading of whatever payload was intended by their creators.

While analyzing this campaign, we came across a couple of similar ones in which the infection chain was an exact match — as described above — but the final payload differed. Instead of deploying DCRat, the attackers used the Rhadamanthys infostealer and another popular remote access trojan: Remcos.

Acronis Advanced Security + Extended Detection and Response (XDR) successfully detects components used in the attack chain.