Categorizing and Enriching Security Events in an ELK with the Help of Sysmon and ATT&CK

Lately, I have been working on a few projects such as OSSEM, HELK and ThreatHunter-Playbook with a main goal of integrating all of them and starting to document and define how data can drive categorization and prioritization of detection analytics. 

I also had the opportunity to present with @_devonkerr_ from Endgame at BSidesCharm at the beginning of the year about "Quantifying Your Hunt".  We talked about how we could start measuring detection capabilities by mapping available data sources to MITRE ATT&CK Techniques. I enjoyed our conversation because we were able to prioritize specific data sources we could use to increase visibility across several ATT&CK techniques. One particular free tool that provided a lot of context across several techniques was Sysmon. I loved the fact that by linking security events to techniques, we could also start prioritizing the development of ATT&CK-based analytics.

One of the challenges that I faced with Sysmon was the fact that even though I was able to collect data and categorize events by the specific Sysmon Event IDs, it was hard to know what specific Sysmon rules were triggering every time an event was created. This was necessary to automatically map security events and potential incidents to ATT&CK techniques information. It could also help to understand the volume of specific data being collected per technique. 

Thanks to the recent update to Sysmon (Version 8.0), tagging Sysmon rules is now possible, and makes things much easier to add extra metadata to Sysmon events. 

In this post, I will show you a basic example of Sysmon rule tagging and how you can scale it with the right parser in solutions like HELK. I will share a few initial thoughts on how to utilize these new capabilities. NOTE: While I was testing a few things to write this blog post, @olafhartong published also his first attempt with the new version of Sysmon. I highly recommend checking out his post "Sysmon 8.0, a leap forward in event annotation". It has a similar basic example to start. Great work Olaf!!

Install Sysmon v8.0

The download and install process is very straight forward. One thing to remember is that with Sysmon version 8.0 the configuration schema version is now 4.1. I updated my basic Sysmon Config that I usually use to start logging events and creating a baseline of my lab environment. Feel free to download it and use it to start.

Figure 1: Part of initial Sysmon Configuration

Figure 2. Install Sysmon with specific configuration

So, What Is New?

In order to know right away about the new metadata added to the events, I decided to start a process and check the event schema. I launched Calculator.exe as shown in the image below. As you can see, there is a new data field named "RuleName". It is blank because I did not tag a Sysmon rule to include events generated or related to Calculator.exe.

Figure 3. Open Calculator and check the event log

Another great way to gather information about the Sysmon schema was posted by @olafhartong and can be found here. I like that approach because it will help me a lot to update all the Sysmon dictionaries I put together for Sysmon data in OSSEM right away. However, there is always extra metadata generated by the system that still needs to be parsed and is not in the Sysmon Schema. I copied the XML details of the event log generated for Calculator.exe so that you can see what to expect. I have already taken care of that for you with HELK.

Ok, How Do I Tag Sysmon Rules?

If you go to the Sysmon site and go to the "Event Filtering Entries" part, you will find the following details: 

"To have Sysmon report which rule match resulted in an event being logged, add names to rules: <NetworkConnect onmatch="exclude"> <Image name="network iexplore" condition="contains">iexplore.exe</Image> </NetworkConnect>"

So if I want to add a name to a rule that collects/include events generated by a process that ends with Calculator.exe, I can update my Sysmon config to the following:

Once I update the config, I have to also push an update to my Sysmon service

Figure 4. Update Sysmon Config with new rule name.

If I open the calculator app again, I should be able to see the RuleName field populated with the Calculator Rule tag in it:

Figure 5. Sysmon Calculator rule name.

MITRE ATT&CK Integration

One very good initial use case that I explained at the beginning of this post was  the automation of mapping security events and potential incidents from a Sysmon rule perspective to ATT&CK techniques information such as Tactic, Technique Name, Technique ID, Platform, etc. Following our initial basic calculator example, we can start tagging Sysmon rules that could relate to specific procedures defined in techniques used by adversaries.

Do I Just Pick Any Technique?

I usually recommend prioritizing what you can potentially see currently in your environment over just picking any technique in the matrix. For example, if you have Sysmon running in your environment and you are collecting "ProcessCreate" events, then you can prioritize techniques that require to have "Process Monitoring" or "Process command-line parameters" as data sources. Let's say we pick "Create Account - T1136". 

