Anti-VM gone wrong :)

On a weekly bases we check for VM-aware and dynamic analysis system aware malware samples at Joe Security. Lately we came across an interesting sample (MD5: cc9fab2465a279b9424da3a09df7c8d5):

The initial analysis was performed on a virtual machine. As you see the sample does not show lot of behavior. It idles and only reads the registry key HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Disk\Enum 0 which basically contains the name and serial ID of the primary disk. Checking the Disk\Enum\0 registry entry for a particular name is very old and known trick to detect virtual machines. Since we started add virtual machines support to Joe Sandbox we included mechansims to randomize this particular registry key. So although Joe Sandbox tries to prevent this specific virtual machine detection it seemed the malware was still successful in doing so. Thus we analyzed the sample a second time on a real physical machine (yes you can easily do that with Joe Sandbox):

Surprisingly the results were exact the same. The sample did not show any suspicious activites during execution on the physical machine. So based on this finding it looked obvious that the sample either does not run at all or it only runs on virtual machine. To validate that we disabled the randomization of virtual machine artifcats within a cookbook:

And finally analyzed the sample a second time:

As the signature overview outlines the sample has opened a listening socket on port 8000, dropped a new PE file and created a startup key. This malicious behavior confirms that the sample (which seems to be a version of the Gamarue Worm) only runs on virtual machine. This is quite funny, since malware authors try to prevent running on virtual machines to hinder automated analysis. So it seems to be a cool programming mistake.

A deeper look with Hybrid Code Analysis revealed the sample only works on VirtualBox, VMware and Qemu:

Full sample report:

• VM only Gamaru, Joe Sandbox Desktop 8.0.0 Analysis Report

Update 1: Thanks to advanced_reddit_user to pointing out that our analysis was wrong. He outlined that the payload we see on VMs only (copy to svchost.exe and 8000 port listening) is a fake behavior of a trojan called Andromeda. The real payload is only shown if the volumn name of the system drive equals a specific checksum.

Update 2: We confirm the finding by advanced_reddi-user:

Analysis Report:

• Joe Sandbox Andromeda Analysis Checksum

Changing the drive volume to CKF81X:

Analysis Report:

• Joe Sandbox Andromeda Analysis Checksum