Make your desktop a fake Virtual Machine to defend against malware

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:

1. 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.
2. 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

1. I think it proves my point
2. 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/vaccination/

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]

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.

SANS FOR 610 - Reverse Engineering Malware mentor class in Budapest

I will mentor the SANS 610 - Reverse Engineering Malware class in Budapest, starting at the 19th of January, 2016. If you live in Budapest and wanted to take such a class, I highly recommend it, because this is a great course. Here are the details:

https://www.sans.org/mentor/class/for610-budapest-19jan2016-csaba-fitzl

You Will Learn How To:

• Build an isolated, controlled laboratory environment for analyzing the code and behavior of malicious programs.
• Employ network and system-monitoring tools to examine how malware interacts with the file system, registry, network, and other processes in a Windows environment.
• Uncover and analyze malicious JavaScript and VBScript components of web pages, which are often used by exploit kits for drive-by attacks.
• Control relevant aspects of the malicious program's behavior through network traffic interception and code patching to perform effective malware analysis.
• Use a disassembler and a debugger to examine the inner workings of malicious Windows executables.
• Bypass a variety of packers and other defensive mechanisms designed by malware authors to misdirect, confuse, and otherwise slow down the analyst.
• Recognize and understand common assembly-level patterns in malicious code, such as DLL injection and anti-analysis measures.
• Assess the threat associated with malicious documents, such as PDF and Microsoft Office files, in the context of targeted attacks.
• Derive Indicators of Compromise from malicious executables to perform incident response triage.
• Utilize practical memory forensics techniques to examine the capabilities of rootkits and other malicious program types.

Hacktivity 2015 - Hello Anti-disassembly workshop

My Hacktivity 2015 - Hello Anti-disassembly workshop files can be downloaded from here:

hacktivity2015_helloantidisassembly.zip

The zip file contain the following files:

IDA python script:

antida.py

Example codes:

case1.c
case1.exe
case2.c
case2.exe
case3.c
case3.exe
initial.c
initial.exe

Guide:

Hacktivity 2015 - Fitzl Csaba - Hello Anti Disassembly.pdf

The original workshop description:

"We will review how the two main types of disassembler works, and why they can be fooled, then we will cover 3 typical examples. As part of each exercise we will create our own short C program, which will cause the disassembler to incorrectly parse our code, then we will see how we can manually find and correct it in IDA Pro. As a last step we will create a short Python script for IDA Pro, which will automatically find and mark these techniques for us. We will also check how we can patch the code from an IDA Script to defeat the anti-disassembly techniques."

https://hacktivity.com/en/hacktivity-2015/hello-workshop/hello-anti-disassembly1/