Installing & Configuring Sysmon on Windows Server 2019 - cfloquetprojects/homelab GitHub Wiki

Introduction

In a world of frustrating obscurity behind various Windows Event codes that seem to be notorious among the likes of Microsoft Systems Administrators, Sysmon has the unique ability to report on granular details at the operating system level while filtering out much of the noise.

Sysmon, from the Sysinternals suite, is ideal for advanced threat detection, as it gives us unparalleled insight into the processes, connections, and other activity on a particular system that we can monitor against high-confidence indicators obtained from different threat intelligences sources.

Sysmon is capable of monitoring the following activities on the local operating system:

• Process creation (with full command line and hashes)
• Process termination
• Network connections
• File creation timestamps changes
• Driver/image loading
• Create remote threads
• Raw disk access
• Process memory access

While we will not be implementing all of these options today, it's important to realize the potential of this tool in the wider scope of security monitoring, and how powerful it is not only in threat detection and prevention, but incident response as well.

Downloading & Installing Sysmon

Sysmon can be downloaded from here to kick off our installation process.

While the default installation for Sysmon is functional and fine for lab purposes, we can also get a jump start on a very impressive set of logging capabilities by employing the use of SwiftOnSecuritys' sysmonconfig-export.config configuration.

For those of us who would rather have a simple one-liner that grabs that script and saves it to the C:\Windows\ folder (change the destination folder as you wish), run the following command from an elevated command prompt:

C:\> curl https://raw.githubusercontent.com/SwiftOnSecurity/sysmon-config/master/sysmonconfig-export.xml > C:\Windows\sysmon-config.xml

Once we have Sysmon downloaded and extracted into your desired directory, navigate to it's working directory within that same elevated command prompt and run the following command to install Sysmon on a x64 based system, using -accepteula flag to prevent another dialog, and the -i flag to designate a specific installation config file (which we obtained from SwiftonSecurity).

C:\path\to\sysmon\folder> Sysmon64.exe -accepteula -i C:\Windows\sysmon-config.xml

Introduction to Event IDs within Sysmon:

Sysmon uses a slightly different alerting system, numerically speaking, than traditional Windows Event Logs, which catagorize themselves into distinct high-level event categories that themselves aren't indicators of malicious behavior, but upon investigation and when combined with other contextual evidence can help investigators piece together what is actually happening on a given system.

A full list of Events generated by Sysmon is available on their download page here, so for now we will only review the first three, which are rather important:

Event ID 1: Process Created

• Provides helpful information (including the full command line) surrounding the execution of the given process, while creating unique values for each process to make correlation of these events easier across a larger domain/enterprise. The hash value is also returned as a parameter in this event, which is useful for better detection of malicious files.

Event ID 2: Process changed a file creation time

• Simply tracks any changes made to the file creation time made explicitly by a certain process, like Event ID 1, there are also legitimate uses cases of this, so it's not necessarily indicative of malicious activity.

Event ID 3: Network Connections

• While this event ID is disabled by default, it's tremendously useful for tracking any & all connections to a particular machine. Includes source and destination addresses, port numbers, etc.

Viewing Generated Sysmon Logs using Event Viewer

By navigating to Start > Event Viewer within the host, we should be presented with the Event Viewer GUI.

Within Event Viewer navigate to the folder for Sysmon via Applications and Services > Microsoft > Windows > Sysmon (shown below)

Once we scrolled down to find the Sysmon folder, expand it to view the Operational settings, where we can see the events being generated on the local system.

Now that we know Events are being created and tracked by Sysmon, we can test our config file by simply creating a new file within any given folder, shown below using cmd:

If our configuration was successful, we should immediately see an event within Event Viewer after going to Actions > Refresh in the top left hand corner.

Forwarding Sysmon Logs to Splunk SIEM using UF:

If you haven't already, now is a good time to restart your host and sign back in as the local administrator, so we can install the Splunk UF on the local system and have read access to the necessary file directories we will be monitoring, namely our Sysmon logs.

Begin the installation of the Splunk UF on your local host by creating a free Splunk.com account and downloading the latest version of UF, both of which can be done using this link

Once the installer is downloaded, run it as the local administrator account, and after a few moments we will be greeted with the following screen, where we should choose to Customize Options which will give us more control over our installation.

Go ahead and use the default installation directory, and hit Next to get to the next page.

💡: I have chosen to upload the certificate from our Issuing CA that was installed and configured in a guide I wrote earlier which can be found here, if this is something that interests you. This however is not required for the purposes of this lab.

Go ahead and check all of the boxes under Windows Event Logs, as we want to be sure to expand the scope of our log collection as much as possible from a security perspective. Performance metrics are important, but won't be included for analysis for the purposes of this lab.

💡: I have also chosen to include our Sysmon file path, which is shown below in the picture. This can also be done post-installation using the add monitor command, the decision is yours.

Set the desired credentials to be used for managing this specific forwarder:

💣: Note that these are not the credentials for your Splunk indexer instance, and should never be shared outside of your Splunk environment. These credentials are unique to this forwarder and this forwarder alone.

Now we get the chance to designate our Deployment Server, which in our case will the same as our Receiver which we will define in the next step:

Receiving Indexer should be configured in a similar manner as the Deployment Server, using the default ports as nessecary:

You should now be all set to install the UF, and once it has successfully completed you can hit Finish as shown below:

We can confirm that the Splunk Universal Forwarder is running, as well as if our Sysmon log file is being monitored by issuing the following commands within the C:\Program Files\SplunkUniversalForwarder\bin directory on the local host from an elevated command prompt:

💡: In terms of actionable use cases we will be able to use leveraging this data, there will be a guide soon on integrating threat intelligence data (obtained via API) from AlienVaults' Open Threat Exchange (OTX) program, particularly surrounding the monitoring of hashes of the processes being executed on the system.