marvel90120
commented
2 weeks ago Hi Riccardo! Thank you for your question.
The team went back and did some additional research on this question to clarify if Sysmon Event ID 1 was user-mode or kernel mode.
Based on the research done by the team, Sysmon Event ID 1 is the most difficult Sysmon event to avoid triggering. As you mentioned, it unusually relies not on a function hook or userland artifact, but waits for a kernel callback to notify via through the "PsSetCreateProcessNotifyRoutineEx" function that a new process has been created. This routine is normally triggered by the driver any time a new process is registered with the kernel, at which point it notifies all drivers in its callback array of the new process registration. Although it is possible for the notification routine to be avoided, doing so generally requires modifying Sysmon or the driver itself, both of which are impractical and are out of scope of Summiting.
Because of this, we will be changing our scoring of Sysmon ID 1 from user-mode to kernel mode. It will be included in the next release of Summiting the Pyramid, so stay tuned.
Thank you for your question and staying engage with the Summiting the Pyramid project!
Resources used:
- https://github.com/trustedsec/SysmonCommunityGuide/blob/master/chapters/process-creation.md
- https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntddk/nf-ntddk-pssetcreateprocessnotifyroutineex
- https://www.alteredsecurity.com/post/when-the-hunter-becomes-the-hunted-using-custom-callbacks-to-disable-edrs
- https://synzack.github.io/Blinding-EDR-On-Windows/
Hi,
I was reading the introduction post and it seems that you mentioned that Sysmon event ID 1 (process creation) is a user mode data source? If my understanding is right, Sysmon should capture this via a kernel callback. Should this be a kernel mode data source?