bobby-mack
commented
1 year ago Just a quick follow-up to my original inquiry on this -- it's not just network connections that are affected; it's every process that grinds to a screeching halt. I believe I've narrowed down the culprit to force-killing the Sysmon64 service as part of my update script, prior to actually passing the -c param and specifying my new config. Attempting to force-kill the process like this:
PowerShell -Command "Get-Process Sysmon64 | Stop-Process -Force"
...results in the command seemingly hanging forever, with some very nasty side effects. In particular, the entire system hangs on any kind of existing or new commands, which ultimately winds up requiring a force reboot by holding down the power button on a physical device, or doing a soft reset of a VM.
It's still a mystery to me why this behavior all of a sudden changed in 14.14; is due to some kind of anti-tampering mechanism or kill switch baked into the service design? Just a theory based on being able to reproduce this myself.
I had noticed a couple registry detections for Sysmon included in the "default" config here, but that shouldn't influence my ability or inability to start/stop services. I feel like I'm missing something here.
`
technion
Following an upgrade from Sysmon version 13.33 to 14.14 (latest) with the "default" pre-generated configuration (balanced config / most used) -- we ran into serious network complications with Windows servers (2016/2019), that essentially rendered them inoperable until a server reboot (i.e. no connections could be made... the servers were actively refusing any inbound connections). I don't really know if the Sysmon config itself would play a part here or not, but I was of the understanding that a restart was not required to commit changes to Sysmon and a simple service recycle would suffice there. Perhaps this is some kind of bug in the upgrade jump or something with the service itself, but I would like some clarification if others can speak to this. Looking for any feedback!