While hidden Macro 4.0 samples are on the rise, we recently spotted some very interesting evasive VBS samples. In this short blog post, we will look at sample files#_56117.vbs, MD5: 147091e61ec59f67ab598d26f15ad0e7 and outline some of the evasive tricks.
An initial look at the Joe Sandbox v29 analysis reveals two evasive behavior signature hits:
In addition, there is no payload behavior, the sample shows a fake error message box and deletes itself and quits:
The two evasive signatures hits gave us enough evidence to investigate the sample further.
ExecuteGlobal
The VBS file itself is obfuscated. Large arrays hold encrypted characters which are decrypted during runtime and executed with the VBA function ExecuteGlobal:
Deobfuscation is straight forward - simply replace ExecuteGlobal with a function to append the code to a text file, or even easier, download the AMSI output which is captured by Joe Sandbox:
It holds all the code executed by ExecuteGlobal.
The executed code performs nine different evasive checks which are outlined in the next sections.
Total Disk Size Check
The VBS sample checks if the size of all disks combined is bigger than 60 GB. In addition, the code verifies if there is no empty CD-ROM drive. In case there is an empty CD-ROM drive or the total size of all disks is smaller than 60 GB the sample will quit:
To enumerate all disks it uses the WMI class Win32_LogicalDisk. Likely the authors recognized that many sandbox VMs still have an empty CD-ROM drive connected, meanwhile end-user laptops don't. The CD-ROM drive check is a new evasion method that we haven't seen before.
File Count Check
Next, a file count check follows. The sample verifies if the number of files in the user download folder is bigger than 2. The same check is executed for temporary files:
If the count of either directory is below 3 then the sample quits.
Process Name Check
Checking for debugging and reverse engineer tools is very common for many malware samples. This VBS sample has a very extensive list of debugging tools:
If one of the listed process names is found running on the system the sample quits. In addition, it also verifies that the total number of running processes is bigger than 28. This is a nice trick that has also been used by many other samples, especially VBA droppers. On a real endpoint, a user has usually opened many applications (e.g. web browser, Microsoft Office, etc) while on a VM sandbox there are no applications running.
Country / Region Check
The sample will quit if the geographical location of Windows is Russia:
In the sample, this check is currently disabled.
CPU Count Check
If there are less than 3 CPUs available on the system the sample quits:
Memory Check
If the total physical memory is below 1030 MB the sample quits:
Last Boot Time Check
This is a newer evasion and we haven't seen it a lot in malware samples. The sample verifies if the time the system booted is more than 10 minutes ago. Again VM sandboxes might have a much shorted last boot time.
Real end-user systems on the other hand, are rebooting the system less often.
Name and File Checks
Finally, there are also some sample name-checks that are very common. The most prominent one is to check for sample or myapp or in the current case testing:
There is also a weird additional check for microsoft.url in the temp directory. So far we have not yet found which sandbox is targeted by this check:
IOCs