Putting attackers in hi vis jackets with sysmon

Background

Sysmon (short for system monitor) has been part of the Sysinternals suite for several years.  It comprises kernel-mode driver and a Windows service that monitors system events and writes those to Windows event logs.   The fact that it is a kernel mode driver gives it a significant advantage over many other monitoring agents.  As an example, some monitoring agents claim to be able to capture process creation, however their approach may be to simply poll the process tree every second or so.   Any process launched outside of the polling window will be missed.   A kernel mode driver is “always on” and can therefore be programmed to capture every single process creation event.
As sysmon is a kernel-mode driver, it also has the ability to provide much greater visibility into the internal activity of the operating system.   Increasingly, malicious activity is occurring in memory, leaving little or no trace on the disk.  Memory forensics is the most robust method of detecting in-memory attacks but it is challenging to do this at scale and is expensive in terms of resources to perform.  Sysmon is no alternative to memory forensics, but it is an excellent tool for identifying systems that may be worthy of such an investigation.
Sysmon uses a configuration file to dictate what events can be captured.   A fairly recent development is the extension of the configuration file capabilities; this gives a high degree of flexibility in relation to the type of events that can be captured and the conditions that will trigger the logging of an event.

Installation

Installation is simple; to deploy to a single system, launch a terminal with administrator privileges and change to the folder containing sysmon and the configuration file.  Issue the command sysmon64.exe –accepteula –i config_file_name.xml
You should see some messages confirming that the installation completed successfully, as shown below:

 

Configuration

The configuration file should be tuned to your environment, making sure that known good events are excluded from logging (unless you want to use Sysmon for comprehensive process auditing).   Before deploying sysmon you should really understand what you want to use it for, as it has a number of use cases:

• Comprehensive process auditing – every single process, including command line activity can be logged.
• Malicious activity logging – interesting events that are indicative of malicious activity can be logged. This would include an executable in a users profile writing to a system process space.
• Desired state assurance – capture instances where your desired state is deviated from e.g. an expected HIPS process is absent or an unauthorised process is run.

This decision may be guided by your existing defensive posture.   If you have a SIEM in place then this could ingest your sysmon logs. However, if you use a Messages per Second payment model, this could significantly increase your costs if you have configured sysmon for comprehensive process auditing.   It may be that you have SCCM deployed and you could configure this for process auditing and configure sysmon to capture malicious activity.  Another consideration is the ability to use Windows Event Forwarding to forward potential malicious activity logs to a collector whilst retaining process auditing logs on the original host.
Once you have decided on the objective of your sysmon deployment, you can configure the configuration file.   If you want to perform comprehensive logging you will need to create a configuration file that logs the following:

• All process creation events
• All network connections
• All loaded drivers
• All image loading

If want to capture malicious events, you will be more interested in logging the following event types:

• Command line or PowerShell processes
• Suspicious network events e.g. those going to port 80/443 that aren’t initiated by a web-browser, email client, chat client etc.
• Unusual instances of process injection
• Unusual instances of a process accessing another process

In these circumstances you will need to establish what is “normal” in your environment.   Process injection and process access is used legitimately by a number of non-malicious processes.  You will need to discover what those are by deploying sysmon with a configuration file that captures all of those types of events, then exclude the events that occur normally in your environment (after you have confirmed that they aren’t malicious!).
Below is an extract from a configuration file that seeks to detect the lsass and cmd process spaces being accessed by another process.   The configuration file is XML based and allows the logging of event types and the filtering of the event types.   In our case, after configuring sysmon to include the logging of lsass and cmd ProcessAccess events we then filter out the logging of executables that legitimately access those processes.

 

Output

Once you have eliminated the noise being logged by sysmon, malicious activity becomes much easier to spot.    In a test we ran shellcode on a compromised system running sysmon and configured to capture events where the lsass.exe and cmd.exe process were accessed by another process, sysmon Event ID 10:

We can see that a suspiciously named source image has accessed cmd.exe.   Having done our tuning, we know that this is abnormal behaviour; this log would certainly cause us to investigate the source image.
Below is another example. In this case we have captured some interesting network activity using a configuration file that tuned out all the “normal” network activity.

We can see that PowerShell.exe has initiated an outbound connection to an external IP address on port 443.   This event would cause us to investigate that activity.

 

Security

You will need to think about counter-measures that attackers will take to try and bypass sysmon logging.   Therefore, it would be wise to monitor the system log for Event ID 1.  Below is an example of a System event log recording the shutdown of the sysmon service.

 

Conclusion

Sysmon is a free utility that provides a great deal of visibility into Windows systems.  The log format that it uses can be ingested by most SIEM solutions to provide real time detection of malicious events.  It’s well worth taking the time to get to know and implement it in your environment.