The Dead Giveaways of VM-Aware Malware

I often overhear talk about so called next generation anti vm, sandnet and debugger techniques and their *widespread* use by modern malware, and how this is hurting modern day automated malware analysis and detection. Well I find the facts are quite different.  Most of these claims don't provide good evidence and I consider them little more than an attempt to create FUD (Fear, Uncertainty and Doubt). The reality is that after the good old days of IRC bots which were created mostly for fun, the majority of commercial malware shown no interest in detecting VMS and/or debuggers. Why? I will come to the reasons later.

A while back, I talked about the world's top 20 malware list based on FireEye's real time data feed. None of these malware families except for Conficker (number 11) try to detect virtual machines. What about taking into consideration the top 10 malware list given by Microsoft a while back? I can prove that none of these top 10 malware try to detect a Virtual Environment.

How many malware families try to detect popular, publicly available sandnets like ThreatExpert? See for yourself.

Now I'll come to the reasons why.

1. A big portion of existing infrastructure is moving towards virtualization now a days. Virtualization is no longer a researcher's tool. One will find lots of real assets running on top of these virtual environments. Malware authors are well aware of this and can't afford to loose these valuable assets.

2. Another reason for not detecting virtual environments in general is that after the first wave of VM aware malware (mostly IRC bots like Rbot, SDbot/Reptile, Mechbot, SpyBot and AgoBot etc.), the authors of next generation malware realized that advanced behavior analysis engines (including FireEye's own from day one) can turn the tables on them and will use these evasion techniques as a way to detect them. In other words, to filter the bad from benign. How many legitimate software applications are you aware of that try to detect the ThreatExpert environment? If some software is doing it, there is a great chance that it is bad, making malware detection easier.

3. How much difference have these anti VM/debugger malware features made? Did it stop researchers from reversing Conficker, SDbot etc? As a matter of fact, Conficker is one of the most widely talked about malware families, mostly due to its evasion techniques. Similarly almost all the modern debuggers like OllyDbg are aware of anti debugging techniques and can bypass them very easily.

Anyway, let's wrap up this debate and talk about an exception that proves the rule. I recently came across a relatively unknown malware sample that is different from other malware in many aspects. It uses its own custom obfuscated CnC protocol, and is equipped with quite a few data stealing payloads etc.

Most importantly it is using a whole lot of anti debugging, vm and sandnet techniques which my eyes caught very quickly (unnecessary attention, isn't it?). The name of this malware is Rebhip which we here in FireEye classify as an information stealer. To keep this article short and relevant to the topic, today I will only talk about its anti analysis techniques.

Rebhip anti analysis techniques can be divided into four broad categories.

1. Anti Sandnets

2. Anti VM/Emulation

3. Anti Debugging

4. Anti Disassembler

Let me describe these one by one.

1. Anti Sandnets

Rebhip is capable of detecting all the popular VMs along with publicly available automated malware analysis workbenches like ThreatExpert, Anubis, CWSandbox and JoeBox etc. In terms of VM detection its capable of detecting VMWare, Virtual PC and Virtual Box. No surprise that none of the proprietary virtualized environments like FireEye's own, are on the list.

1.1 ThreatExpert

It looks like ThreatExpert inserts a special dll named dbghelp.dll for every process running inside their environment, most probably for API hooking purposes. Once Rebhip finds that this dll is loaded inside its own process space it silently aborts.

 push    offset aDbghelp_dll ; "dbghelp.dll"
 call    GetModuleHandleA
 test    eax, eax
 jz      short loc_405323
 mov     bl, 1

Resolution:

Time to change the name of this dll. To avoid these kind of attacks in future the dll name can be generated randomly at runtime.

Note: If some of you guys are wondering how the bad buys know about this dll. The simplest answer is that one can craft a binary just for the sake of revealing this kind of information as part of ThreatExpert output. Moreover a reverse shell can be invoked to give an attacker access to a virtual environment remotely.

1.2 JoeBox

Detection of the JoeBox sandnet is done by comparing the product key of the running OS with 55274-640-2673064-23950. If there is a match, the malware assumes that it is running inside JoeBox.

push    ebx
add     esp, 0FFFFFEF4h
xor     ebx, ebx
push    esp             ; phkResult
push    1               ; samDesired
push    0               ; ulOptions
push    offset SubKey   ; "Software\\Microsoft\\Windows\\CurrentVersi"...
push    80000002h       ; hKey
call    RegOpenKeyExA
test    eax, eax
jnz     short loc_405387
mov     [esp+110h+cbData], 101h
lea     eax, [esp+110h+cbData]
push    eax             ; lpcbData
lea     eax, [esp+114h+Data]
push    eax             ; lpData
push    0               ; lpType
push    0               ; lpReserved
push    offset ValueName ; "ProductId"
mov     eax, [esp+124h+hKey]
push    eax             ; hKey
call    RegQueryValueExA
lea     eax, [esp+110h+Data]
cmp     eax, offset a55274640267306 ; "55274-640-2673064-23950"
jnz     short loc_405387
mov     bl, 1

Resoulution:

Just before each run modify the registry key holding original Windows Product Id with some random key. Also flag this lookup as a possible sign of badness.

1.3 CWSandbox

Similarly CWSandobox is detected by comparing VM host product id with 76487-644-3177037-23510.

Resolution:

Same as above.

1.4 Anubis

Same is true for Anubis and this time the product id to match is 76487-337-8429955-22614.

Resolution:

Same as above.

2. Anti VM/Emulation

As I explained above this malware is capable of detecting VMWare, Virtual Box and Virtual PC specifically and one generic way to detect VM presence.

2.1 Virtual Box

Detecting a Virtual Box environment is done by going through the running process list and looking for a process having name 'VBoxService.exe'. This service is part of the 'Guest Additions' offered by Virtual box in order to assist in tasks like drag and drop and clipboard sharing etc.

Resolution:

Installation of 'Guest Addition' is optional and I won't recommend installing it although it will mean the loss of some cool features.

2.2 VMWare

Rebhip uses VMWawre backdoor I/O as a means to detect VMware presence. If the OS is running inside VMware a port name 'VX' will be available to be used for communication between the host and the guest OS. Data from this port can be read given different op codes, for example 0x0A is used to get the VMware version. A successful read means that you are inside VMvare.

mov     eax, 'VMXh'
mov     ebx, 3C6CF712h
mov     ecx, 10
mov     dx, 'VX'
in      eax, dx
mov     eax, 1

2.3 Virtual PC

Virtual PC uses a few invalid x86 instructions to interface between the VM OS and the emulator itself. When running inside a physical machine, execution of these invalid op codes will raise an exception whereas inside Virtual Pc it will be handled gracefully. Rebhip installs an exception handler and checks to see if this exception is caught. If so, it assumes it is running on a physical machine otherwise inside Virtual PC.

2.4 General Purpose

This method relies on the assumption that virtual machines are less powerful than physical machines. If the time lapse between a series of actions is greater than a certain value , it's likely to be running inside a VM.

Rebhip does it like this:

1. Find the milliseconds lapsed since the start of this machine using the GetTickCount win32 API.

2. Execute a series of operations including calling a list of crafted functions 

4. Get the elapsed time again using GetTickCount API.

5. If the time elapsed is more than 5 seconds, abort.

It's still unknown to me how the author reached the conclusion that 5 seconds is the right figure. I guess it was a result of trial and error.

3. Anti Debugging

Rebhip is equipped with many types of anti debugger techniques. Some of these are general in nature while there are some which are specifically targeting debuggers like SOFTICE.

3.1 General purpose

Rebhip uses two general approaches to detect user level debuggers like OllyDbg and IDA Pro etc. The first method uses PEB (Process Environment Blocks) structures's 'BeingDebugged' field. The third byte of this filed is always set to 1 when a program is running inside a debugger.

This is accomplished like this:

mov     eax, large fs:30h

Load eax with the memory located at the 0x30th offset of Thread Information Block (TIB) structure. Please note here that FS is supposed to hold the starting point of TIB. Where 0x30st offset contains the linear address of PEB (Process Environment Block).

movzx   eax, byte ptr [eax+2]

Copy the third byte of PEB->BeingDebugged flag into EAX. If value of eax (or al) is 1, it means the program is running inside a user level debugger and the malware calls ExitProcess to quit silently.

The second approach used by Rebhip is the use of the famous 'IsDebuggerPresent' Win32 API. If some readers have ever tried to debug this API they will know that the logic inside IsDebugPresent is almost the same as I explained above. What is the reason that the author re-implemented the same logic himself? The most plausible answer is to make reverser's job more difficult.

Resolution:

In case your debugger is not able to fix it automatically. Re-write this flag value back to 0 in the very start of the execution.

3.2 Kernel level debuggers

Rebhip is also equipped with the ability to detect kernel level debuggers like SOFICE, SYSER etc. The technique in use targets that fact that the above mentioned debuggers register different devices (driver objects) with the system like \\.\NTICE and \\.\SyserDbgMsg etc. Once Rebhip find the presence of any of these devices on the system it aborts.

Resolution:

Again start using random names for your driver objects.

4. Anti Diassembler

Well this should not be surprising. Almost all modern day malware use some sort of binary obfuscation or packing techniques to evade signature based AV detection. The same is true for Rebhip. I got a chance to analyze over a dozen samples and all of them were packed with different unknown (based on PEID output) packers.

like

MD5: a6a8d4d31431fb52c56d8741e0ffb516

In a nutshell all of these evasion techniques can be bypassed and used for an easy detection of the malware. In general, the best chance for a malware to survive for a longer period of time is by flying under the radar and not challenging researchers. What we have seen in the past is that the more innovative malware tries to become, the greater the chances are there that it will gain unnecessary attention. Like we seen in the case of Storm 1.0 with its fancy P2P protocol, Conficker with its anti researcher/anti AV approach, Licat and Kraken etc. with their auto domain generation algorithms. 

Atif Mushtaq

Comments

[Roger]

Many of these Anti-detection methods are indeed very old, there's is really nothing new about any of these, and the ProductId detection for Anubis is useless aswell, as it have plenty of different ones (Try it yourself, upload a sample that printf()'s the ProductId and upload it a few times, you will see that Anubis randomizes the ProductId

Other sandboxes probably does this aswell.

Either way none of this is a new concept and my guess is that it is a RAT or similar (Like Bifrost) that have been coded by script kiddies.

Is the exe made in VB or .NET by any chance?

[James W]

Great article as always, Atif.

[Nikolay]

Some of these tricks does not work already. They worked few years ago.

[Atif Mushtaq]

I am surprised that top malware list given by FireEye and Microsoft and thousands of ThreatExpert reports links are not enough for you. Why do not you come up with a counter list even of a fraction of the above mentioned data to prove your case?

If you think that Rebhip evasion techniques were able to stop AV industry, you can see the detection rate here:

http://www.virustotal.com/file-scan/report.html?id=f854a28eff3f85f96f8f1d7f281c3d072098534448000d49e289b73d5e650b17-1278356440

Anyways, I respect your freedom of speech right just like I do for “advanced_comentator” who is saying malware authors the brave guys and AV industry on a whole bad money suckers.

[ok]

Really? You just complained of fud based on a claim of no data, but provide no data to make your own. Flimflam.
Ever take a real look at what doesn't run on TE? Can't tell from this writeup if you did.

[Mark D. Adams]

Nice write-up. I guess I need to make my own proprietary VM. I don't have the time to disassemble that much anymore. It seems like the easiest way to defeat automated analysis though, is to simply wait for a specific user action to do something malicious.

[advanced_comentator]

>how the bad buys
>bad buys
Why AV companies always mixing truth? They are not "bad guys", they are good and brave guys. Trying to return their money from fat and dirty capitalists. Who are bad guys then? Answer is AV industry. They can't protect users from real attacks, such as stuxnet or conficker, just doing their PR and sucking money from innocent users.