Sysinternals Sysmon unleashed


Introduction

Warning: This post recommends Sysmon monitoring policy implementations that are not official Microsoft recommendations. Readers are encouraged to review and test all policy recommendations prior to their implementation in a production environment.

Sysmon from Sysinternals is a very powerful Host-level tracing tool, which can assist you in detecting advanced threats on your network. In contrast to common Antivirus/HIDS solutions, Sysmon performs system activity deep monitoring, and log high-confidence indicators of advanced attacks.

Sysmon is using a device driver and a service that is running in the background and loads very early in the boot process.

Sysmon monitors the following activities:

  • Process creation (with full command line and hashes)
  • Process termination
  • Network connections
  • File creation timestamps changes
  • Driver/image loading
  • Create remote threads
  • Raw disk access
  • Process memory access

Some of these events can be gathered up by enabling Windows built-in auditing, yet the detail level provided by Sysmon is much higher. When it comes to analysis, Sysmon doesn’t provide any; you can use other tools to visualize and investigate the raw events, for example: SIEM, Microsoft SCOM, Splunk and Azure OMS.

Installation

Sysmon is a command-line tool; once downloaded from the Microsoft Sysinternals web site the installation is straightforward: Open elevated (“Run as Administrator”) command line and type the following command: Sysmon /?

Here is the output:

 

