Sysmon is missing Process Access events RRS feed

  • Question

  • We are developing a kernel mode driver and comparing our driver's collected events to Sysmon.  Intermittently but frequently I am seeing missed Process Accessed events from Sysmon.  In our test we fire up both drivers, launch several test processes many times and then check to make sure the events match by gathering our driver's events directly from the driver and Sysmon’s events from the event log.  The discrepancy is with one of our test processes: netstat -b.

    Netstat -b appears to create process handles to every process that has an open network connection, once for each connection.  When the discrepancy occurs, the two drivers' events match perfectly from the beginning of a netstat's execution up to a point just before that netstat exits. Sysmon does not report some of the final Processed Accessed events that our driver does report (see attached image).  When this occurs, it's anywhere from one to as many as 10 missing events, all at the end of that netstat's life.

    To confirm this Sysmon bug, I’m saving to file the console output from each netstat -b (adding -o to get the target PID).  When the discrepancy occurs, I can locate the saved, PID specific, netstat output file and confirm that indeed that netstat reported connections at the end of its output that our driver has logged but Sysmon has not.

    Other considerations taken into account:

    • The test launches netstat -b many times. When the compare fails (as described above), it’s usually for netstats in the middle of the list of executed netstats... so it's not simply that the event log is filling up (not to mention that I have the log size set far bigger than the test needs.)
    • I've seen this with both Sysmon v10.2 and v10.41
    • I’ve seen this on several OSs including Win7 and Win10.
    • To rule out some interfering driver, I've tried assigning our driver's altitude next to Sysmon's 385201 (both one above and one below) with no change in results (though I’m not completely sure this altitude re-assigning did what I think it did.)

    Sysmon config file used for this test:

    <Sysmon schemaversion="4.22">
     <!-- Capture MD5 and SHA1 hashes -->
       <!-- Events to include -->
       <ProcessCreate      onmatch="exclude" />
       <ProcessTerminate   onmatch="exclude" />
       <DriverLoad         onmatch="exclude" />
       <CreateRemoteThread onmatch="exclude" />
       <RuleGroup name="netstat" groupRelation="and">
         <ProcessAccess      onmatch="include" >
           <SourceImage condition="end with">netstat.exe</SourceImage>
       <!-- Events to exclude -->
       <ImageLoad            onmatch="include" />
       <FileCreate           onmatch="include" />
       <FileCreateStreamHash onmatch="include" />
       <FileCreateTime       onmatch="include" />
       <NetworkConnect       onmatch="include" />
       <PipeEvent            onmatch="include" />
       <RawAccessRead        onmatch="include" />
       <RegistryEvent        onmatch="include" />
       <WmiEvent             onmatch="include" />

    Image notes:

    Image contains both the compare results (left) and the output for the netstat that failed the test (right).

    In the compare image:

    • Lines are in the order received by each driver.
    • sysmon is on the left (note missing 15740 events) and our driver’s events on the right.
    • Blue numbers are line numbers (first 776 events matched perfectly)

    Columns are: SourceProcessId (netstat) >> SourceThreadId >> TargetProcessId >> GrantedAccess (int) >> GrantedAccess (hex). 

    “True” denotes the event is a process access (rather than a thread access) and is not relevant here.

    Note in the netstat output that the target PID for the 6 missing events matches both our driver’s output AND prior Sysmon output from a prior netstat.


    Tuesday, November 12, 2019 7:27 PM

All replies

  • 2 followups:

    1. Forgot to mention that I have manually checked the event log for these missing events and they are indeed not there.
    2. Noticed in my sample output that a target PID (5136) happens to have the same value as the GrantedAccess integer.  This is an unfortunate coincidence and not an issue: if I restart that LMS service to get a different PID, the problem still occurs.


    Tuesday, November 12, 2019 9:24 PM