I had an idea about one and half year ago, which was the following: If various malware check for the presence of debuggers, check if they run inside a VM and if they find any of those, then they exit. I wondered why we can't use this to our benefit. I always run into solutions, which try to hide the VM / debugger, so the malware can be analyzed, but I never heard about the other way around. What if we make our regular desktop to look like a VM, thus if the malware detects it, if will simply exit, without doing any harm. I know that the number of VM aware malware is decreasing, but we could still stop a fairly good amount of bad stuff, which is always a benefit, and perfectly fits into the "multi-layer defense" approach in my mind.
In the past one and half year, I run into this idea twice, so luckily I'm not the only one who thought about this. Apparently talk about this stuff is so rare that I have to highlight them:
- The HitmanPro Alert protection tool integrates this feature. I don't know to what extent, and what it will fake exactly, but certainly a welcomed approach.
- The article from Rapid7 Vaccinating systems against VM-aware malware talks about this.
I always wondered why various AV solution doesn't integrate this technique to their toolset, like HitmanPro did, I think it shouldn't be that hard. Probably it could raise some compatibility issues, with having fake services, files, registry keys, etc... but some of those could be done without any harm.
To prove my point, I wanted to develop something that could do this for me. The easy way would have been to actually place the files, registry keys, etc... in the system, like what Rapid7 did, but I think that it might not be easily rolled back, and wanted to see if there is another way. I was always interested how SSDT hooking works in rootkits, so I decided to go down that road, I could learn how SSDT hooking works at the code level, and maybe also produce something useful. This or similar approach could be integrated to AV software as well, like Symantec, which already does bunch of SSDT hooks in x86 systems, why not to add a few more?
I also wanted to see how complex it is to do this. The last time I wrote any line of code in C language was back in 2002 when I was a university student, and it was basic C, nothing to do with Windows API, so the challenge was given.
Luckily the Internet is full of examples, so it took 3 afternoons to develop the first version of my SSDT hooking kernel driver which was working. It took me a couple of more to come up with the final POC, which I will post in GitHub. The POC code can give false information about registry keys, files and devices, when a malware tries to look for them. I stopped here, because
- I think it proves my point
- I don't have time to develop it in more detail for other checks, and I also don't have the need
I know that there are plenty of other checks against VMs (special ports, mac address, red pills, screen resolution, CPU cores, etc...) which could be much harder to fake, but many malware will check for files and registry entries as well, and my goal wasn't to develop a complete solution.
With that my question is: if me, who had "0" experience with developing kernel drivers, or any Windows app in C language, and achieved - what I will show below - in only a few days, then a professional developer, could do this much more fast, and probably add a whole lot of other features as well, easily - and then, why no one does it?
Let's see my kernel driver (I will not go into the details how to write a driver, etc... you can find plenty of articles about that on Google), you can download it from my GitHub: https://github.com/theevilbit/fakevm
In order to install it you need to create a service:
sc create fakevm binPath= [path to your .sys file] type= kernel
After that, it can be started / stopped with the following command
sc start fakevm
sc stop fakevm
You need to have admin rights to do this.
Once it's started it will hook three functions to alter the execution flow, and by default it will start giving false information about files, devices and registry keys. I added a few IOCTLs to the driver (just to learn a bit about that as well), and thus we can control it, and turn on/off hooks, and if we want to make our desktop a fake VMware VM or VirtualBox VM (by default both are enabled). As I more comfortable with python, I created the controller it in that language, here is the usage of that script:
Usage: controller.py [options]
-h, --help show this help message and exit
-w, --vmware Switch fake VMware ON/OFF
-x, --vbox Switch fake VBox ON/OFF
-o, --hook Hook all functions
-u, --unhook Unhook all functions
I used pafish to get ideas what to fake, and also to verify my driver. This is pafish's output without the driver being loaded (note that I used a VM for the tests, because I have a MacBook + if I had a Windows I wouldn't want to BSOD it with a poorly written kernel driver):
We can see that VBox checks and most VMware checks didn't found anything. Of course a few VMware checks were successful, because I'm in a real VMware VM. This is what happens when I start the service:
We can see that many of the checks show that VBox or VMware was found. In the meantime the Windows OS seems to work properly, I can browse the web, open files, etc... doesn't seem to cause any harm. In WinDBG we can see the SSDT hooks:
With having a controller, this is what happens when I turn off VBox for example:
The hooks are still there, but they become a bit more transparent (I still fake VMware indicators).
I haven't done extensive testing of my driver, it might have bugs (most likely it has), I didn't prepared it for a whole lot of error scenarios, but I think overall it's quite stable, and if someone wants can take it further. This is just a simple POC to prove that with a simple kernel driver we could defend against some amount of malware, and I really wish this concept to be widely used by AV vendors, because it can certainly add to the protection level. Every single step counts.