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/

Creating OSX shellcodes

I decided to play around with OS X shellcodes, now this time instead of writing a brand new post about it, I will paste here 3 other posts, which I found really useful to get started.

http://ligocki.tumblr.com/post/5174133459/writing-shellcode-under-mac-os-x-part-0x01

https://filippo.io/making-system-calls-from-assembly-in-mac-os-x/

http://dustin.schultz.io/blog/2010/11/15/mac-os-x-64-bit-assembly-system-calls/

A few highlights:

• OS X is a nix based system, so essentially shellcode creation is like on Linux, you can use syscalls
• These days OS X is x64 only, so you need to pass arguments in the registers, the order is: RDI, RSI, RDX, R10, R8 and R9
• syscalls are done through the syscall command, which is stored in the RAX register
• You need to add 0x20000000 to the syscall number

I created two NULL byte free shellcodes for OS X x64:

1. A simple /bin/sh code: https://www.exploit-db.com/exploits/38065/
2: A bind TCP shell, listening on port 4444: https://www.exploit-db.com/exploits/38126/

I also posted them on my github page: https://github.com/theevilbit/shellcode

Offensive Security - Advanced Windows Exploitation (AWE) / OSEE review

Let me start first with my background. I don't do pentesting, vulnerability research or exploit development at all in my day to day life, I work on the defence side. I gathered this knowledge through the OSCP - OSCE trainings and exams, and that is the only place where I really practiced it. I also happened to read many articles from Corelan and FuzzySecurity on exploit development topics. On the other hand I do reverse engineering both on my day to day work, and I also play some CTFs sometimes to practice that skill. This is not strictly related but definitely helps a lot, when it comes to using debuggers, IDA Pro or understanding code, assembly, which is quite helpful.

If you want to take this class: You definitely need experience with writing basic exploits (basic buffer overflow, SEH based) completely on your own, know to use at least Olly/Immunity debugger (although it’s not used in the training, you need good debugging experience), be familiar with IDA and WinDBG a little bit, and understand assembly very well. As noted earlier reverse engineering experience also comes handy.

Now to the course:

This is the most intense, hardest and probably the best security training I ever took. They keep the same topics over the years, but always update the material with new content (if you follow the syllabus content over the years), basically the case studies which used to present the various techniques are pretty new. I will mostly repeat the syllabus above with my experience added:

Day 1 - 1st half: Location independent shellcode, how you can find the base address of kernel32.dll or any other, and how can you resolve the function addresses, this is important these days because of ASLR. If you took any malware analysis class, this should be familiar. This was the easiest part of the training and it’s really for warm up, to get familiar with WinDBG (we didn’t use Olly or Immunity at all). You also start to feel comfortable, that you can easily handle this stuff, and don't know yet that it can change drastically.

Day 1 - 2nd half & Day 2: Through a Firefox exploit we covered the following topics: DEP, ASLR bypass (with memory leak technique), precision heap spraying, bypassing EMET 5.2 with all protections turned ON. The EMET bypass was annoyingly easy. ROP mitigation could be bypassed with locating a single bit in memory, and setting it to zero, with the unhooked version of the kernel functions, which could be found in the same EMET structure. EAF bypass works with an old shellcode… After this day I started to feel tired :)

Day 3: We went through one of the SEP exploits they found last year to cover x86 Windows kernel pool spraying (like heap spraying just in kernel space), and pool overflow. The technique is even harder because if you overwrite something in kernel you easily end up with a BSOD, so you need to be very precise. We also covered token stealing shellcode for privilege escalation. This was quite demanding as we fall behind in time a little bit on the first 2 days. My brain wanted to explode at this point. We also got homework every day, and this was the first evening, when I was just looking on the screen, and my brain literally stopped working, so I just decided to go sleep.

Day 4: x64 kernel exploit, again with memory overwrite. We covered the MS14-058 privilege escalation exploit which was used in the Hurricane Panda campaign last year. The interesting thing was that the public exploit is only available for Win 7 x86, but we did it for Win 8.1 x64 (it works slightly differently as has some more protection). Basically with a well crafted memory overwrite we could give us debugging privileges and inject a shellcode to another SYSTEM level process to get full system access. This day was a bit more relaxed as we were good with time, although the topics still not easy. The hardest part of kernel exploits seem to be to craft your input so precisely that you end up on a vulnerable instruction that will do some memory overwrite for you.

The class had 20 students with 1 lead trainer (ryujin) and 2 assistants (ronin & sickness) who also helped the students, and you could hardly ask anything from any of them, which they couldn't answer right away. They are really sharp people! But, really, would you expect less from Offensive Security trainers? :) This was really great because there was someone always available to help you out, which was needed quite often. In every case we progressed in small steps, they gave a code at each stage, what we had to fill in with some details what we had to figure out ourselves. They also gave you the solutions if you didn’t want to deal with the exploits just to follow the class. It was really important to understand each step, because if you missed something, you could easily fall behind, and it was really hard to catch up. The trainers made all the effort for that not to happen, they were really helpful through the entire course. All the VMs, material, hint website during the training was prepared very well, everything run smoothly. Due to the level of difficulties, we started earlier, finished a bit later, and got also shortened lunch time. They said that this is the first time when someone didn’t left the class :)

The training is definitely useful to better understand exploits, Windows kernel and adds to your reverse engineering knowledge as well.

Side note: Next to us they run their “Advanced Web Attacks and Exploitation” class, where, as usual their covered currently 0-day exploits… and students were really happy about it :)

Preparation to the exam:

I went through the entire material again, did 3 of the extra mile exercises (out of 4), and went through other two kernel exploits developed by ryujin:

Avast! 4.7 - aavmker4.sys Privilege Escalation

Microsoft Windows XP/2003 Afd.sys - Local Privilege Escalation Exploit (MS11-080)

With that I felt well prepared for the exam, and scheduled it 3 weeks right after the training.

The exam:

As usual I can't say too much. You have 72 hours to solve 2 challenges, a big one, and a smaller one (which is also not easy). Obviously they can't cover all the topics from the training, but they will cover the most important ones. In one way the exam is much more straightforward compared to OSCP / OSCE, it's much more clear what you need to do, but it's also harder and much more time consuming compared to the other two. Additionally just as in any other Offsec exam, you learn new stuff even during the examination process, as you need to adapt to never before seen challenges, and I think this is a really good thing. I really enjoyed solving both of the tasks.

I started at 11AM, and probably I was in a very good mood, because I could solve the big task in 7 hours!!! I continued with the other one in the next few hours, before I went to sleep. I had a short sleep (although I wanted to have a long one, because I had lot of time), but I was debugging even in dreamland... in the morning I finished the 2nd task, but only in the easy way (there are two ways to solve it, each worth different amount of points), so I went ahead for the harder way. I got too relaxed by that time, so finishing that one took me quite long time, because I stuck at one point, from where I couldn't move on. Luckily after some breaks, I figured out how to proceed, and late afternoon I was done with everything. I put my son to sleep, then my wife, and late evening started the documentation, which I finished 5 hours later, 2AM next day.

I submitted it on Friday, and got my PASS result on Monday - was so happy to receive that email :))

In summary: another great training and exam from Offensive Security, I recommend it to anyone who would like to advance his exploit development skills.