Request for option to carry process creation detail fields into other Sysmon event types

Kevin Branch 0 Reputation points
2024-05-22T20:25:15.41+00:00

In Sysmon "Process Create" events, the details are invaluable, but many times I have wished that at least key process creation details like CommandLine, ParentImage, ParentCommandLine, and Hashes, could be carried over to other event types that account for actions taken by those created processes.

Many times in tuning my SIEM's detection rules involving Sysmon network or registry change events, the key piece of information needed to identify the nature of the event, is only available in the original process creation event, likely in in CommandLine, ParentImage, ParentCommandLine, or Hashes.

When I manually follow up on a suspicious Sysmon event other than type "Process Create", I will pivot on the ProcessGuid over to the original "Process Create" event in order to inspect the details I need to more adequately evaluate the action taken by the created process. However, for multiple reasons, this does not translate over to automated orchestation very well at all for me.

For example, I want to be create SIEM detection rules for certain kinds of Sysmon "Network Connection" events that are able to directly factor in process creation attributes of the process that created the network connection. Many obvious false positives with suspicious network connections are only evident once I see the CommandLine details and/or the ParentImage/ParentCommandLine details for the process.

For this to be possible, I am requesting a Sysmon configuration option to enable the carrying of "Process Create" event detail fields over into the other Sysmon events tripped by those created processes. I'm sure there is already some kind of process state table being maintained by Sysmon at all times anyway, from which this kind of detail could be plucked for the enrichment of other kinds of Sysmon events.

This might involve a fixed set of higher-value process creation fields like CommandLine, ParentImage, ParentCommandLine, and Hashes. Or it could be a configurable list of what process creation event fields to carry over. Or it could just carry all process creation detail fields across in a simple all-or-nothing approach.

If this is at all architecturally feasible, I believe something along the lines of the above would ultimately prove invaluable to empower the Sysmon user community to create more powerful detection rules to scrutinize Sysmon records about actions taken by existing processes.

Would you all consider adding such an option? Is this the best place for me to make this request or should I take it elsewhere?

Thanks for your consideration of my request, and for all the value that Sysmon has brought to my work over the last number of years.

Kevin Branch

Sysinternals
Sysinternals
Advanced system utilities to manage, troubleshoot, and diagnose Windows and Linux systems and applications.
1,174 questions
0 comments No comments
{count} votes

1 answer

Sort by: Most helpful
  1. Dave Schob 0 Reputation points
    2024-10-16T14:36:38.4666667+00:00

    I like this idea as well. Our automated testing uses Sysmon's gathered events as a baseline to compare against our driver. I can certainly see some scenarios where your feature could be helpful.

    Half the reason I'm commenting, however, is to let you know this is being seen (by at least me ;)). I'm finding it difficult to know how much this Q&A for Sysmon/SysInternals is reviewed. I also have a posted question getting zero interaction: https://learn.microsoft.com/en-us/answers/questions/2030568/sysmons-reported-commandline-adds-extra-percent-ch
    Admittedly, my issue is relatively trivial for must users but I would appreciate it if you could let me know (here or there) that it is at least properly posted.

    0 comments No comments

Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.