After reading Sysinternals Sysmon suspicious activity guide I started playing with GPO/registry based rule changes for my own deployment of sysmon configs internally.
While testing, I noticed that Sysmon's EventID 16, the event logged when Sysmon detects a configuration change, does not occur when HKLM\SYSTEM\CurrentControlSet\Services\SysmonDrv\Parameters\Rules is modified directly.
To me, this is huge for an attacker. They have the ability to silently kill Sysmon on a machine without raising the alarm.
Consider the following example: I've applied a config using the -c argument on sysmon.exe, verified that a config state change event was generated, destroyed the config using Powershell without another event ID 16 being generated, and verified that Sysmon is now broken and may not be logging as defenders had intended. As an attacker I could have also brought in my own valid config that disables all logging as well 😁
So how could a defender detect this? As it turns out, with Sysmon!
If you add a RegistryEvent option to your config looking for modifications to SysmonDrv, you can spot someone messing with Sysmon in your environment.
Here's what my demo config looks like:
And here it is in action
شركة تنظيف مسابح بخميس مشيطReplyDelete
شركة تنظيف مسابح بجدة
شركة تنظيف مسابح بنجران
شركة تنظيف مسابح بمكة
No Deposit Bonus: Free Play & No Deposit Slots - drmcdReplyDelete
Play free no deposit casino 영천 출장안마 games and win 전라남도 출장샵 real money with 여주 출장안마 no deposit 의정부 출장샵 required. Play casino games 목포 출장마사지 and win real money with free spins.