Introduction

Sysmon v7.0 is out since yesterday and we want to try it out as soon as possible and share with you our findings. We are going to discuss what are the new features introduced in this latest version and how we can use those in order to improve our threat hunting capabilities. We will also discuss the changes on a design point of view and how to address a proper deployment of this new version.

What is new ?

News in the Sysmon command line options

Athough this option was already introduced in the previous version 6.20 there is now the possibility to define at installation time the driver name we want Sysmon to use instead of the default name SysmonDrv.sys.

  -d   Specify the name of the installed device driver image.
       Configuration entry: DriverName.
       The service image and service name will be the same

This new option also mentions that the name of the service will be the same name as the service executable (the one used for installation). When we download Sysmon the common name for the installer is Sysmon.exe. So, if we do not change the name of that installer, the name of the Service will be Sysmon which not stealth at all.

These new features are quite interesting because it goes a step further into hiding Sysmon. One could for instance install it with very generic names for both the driver and the service to prevent simple path existence checks to be sucessful. This simple counter measure can certainly fool simple malware or poor threat actors, however we have to bear in mind that it is not the panacea. For instance many other things, more difficult to hide, can still indicate the presence of Sysmon (strings in service and driver binaries, evtx file ...)

News in the Sysmon Events

Doing a diff between the schema of Sysmon v6.1 and v7.0 we can notice the new fields introduced in both events ProcessCreate and ImageLoad.

diff sysmon-v6.1-schema.xml sysmon-v7.0-schema.xml
1,2c1
<
< <manifest schemaversion="3.4" binaryversion="1.01">
---
> <manifest schemaversion="4.0" binaryversion="1.01">
10a10
>       <option switch="s" name="PrintSchema" argument="optional" noconfig="true" exclusive="true" />
17a18
>       <option switch="d" name="DriverName" argument="required" />
34a36,39
>       <data name="FileVersion" inType="win:UnicodeString" outType="xs:string" />
>       <data name="Description" inType="win:UnicodeString" outType="xs:string" />
>       <data name="Product" inType="win:UnicodeString" outType="xs:string" />
>       <data name="Company" inType="win:UnicodeString" outType="xs:string" />
101a107,110
>       <data name="FileVersion" inType="win:UnicodeString" outType="xs:string" />
>       <data name="Description" inType="win:UnicodeString" outType="xs:string" />
>       <data name="Product" inType="win:UnicodeString" outType="xs:string" />
>       <data name="Company" inType="win:UnicodeString" outType="xs:string" />

To give you a closer look to what actually is new, hereafter is just an examples of an ImageLoad event (converted to JSON) with those new fields.

{
  "Event": {
    "EventData": {
      "Company": "Microsoft Corporation",
      "Description": "Server Service Client DLL",
      "FileVersion": "6.1.7601.17514 (win7sp1_rtm.101119-1850)",
      "Hashes": "SHA1=3207AC7F895EAB34623D994548D7810E54BE3E79,MD5=3A9C9BAF610B0DD4967086040B3B62A9,SHA256=E8E9A0F42B1EE7806EDCEED08AA024D037215D06CA317E3678BD5364AD513D23,IMPHASH=2D37F2D4B3C246F361CA150FC7EBF8D4",
      "Image": "C:\\Program Files\\Mozilla Firefox\\firefox.exe",
      "ImageLoaded": "C:\\Windows\\System32\\srvcli.dll",
      "ProcessGuid": "49F1AF32-B634-5A4C-0000-001016B24F0D",
      "ProcessId": "672",
      "Product": "Microsoft Windows Operating System",
      "Signature": "Microsoft Windows",
      "SignatureStatus": "Valid",
      "Signed": "true",
      "UtcTime": "2018-01-03 18:55:43.803"
    },
    "System": {...}
  }
}

Many ImageLoad Events ...

While we were doing our experiments, we noticed an important change, which must be taken into account by anyone who wants to deploy or update Sysmon enterprise wide. More specifically if one plans to feed a SIEM with the Sysmon events collected on the hosts.

We have noticed an incredibily huge amount of ImageLoad events compared to the previous versions of the software. Hereafter are some statistics about the Events Per Second (eps) for each Event ID showing this.

Start: 2018-01-03T18:59:55Z
Stop: 2018-01-03T19:04:46Z
TimeLastEvent: 2018-01-03T19:04:45Z
Duration (stop - start): 5m0.1181641s
EventCount: 264888
Average EPS: 882.61 eps
EventIDs:
     1: 17 (0.06 eps)
     2: 3 (0.01 eps)
     3: 4 (0.01 eps)
     5: 8 (0.03 eps)
     7: 252886 (842.62 eps)
     9: 6 (0.02 eps)
     10: 7673 (25.57 eps)
     11: 139 (0.46 eps)
     12: 3863 (12.87 eps)
     13: 212 (0.71 eps)
     17: 8 (0.03 eps)
     18: 69 (0.23 eps)

If in the past one could afford to push every single Sysmon event into a SIEM, doubt it would be the same after a migration to v7.0. In order to understand why this happened, I isolated the process responsible for loading many images. And the winner is ... C:\Windows\Sysmon.exe. We now understand that adding the image information fields to the events has a cost. Tought I do not now anything about how Sysmon is implemented (and probably too lazy to reverse it), I would bet that before extracting the information the image is fully loaded into memory by the service itself. That is to say that if you do not want your SIEM to explode, you would better to addapt a little bit your Sysmon configuration file with the following (assuming you installed the service with the default name).

<ImageLoad onmatch="exclude">
      <Image condition="is">C:\Windows\Sysmon.exe</Image>
</ImageLoad>

We have issued the same benchmark as we did before but this time with the adapted Sysmon configuration. We notice that the amount of event logged by Sysmon is drastically reduced and looks like what we were expecting to see in the first benchmark.

Start: 2018-01-03T18:51:14Z
Stop: 2018-01-03T18:56:03Z
TimeLastEvent: 2018-01-03T18:56:01Z
Duration (stop - start): 5m0.1992188s
EventCount: 13423
Average EPS: 44.71 eps
EventIDs:
     1: 11 (0.04 eps)
     2: 2 (0.01 eps)
     3: 4 (0.01 eps)
     5: 17 (0.06 eps)
     7: 806 (2.68 eps)
     8: 1 (0.00 eps)
     10: 8032 (26.76 eps)
     11: 149 (0.50 eps)
     12: 3986 (13.28 eps)
     13: 331 (1.10 eps)
     17: 8 (0.03 eps)
     18: 76 (0.25 eps)

What can we do with those new things ?

In this section we are going to discuss about what we can do with the new image information recently added into CreateProcess and ImageLoad events. I am listing my tought, so that means that they may be bad ideas and that other people might have better ideas than me. Those ideas need to be validated through wide monitoring and the outcome might depend on your environment. Is not it why we love hunting ? “My mom always said hunting was like a box of chocolates. You never know what you're gonna get.”

I do not formalise those thoughts into any form of detection rule so that you can adapt to whatever tool you are using to refine your Sysmon logs.

Better detect process / service Hijacking

Better detect copies of Windows Tools

Enhance detections based on heuristics

Detections based on heuristics is the one that has the highest potential raise false positives. However, if the heuristics are good it should not be the case and this can in some cases lead to interesting alerts.

Conclusions