System Monitor v4.12 – System activity monitor
Copyright (C) 2014-2016 Mark Russinovich and Thomas Garnier
Sysinternals – www.sysinternals.comUsage:
Install: sysmon -i []
[-h <[sha1|md5|sha256|imphash|*],…>] [-n [<process,…>]]
[-l [<process,…>]
Configure: sysmon -c []
[–|[-h <[sha1|md5|sha256|imphash|*],…>] [-n [<process,…>]]
[-l [<process,…>]]]
Uninstall: sysmon -u
-c Update configuration of an installed Sysmon driver or dump the
current configuration if no other argument is provided. Optionally
take a configuration file.
-h Specify the hash algorithms used for image identification (default
is SHA1). It supports multiple algorithms at the same time.
Configuration entry: HashAlgorithms.
-i Install service and driver. Optionally take a configuration file.
-l Log loading of modules. Optionally take a list of processes to track.
-m Install the event manifest (done on service install as well).
-n Log network connections. Optionally take a list of processes to track.
-r Check for signature certificate revocation.
Configuration entry: CheckRevocation.
-u Uninstall service and driver.The service logs events immediately and the driver installs as a boot-start driver to capture activity from early in
the boot that the service will write to the event log when it starts.On Vista and higher, events are stored in “Applications and Services Logs/Microsoft/Windows/Sysmon/Operational”. On
older systems, events are written to the System event log.If you need more information on configuration files, use the ‘-? config’ command. More examples are available on the
Sysinternals website.Specify -accepteula to automatically accept the EULA on installation, otherwise you will be interactively prompted to
accept it.Neither install nor uninstall requires a reboot.

Let’s take a look at the install option available. Two basic options are offered:

  1. Set up the tool with default configuration
  2. Define the desired configuration directly from the command line or from a configuration file

Let’s start with the default configuration by running the following command:

C:\>sysmon -i -accepteula

System Monitor v4.12 – System activity monitor
Copyright (C) 2014-2016 Mark Russinovich and Thomas Garnier
Sysinternals – www.sysinternals.comSysmon installed.
SysmonDrv installed.
Starting SysmonDrv.
SysmonDrv started.
Starting Sysmon.
Sysmon started.

 

That’s it; Sysmon is now installed (installation, or uninstallation, does require a reboot).

The default configuration includes the following events:

  • Process create (with SHA1)
  • Process terminate
  • Driver loaded
  • File creation time changed
  • RawAccessRead
  • CreateRemoteThread
  • Sysmon service state changed

You can view the configuration by using the following command: Sysmon -c

Here is the output:

System Monitor v4.12 – System activity monitor
Copyright (C) 2014-2016 Mark Russinovich and Thomas Garnier
Sysinternals – www.sysinternals.comCurrent configuration:
– Service name: Sysmon
– Driver name: SysmonDrv
– HashingAlgorithms: SHA1
– Network connection: disabled
– Image loading: disabled
– CRL checking: disabled
– Process Access: disabledNo rules installedtd>

Once installed, Sysmon does its job automatically in the background. You can find out the results in the Event Viewer.

The events are written to Application and Services Logs/Microsoft/Windows/Sysmon/Operational log (For earlier – unsupported – versions of Windows, it places those under the Windows System log).

One thing that can help you here is to increase the event log size, I usually use 200 MB, with this command:

wevtutil sl Microsoft-Windows-Sysmon/Operational /ms:209715200 

 

sysmon1

 

Hashes

Many events include the hash value of the process. Hash value is the result of a calculation that was performed on a file, and used to uniquely identify files, as well as look up potential threat details  using online services such as TotalHash and VirusTotal.

For example, in this event we have an SHA1 hash for eventvwr.exe process: 7A2C326970EFF8B9E2194377078B22944808CB71

Sysmon3

Searching for this value in VirusTotal

Sysmon4

Yields the following result (Clean on all 56 Anti-Virus engines)

Sysmon5

From a malware analysis perspective, you’re better off using SHA256 or IMPHASH than MD5.

Configuration

Using the default setup option as we used above is limited, because we can’t apply advanced filtering and unleash the full potential of the tool.

Sysmon can be used with an XML configuration file, which allows you to use advanced and flexible filtering rules, specify the type of hashes and deploy it across the organization. The XML file can be applied during installation and changed any time later.

The XML file is divided into to two main sections: HashAlgorithms and EventFiltering

Sysmon2

 

 

 

 

 

Under EventFiltering you can select any supported event that you want to include or exclude, here we are using the DriverLoad tag as an example.

If you are just using the tag without a filter, the rule (onmatch) has opposite effect!

For example, this line will configure Sysmon to log all driver load events (because we are not using any filter):

<DriverLoad onmatch=”exclude“></DriverLoad>

While this line will configure Sysmon to log drivers load events except (filter) if the signature is Microsoft Windows

<DriverLoad onmatch=”exclude“>

<Signature condition=”is“>Microsoft
Windows</Signature>

</DriverLoad>

The XML configuration file supports the following conditions:

is  Default, values are equals
is not  Values are different
contains  The field contains this value
excludes  The field does not contain this value
begin with  The field begins with this value
end with  The field ends with this value
less than  Lexicographical comparison is less than zero
more than  Lexicographical comparison is more than zero
image  Match an image path (full path or only image name)

 

Full sample XML configuration file is available here: https://github.com/MotiBa/Sysmon/blob/master/config_v3.xml

Once applied, the configuration is stored in the registry under this key:HKLM\System\CurrentControlSet\Services\SysmonDrv\Parameters.

Events

Sysmon features some of the most effective events you need to collect to trace attacker activity and increase host visibility, you can consider the events as breadcrumbs that attackers drop along the way.

The recommendations shown here is intended only to be a starting baseline guide to administrators. Each organization must make its own decisions regarding the threats they face.
A common mistake is to only monitor servers or domain controllers. Since the vast majority of malicious hacking initially occurs on workstations, not monitoring workstations is ignoring the best and earliest source of information.

Event Class Event IDs Rate Author’s Recommendation Importance
Process Create 1 Low-Medium Log these events Detect initial infection and malware child processes.

Hashes captured by the Sysmon driver can be investigated using VirusTotal.com

Process Terminate 2 Low-Medium Log these events (for forensic investigations) Useful for forensic investigations. May be correlated with process creation events
Drive Load 6 Low Detect device drivers loading
Image Load 7 High Log these events (for forensic investigations) Detect DLL injection, unsinged DLL loading
File Creation Time Changed

 

2 Medium-High Log these events Detect anti-forensic activity (timestamp changed to cover tracks)
Network Connection

 

3 High Log these events (use filtering) Identify network activity, connection to malware C&C servers, connection to ransomware server to download encryption keys
CreateRemoteThread

 

8 Low-Medium Log these events Detect  code injections used by malware

Credential theft tools also use this technique to inject their code into the LSASS process

RawAccessRead 9 Low Log these events Detect dropping off SAM or NTDS.DIT from compromised hosts
Comments (2)

  1. Jeff says:

    I have the latest version of Sysmon (6.01) installed and have the following lines to filter out some noisy Splunk executables:

    C:\Program Files\Splunk\bin\splunkd.exe
    C:\Program Files\Splunk\bin\splunk.exe
    C:\Program Files\Splunk\bin\splunk-optimize.exe
    C:\Program Files\Splunk\bin\splunk-MonitorNoHandle.exe
    C:\Program Files\Splunk\bin\splunk-MonitorNoHandle.exe
    C:\Program Files\Splunk\bin\splunk-netmon.exe
    C:\Program Files\Splunk\bin\splunk-regmon.exe
    C:\Program Files\Splunk\bin\splunk-winprintmon.exe
    btool.exe

    However, when I check the logs in Splunk, I’m still seeing those executables.

    Any ideas as to why these aren’t being filtered out?

    Thx

    1. Cad says:

      You should really post the XML section you have, but I’ll just say this.. Make sure you’re applying the config to all your systems. Use Sysmon -c to dump the active configuration of a system that’s reporting the exe activity and make sure it’s correct. Make sure your XML is correct C:\Program Files\Splunk\bin\splunkd.exe or use C:\Program Files\Splunk\bin\

      My guess is that you didn’t apply the configuration file to the machines that are reporting the activity, or you are using it under the wrong section. Is this process create? Is it network? Make sure you use and put it under there or if its event ID 3 vs. 1.

      Hope this helps!

Skip to main content