SecurityFest 2017: How to convince a malware to avoid us

The presentation of my talk is available here:

https://www.slideshare.net/CsabaFitzl/how-to-convince-a-malware-to-avoid-us

My talk, starting at 2:11, can be seen here:

https://www.youtube.com/watch?v=8qf1mPWyxbA

My tools can be downloaded from here:

https://github.com/theevilbit/vaccination

BSidesBUD 2017: IOC sharing - we are doing it wrong

The presentation to my talk is available here:
https://www.slideshare.net/CsabaFitzl/ioc-sharing-we-are-doing-it-wrong

Defend against malware with fake debugger windows

This post will be quite similar to my previous post about making your desktop look like a VM: https://theevilbit.blogspot.com/2015/10/make-your-desktop-fake-virtual-machine.html. The idea here is another trick malware commonly uses to detect malware analyst's machine: enumerating the windows and check if there are titles such as "OllyDBG", "WinDBG", "Wireshark", etc... it will frequently look for debuggers or various malware analysis tools.

I was thinking about, what if I place an empty window with this name, will malware detect it? I didn't wanted to hook into functions this time, but place an actual window. My other criteria was, that I want the window to be hidden, so it doesn't disturb people, but still can serve its purpose.

First let's see how malware detects / enumerates window titles. As described here: http://antukh.com/blog/2015/01/19/malware-techniques-cheat-sheet/ and many other places, it uses the "FindWindow" Windows API call to look for names. This is a quite simple function with two parameters:

HWND WINAPI FindWindow(
  _In_opt_ LPCTSTR lpClassName,
  _In_opt_ LPCTSTR lpWindowName
);

As per MSDN it will search for the string specified in lpClassName, which is the registered class name for the Window, or if that is NULL, it will search based on the window title, which is the second parameter. Malware typically will search for the class name. If you wonder how frequently this being used, here is a little help, to find malware which uses this technique. Cuckoo sandbox recently added some malware behaviour signatures to its feature set, and one of them is looking for this exactly, it can be found here:

https://github.com/cuckoosandbox/community/blob/master/modules/signatures/windows/antidbg_windows.py. It will add the description into the analysis page. https://malwr.com uses Cuckoo sandbox to perform malware analysis, and it's searchable on Google, with that simple search for this on Google, and you will get a bunch of samples:

"Checks for the presence of known windows from debuggers and forensic tools" site:malwr.com

For example:

https://malwr.com/analysis/NmMzYTYyNTJkOGViNGZiZjliOGEwZmRhMjg5YWU0OWU/

Various malware will behave differently if it finds the window, it might exit, or will try to close the window, etc...

With this, let's create our window.

I still can't really do Win32 API programming, so I use the power of copy-paste. I found two very good articles about making your first, empty window in Windows: 

https://msdn.microsoft.com/en-us/library/windows/desktop/ff381409(v=vs.85).aspx

http://www.winprog.org/tutorial/simple_window.html

You can read through this, the only thing I want to highlight is that the window will not be visible by default, you either create it with the appropriate flag, or call ShowWindow, as specified in the example. What if we don't show it? Well, as you would expect, it's not seen, you don't see it on the tray, nowhere, the program runs, and you can find it in the task manager, but no window. What happens if we call FindWindow this way? Based on numerous tests I did, it will always find it, regardless if you search based on class name or title. This is great, because we can start a process, which is completely hidden to the average user, consumes about 500kB memory, and about 0% CPU resources, but a malware will find it. Cool! Now we can hope that it will actually exit if it finds it.

Next question, is: do we need multiple processes to create multiple windows with different names? Based on my tests: NO. You can create multiple windows with different names, and you can hide all of them, and the FindWindow function will find all of them.

I also tried, what happens if I start WinDBG, which will register the same class name, but apparently it doesn't matter. You can run both programs at the same time, you can close them, and it won't cause any conflicts.

There is another method to find windows with GetWindowText based on the title, described here: https://stackoverflow.com/questions/16530871/findwindow-does-not-find-the-a-window, and that also works, it will find the window as well.

If I was an AV developer, I would hook the FindWindow function, and check if a process is explicitly looking for these windows, and if yes, I would raise a flag, because it's definitely not normal. Not sure if anyone does it, but it would be a fairly easy thing to do.

I created a PoC code to create an OllyDBG and WinDBG window, and another one, which will use FindWindow to find them. Both of them are available from my Github page:

https://github.com/theevilbit/vaccination/

The related Visual Studio projects are:

• FindWindow
• FakeDebuggerWindows

JavaScript deobfuscation: criminal case against you.wsf

A few months ago, I came across a malware dropper which was a javascript inside a Windows script file (WSF). The filename was: "criminal case against you.wsf". Typical... I'm a bit fed up with the naming, but anyhow... The file itself is somewhat interesting, because it can contain many types of scripts, and get them run in Windows if there is an interpreter. But this is not what I want to write about. The deobfuscation itself is not super hard, but after doing it I came across two really useful online tools, which can do this in a matter of seconds, and this is why making this quick post.

This one was new to me, and it is pretty handy:
http://deobfuscatejavascript.com/

I already knew about this, and it was useful in the last step:
http://jsbeautifier.org/

I really recommend everyone checking them out.

For completeness here is the file, which contains the original JS, and then each step of the decoding, it had 4 layers of obfuscation.
criminal case js deobfuscate.txt

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.