We recently found a ransomware variant that not only holds the victim’s machine and data hostage until a ransom is paid, but also exploits the compromised machine as part of a potential DDOS attack. This means that while the victim is unable to access their endpoint, that same endpoint is being used to deny service to another victim. Two attacks for the price of one.
In order to achieve this, the attacker uses a weaponized Office document, a type of file-less attack method. In our latest Advanced Endpoint Threat Report, we noted that weaponized documents are dominating the threat landscape. The reason this is such a popular technique is that most antivirus and “next-gen” antivirus vendors are completely blind to file-less attack methods.
In this case, attackers exploited Visual Basic to conduct the file-less attack. Visual Basic is one of the most widely used programming languages for scripts and programming today. Visual Basic is built into Microsoft Windows and used for all sorts of automation tasks native to Windows. Because of its widespread use on the Windows platform, it has also become a go-to scripting language for crafting exploits. VBscripts (as well as VBE Files) are often embedded in text documents to allow users to generate reports and conduct other legitimate business related tasks. This same tactic, however, is also used by the black hats to craft weaponized documents that can drop and run malicious executables on the host.
A detailed analysis of the attack is included in the body of this blog post.
This sample has all indications of a typical weaponized document. The key things to look for when distinguishing a harmless document from a weaponized document is the location in which the process runs and the file(s) that it creates.
In the above example, we see that the adversary sent a spear phishing email to the inbox of the victim with a Rich Text Document (.rtf) attached. In many instances, the document and message in the email reflect an invoice or some important information that may be time sensitive or specific to that individual (spear phish). In this case, the document seems to have a generic and possibly computer generated filename. The victim still decided to opened the email and the attached weaponized document, which launched Microsoft Word and initiated the embedded macros.
Before the document can execute a script on the host, it has to gain elevated administrative privileges on the host. In most cases, the user is prompted to allow the macros to run in Microsoft Word, which gives the malicious document the necessary elevated privileges. The macros spawn an elevated command shell on the host, which executes an encoded VBscript. Below is a snippet of the raw code executed in the command shell.
The first thing I noticed when looking at the code is that it seems to be encoded. Obfuscation, the deliberate act of manipulating code to make it difficult for humans to understand, is a common technique among adversaries. The functions and variables in this case all seem to be computer generated. I also noticed there are pieces of code that resemble human readable functions. The font is still randomized using both upper and lowercase text instead of the regular convention of capitalizing the first letter in each word.
To make it easier to read, I reformatted the code using proper line breaks at what seem to be the end of each line. When doing this, I noticed that almost all of the variables that are instantiated before the end of each line are only seen once throughout the code. You can see below that all of the highlighted code are variables that are instantiated but none are seen twice. The sections outlined in red are portions of the code that seem to resemble human readable functions and conditions. Proceeding each of these variables is a VB comment, in the format of “ ‘ x x “ (x’s representing integers). I believe the variables, integers, and comments do not serve any particular purpose and are simply added to confuse the human reader.
Seen below are portions of the script that I formatted to follow regular convention. These portions of the code stand out to me in a few ways, and may also explain some of the characteristics of how the malware behaves. In the first snippet, we see a “FOR” loop that iterates from 1 to half the length of the given variable. Within that FOR loop, we see variables that break down to integers and iterate over the length of the loop. The values are also stored in the object “obj1” (note: I altered the variable name to obj1 for ease of reading).
In the second snippet of code, we see another formatted function that seems to open a text stream and writes that information to a file. Specifically the function opens an object and sets it to a particular variable. Another text file is created and data is written to it in until the end of the stream. Once done, the stream is closed and all the remaining variables are set equal to nothing.
At the end of the code, we see that the entire script is exported to a .vbs file and then executed. We also see this in the console above that the variable name of the function is set to random set (“Jy0reRSTbRCII4=%RANDOM%” seen at the beginning of the code snippet). This random value created a file called “3263.vbs” and executed the script.
After the script is called and executed, it creates another malicious binary “3311.tmp” that is then called and executed. Based on static analysis, the binary seems to be ransomware of the Cerber family.
Dynamic analysis also showed evidence of ransomware. In particular, the binary made changes to the screensaver data in the registry as seen below:
A change like such could allow the system to post a permanent ransom note on the victim’s screen. Unlike typical ransomware this sample exhibits strange network behavior. From the dynamic analysis performed on the binary I noticed the host calling out to a large 255.255.192.0 subnet. The address range starts at 220.127.116.11 and goes to 18.104.22.168. It is unclear if the binary was able to run to completion.
Another thing I noticed is the repetition of a particular sequence of events. A hexadecimal tmp file (with the exception of the second file) is created and the explorer.exe process is subsequently launched.
All these events are child processes of the same malicious file that was originally created (3311.tmp). Please note that the “dnscacheugc.exe” file seen above has the same hash as the 3311.tmp file; just a different filename. I believe this sequence of events is related to the original loop we saw in the VBscript. It is unclear the purpose of these .tmp files as they are not executed anywhere in the dynamic analysis, which leads me to believe the malware did not fully complete its process and deliver the payload.
The observed malware seems to serve multiple purposes. First, it is a typical ransomware binary that encrypts the user’s file system and files while displaying a ransom note. Second, the binary could also be used to carry out a DDoS attack. The observed network traffic looks to be flooding the subnet with UDP packets over port 6892. By spoofing the source address, the host could direct all response traffic from the subnet to a targeted host, causing the host to be unresponsive.