Setting Up Sysmon

On November 23rd Microsoft / Sysinternals released a new version of Sysmon. Sysmon installs as a service and provides detailed logging information on items that are not normally logged in default Windows logging configurations.

Sysmon can be used to troubleshoot server issues, but today I want to outline how it can be used to detect Malware or other malicious activity on hosts.

The first step is to grab Sysmon from https://technet.microsoft.com/en-us/sysinternals/sysmon

There are a few options available to install Sysmon:

But the best option is through a config file - the Sysmon site has a default one available, but I am using a slightly tweaked version, here is the text that you can copy and save as an XML file.

* microsoft windows </DriverLoad> iexplore.exe </NetworkConnect> </EventFiltering> </Sysmon>

So now you have your Sysmon.exe and the config file - now what.

Open up an administrative command prompt and install using your XML config you made earlier:

The -i parameter tells Sysmon to use your config.xml instead of the default options.

Now for the fun part, let's go explore some logs.

Open up Event Viewer and navigate to Applications and Services --> Microsoft -> Windows -> Sysmon -> Operational - this is where all your Sysmon logs will go.

Close your eyes and pretend that an attacker managed to get Administrative credentials somehow and has now executed a Meterpreter payload on your victim system.

You got some long hours ahead no doubt, but at least you'll be able to see the malicious activity with Sysmon!

Here is the Meterpreter session executing:

Now let's see what Sysmon made of this. For context, my attacking machine is 192.168.1.15 and my victim machine is 192.168.1.124

Sysmon has logged an Event ID1 (Process Creation):

As you can see, there is tons of detail. This is a Meterpreter payload launching PowerShell.exe, hidden, with a Base64 encoded string. ( Note: This is cursery explanation, for more information on PsExec visit: https://community.rapid7.com/community/metasploit/blog/2013/03/09/psexec-demystified )

This is far beyond the level of detail that a Security event log will show.

Now you know that a malicious piece of code was executed on your system, but you are still unsure if this piece of malware is communicating back to an attacker. Fear not, Sysmon has you covered there as well.

Shortly after Event ID1 was logged, we see an Event ID3 (NetworkConnect):

Here we see my victim machine (192.168.1.124) connecting to the attacking machine (192.168.1.15) over SMB.

At this point, you have much more information regarding the malware that was just executed on your system; another piece of the puzzle.

An attacker is not going to just sit around and do nothing while "pwning" your box, they will try to escalate privilege, enumerate network information, dump clear text credentials and other fun stuff.

Thankfully, Sysmon can help here as well.

In the above image, an attacker is determining what account their shell is running under - here is the flip side, what Sysmon saw:

Another Event ID1 (ProcessCreate) - this time, we see whoami.exe being executed via cmd.exe

A useful way to think about the value of Sysmon - or any other defensively oriented security tool - is to compare its capabilities to the Cyber Kill Chain ( http://www.lockheedmartin.com/us/what-we-do/aerospace-defense/cyber/cyber-kill-chain.html ). Sysmon enhances your visibility into a number of critical areas of this chain: delivery, exploitation, installation and command and control.

I hope to make a few more posts covering Sysmon, including more advanced configurations, filtering out noisy events, the detection of Mimikatz ( https://github.com/gentilkiwi/mimikatz ) and how to work with Sysmon events via PowerShell.

That's it for now.