When analyzing suspicious domains, Dropbox is one of the brands that is usually under scrutiny. Typically, we are looking at a phishing page that is pretending to be Dropbox in order to steal user credentials. Other times, as with most cloud content hosting sites, we find shared links hosted on Dropbox that lead to a malicious file.
In this blog post, as members of the Security Research Analyst team, we’re going to run through an analysis we did of a file that was hosted on a Dropbox shared link that turned out to be using some pretty interesting obfuscation techniques in order to hide the real intentions of the file. The file was initially received as a zip archive. Inside was what appeared to be a .scr file, or a screensaver file.
A New Screensaver
We started out doing some typical forensic steps by running the file against pestr in REMnux. From this, we were able to determine that it contains a couple of .exe and .vbs files. This led us to the conclusion that the file wasn’t packed.
The file was then run through CFF Explorer to see if it was a screensaver or just posing as one. The PE header starts with MZ which indicates that it is an executable.
The file was probably renamed from .exe to .scr to either evade security solutions or to distribute it as a free screensaver. The .scr file was unzipped and it had a whopping 59 files within it. When all the files from the unzipped scr file were inspected, each of them were of various file types. We then realized that those were not the real extensions, but just another trick to evade analysis. Most of these were actually just text files.
Let’s start with ‘csn.vbs’. When dealing with malware, vbs files which are usually launched through macros can contain malicious code that furthers the infection process usually by contacting a domain or IP address to download additional malware. Upon opening the file, it was observed that the whole file was filled with Chinese text.With further inspection we realized that this was merely used as an obfuscation method to hide the actual code, thus making it harder to detect.
After filtering out all the Chinese text, we obtained the function from this file.
The vb script calls a file named agj.exe and ‘gjm=loo’ is passed as a parameter to it. Our next step was to inspect these two files.
Would you like some more files?
When analyzing agj.exe, we went back to the parent folder to look for it, and realized the file was not present in the set of 59 files. Usually in such cases, URLs will later be contacted through a powershell command when another file is executed in order to download additional files. However, in this analysis we didn’t observe that behavior. So where was the file? After enabling the Windows OS to ‘show hidden files’, voila! We found agj.exe. The malware author was using another technique to hide their tracks.
We then started inspecting gjm=loo. We looked into the properties of the file, and noticed that the file size was 215 MB. But the original scr file was only 1.25 MB. The malware authors must have used some compression techniques to compress the 59 files into one. The smaller file size makes the file easier to distribute and thus infect more victims.
When inspecting the ‘gjm=loo’ file, we again saw that it was filled with Chinese text. However, this time the file was too large that it crashed every possible GUI editor we tried. Manually removing the Chinese characters like the previous time was out of the question since this contained more than 2,045,440 lines. A python regex script was made to try to handle this, but also crashed. We opened it in powershell and found out that a set of characters repeated every 9,200 lines. Every command was also preceded by ‘#ce’. We made use of this to filter out only the actual code.
Upon inspecting the code, we noticed that the ‘gjm=loo’ file refers to another file, ‘mgi.cpl’.
The .cpl is a control panel item. Again, it wasn’t actually a cpl file, but a text file in which the extension was renamed. A lot of the code in the ‘gjm=loo’ file were AutoIt functions. AutoIt is a scripting language designed to automate functions in the Windows UI as well as for use with general scripting tasks.
AutoIt in this case is probably used to prevent antivirus systems from recognizing the malware’s signature. The code is compiled and run as a valid AutoIt process with the malicious payload loaded into an AutoIt process memory space. Malware authors leverage and abuse trusted processes to hide and masquerade their malware.
The ‘gjm=loo’ file has a slew of global variables and has the typical traits of malware, using suspicious functions and variables. We initially thought that these may be some address locations that the variables point to. However, digging deeper we realized that these are in fact keycode constants. Keycode constants/values can be used anywhere in code in place of the actual values. For instance, the first variable declared equals 0x1. This is a keycode constant for a left mouse button. So when this variable is invoked somewhere in the program, it causes the left button to be clicked.
Some of these global variables also pointed to cryptographic algorithm identifiers. For example, 0x00008001 is the MD2 hashing algorithm. All these cryptographic techniques are used at a later stage by the attacker. There were more than 12 different functions here, all of which were called by one main function. When we skimmed through the code, VMwaretray.exe, VBoxService.exe and other such keywords caught our attention immediately. These are traits of typical sandbox evading malware. If the malware figures out that it is executing in a virtual machine, it stops execution immediately or exhibits a fake behavior.
The code also had a function to ensure persistence. This particular sample achieved persistence by writing itself to the registry. The adversary is trying to maintain their foothold. This is seen below.
The abuse of WScript has massively increased over the years. Malware authors make extensive use of this due to its ability to interpret the .js and .vbs files. This particular malware uses WScript to invoke the vb script.
The actual trojan DLL was made by the following function.
The function makes a call to the file ‘mgi.cpl’ and extracts the trojan code in between the strings “Troj” and “ FinTroj”. The string is just an encrypted text of 484,000 length.
Various encryption techniques such as RC2, Triple DES, SHA, etc were used to encode the trojan code. After encoding the whole code, the malware author reversed the string and placed it in the file. When this string is invoked in the main program, the string is first reversed and then passed to a function that creates a DLL.
The DLL injection
The DLL injection is performed by inserting code into the running process. The adversary is trying to gain higher-level permissions. Privilege escalation consists of techniques that adversaries use to gain higher-level permissions on a system or network. This is done by attaching to a process and allocating some memory within the process for the malicious code. This memory allocation is done by a function called VirtualAllocEx(). The code is then inserted in the existing process. This is taken care of by the WriteProcessMemory() function. The base address of the malicious code is noted so that it can be called whenever required. This is usually done using the thread invocation mode so that it may go unnoticed. The malware may inject its own malicious code into the DLL.
So far, we have done only static analysis on the sample. When we dynamically executed it, we figured out the process tree of the malware looks something like this.
When the .scr file is executed, it invokes wscript.exe which helps to execute the vbs script. As discussed earlier, the vb script contains a variable oddshl which causes “agj.exe gjm=loo”, to be executed. This triggers the DLL injection which spins a child process RegSvcs.exe. This is where the actual trojan resides.
Attacker’s Infrastructure
After executing the trojan in a sandboxed environment to do dynamic analysis, we see that the file exhibits Nanocore RAT behavior. Nanocore is a modular remote access trojan (RAT). Its infection method is through spam emails, attachments, and software bundles. Nanocore is able to disable antivirus software, bypass firewalls and make registry modifications. This threat can lead to the installation of additional malware and the loss of sensitive information.
During this analysis the RAT made a callout to the dynamic DNS (DDNS) domain of nikkycharles3[.]ddns[.]net which would be the command and control server (c2 server) where the malware can receive commands to initiate different modules, drop additional malware, or send stolen information.
- Query volume timeline taken from Cisco Umbrella Investigate
Once we had the DDNS domain that was acting as the c2 server, we started investigating the hosting infrastructure. The hosting IPs hosted many more DDNS domains and we were able to find additional malicious artifacts and RATs that were communicating to them. The attacker’s infrastructure is primarily located in Nigeria on ASN 36873. You can find a full list of IOCs at the end of this blog post. They include 79 hosting IPs and over 200 c2 servers.
Why Umbrella?
Umbrella protects users from connecting to malicious sites on the Internet and analyzes over 180 billion DNS requests daily. The sheer volume of DNS requests gives our Researchers a unique view of the Internet to better identify trends on threats, faster. Our statistical models and threat hunting techniques allow our Researchers to be aware of an attacker’s infrastructure before new attacks can launch.
Interested in trying out Umbrella? Sign-up for a free 14-day trial today.
IOCs:
Initial Files:
4fc39b14caa8a3cdca1c57b157b0dd2bd8ec49dc7c550e3811a8bb95f1244927
fb73a819b37523126c7708a1d06f3b8825fa60c926154ab2d511ba668f49dc4b
