Hindering Exploitation by Analysing Process Launches

Malware can do some nasty things to your system, but it needs to get on there first. Thankfully, users have become more suspicious of files named FunnyJokes.doc.exe and so malware authors have had to become more innovative, using a mix of social engineering and the constant stream of 0-day browser exploits to land evil code on your box.

Popular infection methods include leveraging exploit kits to run arbitrary code in the context of your browser and 'infecting' documents files, such as Microsoft Word documents, which still, 20 years since the first macro virus, allow you to automate the downloading and execution of files. Recently I have been pondering the similarities between various attack types and how they present themselves on the end users machine. It strikes me that, more often than not, the endgame is launching a process by the targeted program.

This begs the question:

Is there ever a legitimate reason for Internet Explorer or Microsoft Word to launch a child process?

Of course there are exceptions, I'm not talking here about Internet Explorer launching a low integrity version of itself every time it runs, but something infrequently seen and significantly less trusted.

Common attack surface: macros

Let's start by looking at Microsoft Word macros, which are used by several current malware strains. If you interrogate the macro code you are likely to come across a call to the Shell() API, which is one method by which you can execute a process. It looks something like this:

Result = Shell("C:\windows\system32\calc.exe", vbNormalFocus)

No prizes for guessing what program is going to be launched here, but what is interesting is that the calculator launches as a child process of winword.exe (Microsoft Word), which can be seen in the ProcessHacker snippet show here:

Taking a look at a real world example, this neat analysis shows how again, based on the fact that this is dropped using a macro, we can see some strange child processes appearing from winword.exe - interesting!

Further attack surfaces: web browsers

How about Internet Explorer? Well, the desired outcome of any high-stakes exploit writing competition tends to look something like the picture below. Again, we can see the launched program is a child of the attack surface - in this case, iexplore.exe.

Again, in the real word, exploit kit authors leverage vulnerabilities in the browser and cause malware to spawn from iexplore.exe (see the image right at the bottom).

It appears a pattern is emerging!!

What can we do about it?

So here are my thoughts - if we watch for processes being spawned from these common attack surfaces we may be able to detect anomalous activity. I decided to experiment by writing a python script which does the following...

• Utilise WMI to detect new processes being launched
• For each new process launched, identify the name of its parent
• If the name matches that of a common attack surface (browser, word processor etc)...
• ...alert the user and terminate the process!

My code looks like this (and is available here):

When I tested it and made Internet Explorer launch calc.exe the result I got looked like this:

and boom! it's gone...

Running a python script in your environment may not be a viable solution, but if you have a flexible endpoint monitoring solution it may be worth considering implementing a rule to monitor for unexpected spawn!

Follow me on Twitter: @CyberKramer