You’re probably reading this article because you understand how important Sysmon is to your environment. Without Sysmon, it’s difficult to log most endpoint actions unless you have advanced auditing turned on via your group policy; however, I believe not everyone is doing this.
Malware authors know how useful Sysmon is to threat hunting and detecting payloads being downloaded, or processes calling other processes so it only makes sense to kill or disable this service. Just as you monitor other things daily, we should also monitor the status of Sysmon and other critical processes running in our environment.
I went ahead and disabled or killed Sysmon and recorded the Event Id’s being generated to setup alert rules to ensure I get a notification anytime Sysmon fails for whatever reason.
Here’s the event ID’s that were generated:
Action 1: Manually Stopped Sysmon under Services:
System Event ID: 7036 – Sysmon service entered the stopped state.
Sysmon Event ID: 4 -Sysmon Service state changed
Action 2: Disabling the Sysmon Service
System Event ID: 7040 – Sysmon service set to disabled.
Action 3: Killing or terminating Sysmon.exe
System Event ID: 7034 – The Sysmon service terminated unexpectedly.
Here’s all the Event ID’s listed, as you can see they are located under System and Microsoft-Windows-Sysmon/Operational event viewer.
Sysmon Event ID: 4 -Sysmon Service state changed
System Event ID: 7034 – The Sysmon service terminated unexpectedly.
System Event ID: 7036 – Sysmon service entered the stopped state.
System Event ID: 7040 – Sysmon service set to disabled.
Here’s a query I came up with to easily filter through our events within ELK.
(event_id: 4 OR event_id: 7034 OR event_id: 7036 OR event_id: 7040) AND message: sysmon AND NOT (event_data.param2: running or event_data.State: started or event_data.param3: "auto start")
These are the results you’ll see which can help you investigate if there’s possible malware that is disabling or killing the sysmon.exe process.
Happy Hunting!