Introducing Sysmon Config Pusher
When providing various services to clients, including Purple, Blue, and Red Team engagements, the Lares team often recommends Sysmon to close detection gaps. Indeed, Sysmon is an incredible and freely available tool that enhances visibility across Windows systems and provides rich data and telemetry from which to build alerting, detections and undertake proactive threat hunting efforts.
In recent years, an entire ecosystem of Sysmon configurations, presentations and various tools has cropped up, supported by members of the InfoSec community. Although Sysmon is now well-known and supported, the barrier to entry for some organizations is still too high. Installing and configuring Sysmon on a handful of systems is simple enough, but deploying Sysmon and managing its configuration files – particularly across a large and diverse fleet of endpoints – has remained a challenge.
Installing and Updating Sysmon
Traditional methods of updating and installing Sysmon to your endpoints have entailed setting up Group Policy Objects (GPOs) with some form of a scheduled task that runs a script which checks a directory for a newer version of a Sysmon configuration than is installed on the endpoint. If a newer configuration exists on the central share, the endpoint then updates its Sysmon configuration to the newer version. A few examples of this approach:
- https://m365internals.com/2021/05/17/how-to-deploy-sysmon-and-mma-agent-to-receive-logs-in-azure-sentinel/
- https://www.syspanda.com/index.php/2017/02/28/deploying-sysmon-through-gpo/
This approach works well and is effective. However, managing a successful Sysmon deployment means that you are constantly tweaking your Sysmon configuration file in order to strike a delicate balance between data coverage, system performance and noise.
Different machines in modern day networks have different suites of applications installed and these various applications all have different impacts on your Sysmon configuration. What if, for example, you wanted to exclude a particular directory from ProcessCreate events on one group of endpoints but not another? In a similar vein, you may want to deploy a minimal Sysmon configuration to performance-sensitive endpoints and a more comprehensive configuration file on more performant endpoints.
Using the above methods, each of these classes of endpoints would require a different GPO, which point them to a different version of your Sysmon configuration file. As you can probably imagine, this situation could quickly result in a large number of GPO objects and can become difficult and untenable to manage.
A New Approach – Pushing Sysmon Configs
The scenario described above is what Sysmon Config Pusher aims to solve by giving users the ability to "push" various Sysmon configuration files, organized by tags, to various systems on their network.
Let us take a brief look at how the app works in the following video:
More detailed information, download links, as well some security considerations are found in the GitHub Repo for SysmonConfigPusher:
https://github.com/LaresLLC/SysmonConfigPusher
It is our hope that SysmonConfigPusher will lower the bar of entry to Sysmon deployments and would provide additional flexibility to teams managing a Sysmon deployment in their networks. SysmonConfigPusher is free to use and download and contributions from the community are more than welcome.
Sysmon Resources
If you are just starting out with Sysmon, check out the following resources and Twitter feeds to help you get started.
- https://github.com/trustedsec/SysmonCommunityGuide
- https://marketplace.visualstudio.com/items?itemName=DarkOperator.sysmon
- https://github.com/SwiftOnSecurity/sysmon-config
- https://github.com/olafhartong/sysmon-modular
- https://twitter.com/Cyb3rWard0g
- https://twitter.com/ionstorm
- https://github.com/MHaggis/sysmon-dfir
- https://github.com/nshalabi/SysmonTools
- https://github.com/darkoperator/Posh-Sysmon