Sigma (grindset?) Rules - find suspicious events with Sigma

In previous post we looked at the creation and functionality of YARA rules which are an invaluable aid to analysts in detecting and classifying files. However, some might say that today is not enough. After all, living off the land attacks are becoming more and more popular, where attackers do not use additional software, but are satisfied with the tools already present in the system. So how do we create detections and catalog activity indicators if we want to focus on behaviors, not files? This is where they will help us Sigma ruleswhich, in a way, are YARA rules for files for system event logs. With their help, we will be able to describe events, share detections and implement our ideas for detecting malicious activity by translating Sigma rules into the syntax of systems such as Splunk or Elastic.

The rules use the YAML format and their structure will be more complex than that used in YARA, we will not waste time looking at how Sigma works. The skeleton of the rule according to the official specification is as follows:

As we can see, there is quite a lot of it, which results from the multitude of potential log sources, and therefore the need to take into account the fields that will allow us to precisely define what and where we are looking for. Now let's get acquainted with each of the available functions and how we can use them.

The first part is for specifying the name of the rule and adding information to help you understand the context and operation of the detection. This section is similar to the "meta" part of the YARA rules. Apart from the name, the fields are not obligatory, but it is definitely worth adding them to facilitate the use of our work. Briefly zooming in on the fields in this section:

1. Title - the obligatory name of our rule.
2. id - we can put a unique UUID here that will allow for unambiguous identification of the detection.
3. related - in this subsection we can indicate references to other rules, e.g. previous versions of the current rule.
4. status - here we put information about the status, such as whether the rule is in the testing phase or is ready for production.
5. description - description of the functionality and application of our work.
6. author - information about the author and contact details.
7. references - and finally we can put the sources we used to create the rule.

The next section will be the core of detection. In the logsource, we will define the type of logs to which our rule should be applied. We have three main fields here:

1. category - type of device logs we use as firewall or anti-virus.
2. product - as the name suggests, we define a specific product here, such as Windows or Apache.
3. service - and finally we can mark the categories of logs from a given product, e.g. in the case of Windows we can narrow down the logs to events from the Security log.

Additionally, to narrow down the data sources, we can use the Definition field. It is not automatically converted into instructions for e.g. Splunk, but it can make it easier for analysts to properly configure data sources.

Next, we put the Detection section in which we will specify what we want to find in the logs and when our rule should trigger an alert. Two variables will play a key role here:

1. selection - in which we will put the definitions of what we want to find, such as: file names and paths, commands in the terminal.
2. condition - as in YARA, conditions to be met for the rule to react, e.g. one of the two conditions specified by the selection fields.

Selection is the part in which we have the greatest scope to show off and this is where we will define variables, event IDs and other values that can help in detecting malicious activity. In addition to the usual "text" search, we can use lists and dictionaries, as well as content search modifiers. Let's look at examples from the Sigma documentation itself:

Here we can see the simplest example, when we indicate text strings to be detected, in this format there is an OR operator between them, so it is enough to detect one to trigger the detection.

Now we are using the dictionary, in order to trigger the detection, log Security must occur with the event ID 517 or 1102.

In the case of file names or specific events, this syntax may be sufficient for us. However, if we want to search for commands in the terminal or files in specific paths, modifiers that Sigma takes into account will be very useful. We add them after the symbol "|" and thus change the scope of the search. For example, if we want to search for a string that appears anywhere in a command executed in the terminal, we use the "contains" modifier, which wraps the given data with "*" symbols, i.e. any string of characters can appear after and before. In practice, it looks like this:

So we chose the log category here - process creation, and the product - Windows. Our search string here is "oursecretstring", which the rule will look for in the command line - according to the modifier, no matter where it occurs. In the end, as a condition, we simply indicated selection, i.e. here the occurrence of our selected text in a specific log. As for other modifiers, it is also worth mentioning:

• all - changes the condition in lists from OR to AND, which means that all given values must be found.
• startwith / endswith - similar to contains specifies where the given data appears. So we can ignore it after (startwith) or before (endswith) the given value.
• base64 - base64 encode values.

The condition field works in Sigma similarly to the YARA rules. So we can both indicate criteria directly, such as: "selection_1 AND selection_2" and use the expressions "all of them", "2 of them", "any of selection_ *" and similar.

Finally, let's look at two more optional but noteworthy fields.

In "falsepositives" we can indicate to users of our rules what to pay attention to in order to screen out similar but harmless activity. Especially when trying to detect the use of living off the land techniques, helping to distinguish administrative activity from malicious activity.

Finally, "level" allows us to define the priority of an alert resulting from finding indicators specified in the rule. Sigma assumes five levels here:

• informational - for rules used to mark events rather than search for threats.
• low - events that may indicate malicious activity in a specific context, such as a large number of such events.
• medium - significant events that should be regularly checked by analysts.
• high - Malicious activity events that should trigger an alert and be immediately checked.
• critical - particularly dangerous behavior that should trigger an immediate reaction.

By combining falsepositives and level, we can definitely facilitate the work of analysts. Even the best detection is difficult to apply if we have to regularly confront false positive alerts and it is difficult to assess the significance of the find. When creating detection, we should not only think about technical details, but also about the implementation of rules in the working conditions of the SOC team and incident response.

So let's collect all this information and try to create a specific rule that will detect the creation of processes with the names used by the activity groups of interest to us, along with the password given as an argument (which we know from the irreplaceable threat intelligence team 🙂).

If we now want to convert our Sigma rule to the query format in the log handling system we use, such as: Splunk, we can use sigmac tools be online converter. Let's look at the result of using the latter:

This is how we learned the basics of creating Sigma rules and we can start looking for events that interest us in the logs that we have at our disposal.