Figure 6. Create Account Technique Information

ATT&CK Simulation Repos Help!

One thing that I love about the industry is that there are 'Red Team Simulation" projects that allow you to learn and test different variations of a specific technique.  My favorite projects out there that provide great information are Endgame's Red Team Automation (RTA) and RedCanary's Atomic Red Team (ART). I usually use the GitHub search bar on the repositories and look for a few initial commands or steps defined by ATT&CK in the techniques description information. For ART, you can also just go to the technique ID folder and learn more about it.

Figure 7. Endgame RTA

Figure 8. RedCanary ART

Add Sysmon Rule & Name

If your Sysmon config is already allowing you to capture events generated by the execution of net.exe due to the fact that you use your config to exclude instead of include events, you will have to change that in order to tag a specific Sysmon rule that could map directly to T1136. I updated mine to the following:

Why Don't You Add The Net.exe Condition to the Rule Name?

Great question! I recently parsed the whole ATT&CK database and made it part of a HELK Dashboard by default. If I look for net.exe by itself without any command arguments across the whole ATT&CK database, I find that there are around 13 techniques where net.exe is mentioned. That will be a lot of tags. This is why I recommend to be a little bit more specific if you want to start tagging and mapping Sysmon rule names to ATT&CK techniques .

Figure 9. net.exe across the whole ATT&CK database

Simulate The Technique

Run a few basic commands and check the results

net user /add wardog

Figure 9. Create Account simulation via net1.exe

Something interesting to mention after doing this exercise is that when the event that triggers a rule has other data fields without a rule name, it automatically excludes the RuleName tag value from the event. For example, the net.exe condition by itself does not have a rule name; However, CommandLine: user /add does. If net.exe is executed with user /add command-arguments, the event is shown with an empty RuleName. Only net1.exe shows with a rule name or tag. Keep that in mind when you start tagging rule names.

Figure 10. Create Account simulation via net.exe

Nice! Now, How Do I Parse the RuleName?

All those basic use cases make sense, but it is important to also cover how you could start using the flexibility of tagging Sysmon rules in your production environment. For the collection piece, you could use a WEF server and a Winlogbeat agent on the top to push data to a data lake or straight to your SIEM. I use KAFKA brokers to centralize the collection of several data sources and then an ELK stack to extract, transform, load, analyze and visualize the data.

One thing that I am sure you have noticed is that when we add several tags to one Sysmon rule, it separates the key=value by commas, so you will have to parse all that. If you are using an ELK Stack as your SIEM, you could use the Logstash KV filter plugin to parse the RuleName field values

Logstash KV Filter Config

According to Logstash documentation, the KV filter pluting helps automatically parse messages (or specific event fields) which are of the foo=bar variety.

• source => The field to perform key=value searching on
• field_split => A string of characters to use as single-character field delimiters for parsing out key-value pairs.
• value_split => A non-empty string of characters to use as single-character value delimiters for parsing out key-value pairs.
• prefix => A string to prepend to all of the extracted keys.
• transform_key => Transform keys to lower case, upper case or capitals.

filter {
  if [log_name] == "Microsoft-Windows-Sysmon/Operational"{
    if [event_data][RuleName] {
      kv {
        source => "[event_data][RuleName]"
        field_split => ","
        value_split => "="
        prefix => "mitre_"
        transform_key => "lowercase"
      }
    }  
  }
}

Re-Simulate & Watch

Once, you have that filter in your Logstash pipeline, you will be able to transform/parse the RuleName field values of every endpoint that produces the data triggered by the Sysmon rule.

Figure 10. Event ID 1 - Sysmon Rule Tag

Figure 11. Event ID 1 - Sysmon Rule Tag metadata

That's it! I just wanted to share a little bit of my initial thoughts about utilizing the Sysmon rule tagging capabilities to start categorizing some of the data that you might be collecting via Sysmon. Even though this seems to be pretty straight forward, it is important to remember that some Sysmon rules might fall into the "Signature" vs "Situational Awareness" type of analytic. You can just add another tag named "analytic" and set it to Signature or Situational Awareness depending on your environment. Also, take in consideration that several techniques get repeated across several tactics when you tag Sysmon rules. I will be sharing more soon.