The usage of anti VM/Sandbox detection tricks is becoming more common nowadays. These are used by malwares to detect that they are running inside a sandbox.
However, most of the tricks used in malwares make it evident that they are trying to detect VM. For instance, they look up Registry Keys/Process Names for strings like "vmware", "virtual", "qemu", "xen". If the reverser is stepping through the code of a virus, they can easily make out that this malware is VM-Aware.
I am more interested in methods which detect the VM using assembly language instructions only. There are certain assembly language instructions for which there is a different behavior exhibited by VMWare guest than host operating systems. Tricks that use SIDT, SLDT, SGDT, backdoor interface of virtual machine (VMXh) and others are known.
I was working on finding a new way to detect that we are running inside VMWare. At the same time, I did not want this method to rely on evident strings as mentioned above. After exploring the memory address space of the *.vmem file of my Virtual Machine, I developed a good method.
VMWare has a specific OEM String that looks like: MS_VM_CERT/SHA1/
This OEMString will be present in the SMBIOS. On operating systems like Linux you can view it using dmidecode which is able to extract information from the SMBIOS structures.
On Windows, you can get some information from the SMBIOS using wmic (Windows Management Instrumentation Console).
I noticed that you can also get the same information from the process address space of csrss.exe. Below you can see the result of scanning the process address space of Windows XP SP3 Virtual Machine using the yarascan plugin of volatility framework. It shows that OEMString was found in csrss.exe's address space:
So, we can detect the presence of VMWare by scanning csrss.exe's process address space and looking for the string, MS_VM_CERT. I wrote the following code in C to do this:
Here is the output of the code:
Advantages:
1. We are not scanning for an evident string like "vmware", "virtual" and so on which would give away the trick to the reverser.
2. Currently my code scans for MS_VM_CERT. However, it is also possible to scan for the SHA-1 hash. I have observed that the SHA-1 hash is consistent on most VMWare Virtual Machine instances. This would need to be tested further.
3. Scanning in the memory is much more effective than checking the Windows Registry, Processes or File System artifacts for strings related to VMWare. These can be modified easily by the malware analysts in the VM to prevent basic VM detection tricks from working. However, modifying the OEM String in memory is not that easy.
To test:
1. On different products of VMWare like VMWare Fusion, different versions of VMWare Workstation.
2. By setting the option, SMBIOS.reflectHost = True in the VMWare configuration file.
c0d3inj3cT
However, most of the tricks used in malwares make it evident that they are trying to detect VM. For instance, they look up Registry Keys/Process Names for strings like "vmware", "virtual", "qemu", "xen". If the reverser is stepping through the code of a virus, they can easily make out that this malware is VM-Aware.
I am more interested in methods which detect the VM using assembly language instructions only. There are certain assembly language instructions for which there is a different behavior exhibited by VMWare guest than host operating systems. Tricks that use SIDT, SLDT, SGDT, backdoor interface of virtual machine (VMXh) and others are known.
I was working on finding a new way to detect that we are running inside VMWare. At the same time, I did not want this method to rely on evident strings as mentioned above. After exploring the memory address space of the *.vmem file of my Virtual Machine, I developed a good method.
VMWare has a specific OEM String that looks like: MS_VM_CERT/SHA1/
This OEMString will be present in the SMBIOS. On operating systems like Linux you can view it using dmidecode which is able to extract information from the SMBIOS structures.
On Windows, you can get some information from the SMBIOS using wmic (Windows Management Instrumentation Console).
I noticed that you can also get the same information from the process address space of csrss.exe. Below you can see the result of scanning the process address space of Windows XP SP3 Virtual Machine using the yarascan plugin of volatility framework. It shows that OEMString was found in csrss.exe's address space:
Here is the output of the code:
Advantages:
1. We are not scanning for an evident string like "vmware", "virtual" and so on which would give away the trick to the reverser.
2. Currently my code scans for MS_VM_CERT. However, it is also possible to scan for the SHA-1 hash. I have observed that the SHA-1 hash is consistent on most VMWare Virtual Machine instances. This would need to be tested further.
3. Scanning in the memory is much more effective than checking the Windows Registry, Processes or File System artifacts for strings related to VMWare. These can be modified easily by the malware analysts in the VM to prevent basic VM detection tricks from working. However, modifying the OEM String in memory is not that easy.
To test:
1. On different products of VMWare like VMWare Fusion, different versions of VMWare Workstation.
2. By setting the option, SMBIOS.reflectHost = True in the VMWare configuration file.
c0d3inj3cT
0 comments: