We are pleased to announce the immediate availability of the Gravwell Sysmon kit. This kit is designed to get you started quickly with Sysmon data and demonstrate the art of the possible. This post will cover the basic contents of the kit and then we will perform a quick investigation of a process that probably shouldn't be running on a corporate machine.
Getting Started
If you don't already have Sysmon installed and feeding data into Gravwell, go check out the Gravwell and Windows Event Logging post and also visit our documentation page on the Windows Event Service ingester. If you are unfamiliar with Sysmon events or what Sysmon is generally designed to do then I recommend starting with the "What's in a Sysmon Event?" posts part 1 and part 2, then reading the Sysmon DNS Threat Hunting post. We've also put together a quick video with a general overview of the Sysmon kit:
Installing The Kit
The Sysmon kit requires Gravwell version 4.1.3 or better. To install it, load up your Gravwell interface and navigate to the kits page, click on Manage Kits and you should see the Gravwell Sysmon Kit icon in the recommended kits section.
Click on the deployment button and Gravwell will resolve and fetch dependencies. The Sysmon kit uses the resources provided by two other kits (Network Enrichment and Windows Resources) which contain things like a geoip database, ASN database, and a few other network tools. If you have not previously installed other kits that depend on the Network Enrichment kit, the staging process may take a few moments. Once the Sysmon kit and its dependencies are staged, the install process will move through a series of dialogs to show you what you are installing and make sure you know what is about to happen.
Before you get too click-happy, take a moment to stop at the configuration dialog and set the appropriate tag that you have chosen for Sysmon data. This kit uses a configuration macro to specify which tags contain the Sysmon data; by default it is set to "sysmon", but I lump all my Sysmon data in with the other Windows events, so I am going to change it to include the "windows" as well:
If you clicked through and forgot to change the macro, or if you decide to change the tag containing Sysmon data, you can always update the configuration macro in the Macros interface.
Kit Overview
The Sysmon kit provides many resources for executing queries, investigating events, and just viewing the general state of your Sysmon data. However, if you are new to Sysmon or Windows events in general, the Overview playbook provided in the Sysmon kit is an excellent resource for getting oriented. The playbook goes into configuring the Sysmon service and some example configurations; it also dives into each of the Sysmon event types with a listing of data fields and example queries. There are also links directly to many resources like dashboards and query library items.
You should definitely check out the "Getting Weird With It" section at the bottom of the playbook. We show how to use some Sysmon registry events to identify when applications ask for access to the system microphone. Using those events we can calculate the amount of time a given application is using the microphone and sum them up. This query provided a great little table showing how much time a given machine had a hot mic, basically laying bare how much our CEO plays Player Unknown's Battlegrounds and Red Dead Redemption 2. Spoiler, it's a lot.
Dashboards and Actionables
A good place to start on the Sysmon kit is the Process Overview dashboard. This dashboard provides a ten-thousand-foot view of process execution data that is tracked by Sysmon. Which processes are tracked and the verbosity of the events is controlled by the configuration you chose when deploying Sysmon. I am using the SwiftOnSecurity config, so it is relatively quiet. There are a few useful items in the dashboard such as a total count of computers seen, unique image count, and some basic stats about product launches.
The Low Integrity tile shows products and file versions of processes that Sysmon determined to have "Low integrity". The Integrity metric is determined using a bunch of heuristics that Microsoft rolled out with Windows Vista. In a corporate environment with relatively strict deployment guidelines, this table can be extremely useful for finding unauthorized applications. More casual environments typically turn up games and bloatware that get updated a lot. The integrity of a process shouldn't be taken as gospel either -- case in point, an official signed Microsoft package is marked as low integrity on my gaming machine:
You may have noticed that many of the applications are underlined. That is because the Sysmon kit has an actionable targeting Windows application names. I can click on the "Discord.exe" application name and launch queries or open the process investigation dashboard.
The Process Investigation dashboard provides a jumping-off point to see some basic activity by any system that has launched that process. We can see network activity, file activity, overall event activity, and DNS lookups. This all looks normal, but if I saw Discord.exe reaching out to a bunch .cn or .ru domains when I am not in those countries, I might have some questions.
Let's Hunt
For this mock investigation we are going to dive into some Sysmon data and try to run to ground a specific application and its behavior. Let's start with the DNS overview dashboard, where we see that one of the most heavily-queried domain names is prod-live-xenuine.playbattlegrounds.com.
Lets click on that and see who and what has been querying this domain name.
We can see that 26 out of 27 lookups came from ExecPubg.exe, which is clearly PUBG, but there's another application, TslGame.exe, which queried the hostname once. Lets click on that application name and see what it has been doing with the Process Investigation dashboard.
We can see that the TslGame.exe process is generating many more events, creating files, creating other processes, and even setting some registry keys. We also see that within this time range only one machine has launched this application.
We can also see that there is a single SHA256 hash associated with the application name in that time range. If we click on that hash, there is an actionable to look for any other activity where that hash is present -- in other words, we can see if that same process was executed under any other name on any other machine.
The Sysmon SHA256 actionable works well to validate if the same application is running in multiple places on a single machine, or if multiple machines are running the same process. In this case we can pretty clearly see that this hash matches to the TslGame.exe executable that is running out of a Steam folder, particularly the PUBG folder.
Using a few clicks we were able to zero in and see a chain of applications requesting a single domain name and then pivot between views to classify whether other machines were running the same executable and what actions the executables were taking.
If you aren't familiar with the term PUBG, TslGame.exe is part of the launch sequence for a game called PlayerUnknown's Battlegrounds. It's a Battle Royale FPS that some of the Gravwell staff play together. We are terrible at it, but it's great fun.
Conclusion
The Gravwell Sysmon kit provides a great starting point for digging into Sysmon data and then pivoting through the various data types using actionables, investigative dashboards, and query templates. Sysmon often serves as a great tip-off point for Windows investigations and the Gravwell Sysmon kit simplifies that process through a packaged set of tools.
If you would like to see how Gravwell can enable your organization to collect more, search more, and hunt more, click the button below to schedule a demo with one of our Gravwell Guides.
.
