In part 1, I talked about MITRE ATT&CK, Sysmon and how my modular configuration is built up. Obviously you also need a way to get it installed on your endpoints or servers, ideally without too much manual interaction.
This post will cover installing Sysmon, keeping it up to date in terms of software as well as configuration and ingesting it into a centralized logging solution.
Deployment and maintenance
There are probably multiple options apart from the ones I'll be covering, these are the ones I prefer, any suggestion for improvement is always welcome.
To get started we need to get Sysmon installed, in a Windows Domain environment you can utilize the native method of either baking it into your golden images, using Microsoft SCCM or install it through a Group Policy. There are several fine blogposts on this like the one by Pablo Delgado. Essentially you're putting your executable and configuration on a file share and kick of a script through the GPO.
This works quite well, however most organisations I encounter have separate security and IT team, for great reasons btw. This also often introduces some less ideal situations. For instance updating your configuration requires write access to the share, and depending on the GPO script you're using you might need the GPO edited as well. This will not be quick, while sometimes when uncovering a new attack technique you require visibility across the environment as soon as possible. An additional downside to this approach obviously is that you're required to have all machines to be joined to a domain, which is not always possible or allowed.
Since I mostly work for clients that are using Splunk, I decided to create a small app. Splunk has the option to use a deployment server.
This is a role you can assign to a Splunk Enterprise server. This server will be the configuration sever for all locally installed Universal Forwarders (logger agents) that you point towards it. On the deployment server you can create a Sysmon class that is assigned to all Windows clients, to this class you can add the app I created.
Sysmon deploy and maintain | Splunkbase
Deploy and maintain Symon through the Splunk Deployment Server. This will enable you to have all systems running the…
This app when deployed to a machine, will check whether Sysmon service is already running on the system, when it is it will validate the version. If its version is below the configured version (currently 7.03), it will uninstall that version and install with the attached configuration. When it doesn't find the service it will proceed to install the supplied version.
I chose to use a batch file, where I also could have used PowerShell. The main reason for this is compatibility, I wanted to make sure it was running on any Windows box. This script is set to run once after deployment of the application.
Updates are installed through the same app, again you could use GPOs to do this as well. By default every 12 hours it will check for a new configuration by comparing it with its running version. Should it be different it will update the service with the latest configuration.
Universal Forwarder; Since I'm using the Universal Forwarder in this case the ingestion is relatively straight forward. You can choose to deploy the Technology Addon from Splunkbase
Add-on for Microsoft Sysmon | Splunkbase
Provides a data input and CIM-compliant field extractions for Microsoft Sysmon. The Microsoft Sysmon utility provides…
Another, more light weight option is to add the following to your inputs.conf file;
Windows Event Forwarder; Should you be in a fully managed domain joined environment you can also use the Windows Event Collector (WEC)+ Windows Event Forwarder (WEF) Setup. This is quite a nice Microsoft native way to aggregate your logging. In order to get this running you need to set up a WEC server, which is just a normal Windows server with a large disk set.
Through some GPOs you'll define which logs you want to subscribe to, so what the clients will be sending you. All logging will be forwarded to the WEC from where you can ship it to your SIEM or preferred logging solution.
This post covered deploying and maintaining Sysmon and its configuration, the former part covered;
next topics will cover;
- Detect Sysmon tampering
- How to start interpreting the logging to help you tune your config
- My Threat Hunting app for Splunk based on ATT&CK