In part one I touched on logging and the importance of working with what you have already got, rather than trying to reinvent the wheel. There is no point adding more logs if you’re not looking at what is already there. The same can be said for what a vast amount of businesses have in one form or another, Microsoft Windows. There is a lot of information to be gleaned from Windows processes. The thing with processes is that there are a lot of them, and it can seem massively overwhelming, However with a bit of patience and the aid of a book or three (which I will touch on at the end of this post) you can get really quite far under your own steam.

This obviously requires some form of logging of process trees in a multi host/network scenario, there are a good number of products out there that do this now, especially with buzzword bingo firing on all cylinders, if your endpoint product/agent declares itself ‘next gen’ it should do this. We however, will look at these processes from a single host perspective for the sake of this write-up. The rules and theories will be the same though.

First off we need to arm ourselves with ‘Process Explorer’, which is part of the Windows Sys Internals Suite which can be found at https://technet.microsoft.com/en-gb/sysinternals/bb842062

and when fired up looks a bit like this:

All those lovely processes!

So, lets take a look shall we?

System/Idle

These two are special. Why? Well they are not technically full processes. They are not running a user-mode executable as they are both created by ntoskrnl.exe (NT OS Kernel), which as the name implies means it is running in kernel mode. More information on the difference between user mode and kernel mode can be found here:

Some key features of these two processes are:

Neither should have a visible parent process

In the case of the idle process it should be operating one thread per CPU as seen here on my quad core machine.

The PID value for System is always 4:

There should only ever be one instance of System:

What can we look for: