Sigma is an open standard for rules that allow you to describe searches on log data in generic form. These rules can be converted and applied to many log management or SIEM systems and can even be used with grep on the command line.

In this article I’d like to give you a brief practical introduction into the rule creation process. I’ll recommend some tools and draft a guide that helps you to write Sigma rules as quick and sound as possible.

1. Get the Repository

First download or clone our Sigma repository from Github.

It contains the rule base in the folder “./rules” and the Sigma rule compiler “./tools/sigmac”. We will use the existing rules as examples and create a new rule based on a similar existing one. We will then test that rule by using “sigmac”.

2. Copy and Edit YAML Files

My personal favorite editor for YAML is VSCode. It is free and runs on all major platforms. (alternatively you can use Atom with ‘language-yaml’ and ‘linter-js-yaml’ packages)

I used the following extensions but I don’t know if they are still necessary. VSCode has improved a lot over the last 12 months and it is possible that it supports YAML highlighting and syntax checks by default now.

We open the Sigma repository folder with “Open …” and see all existing rules.

3. Create a Sigma Rule

I selected an example in which we will create a Sigma rule from one of @JPCERT‘s findings in their awesome “Tool Analysis Result Sheet“.

We open the results for “Quarks PWDump“, a password dumper often used by Chinese threat groups. It creates temporary files that we want to detect in our SysInternals Sysmon log data. To collect the needed events we use Sysmon with @SwiftOnSecurity‘s Sysmon config file, Windows Event Forwarding or NXlog.

So, what we do is to find a Sigma rule in the repository that we can use as a template for our new rule. We use the ‘search’ function to find a rule that looks for “File Creation” events (EventID 11) in Sysmon log data.

We find a rule that has a special format. It is a so-called “rule-collection“, which allows us to define a global section in the YAML file marked with “action: global” that will be applied to all other sections in that file during the search query generation process. This way you can define and create multiple search queries from a single YAML file.

In the case of our QuarksPwDump example we don’t need a rule collection, so we reduce the rule to a standard rule that contains a detection expression looking Sysmon Events with Event ID 11 and save it as “sysmon_quarkspw_filedump.yml” to a new file in the folder “./rules/windows/sysmon/”.

After that, we modify several fields of that rule:

• We give the rule a correct “title” and “description”
• We leave the status “experimental” to inform everyone that this is a new and untested rule
• We add the correct reference to the source from which we derived that rule
• We change the author of the rule
• We set the level of that rule to one of “low”, “medium”, “high” or “critical”
• We adjust the date (of last modification) and use the format %Y/%m%d (strftime)
• We check if the log source is correct, which is important for the field mappings used by “sigmac”

Before we create the new “detection” section, we review the analysis report in detail.

We add a string with wildcards that matches on the ‘TargetFileName’ field in the Sysmon events of type 11. That’s what the new rule looks like:

4. Test the Rules

We test our newly created rule with “sigmac”, which requires python3. It is located in the “./tools” folder. It features several targets for which we can create searches/configurations from our rules.

Currently supported targets (10.02.2018):

• es-qs (Elastic Search Query Language)
• kibana
• xpack-watcher
• logpoint
• splunk
• grep
• fieldlist (only used to show all fields that require mapping in a config file)

Running “python3 sigmac -h” shows a help:

$ python3 sigmac -h
usage: sigmac [-h] [--recurse] [--filter FILTER]
[--target {es-qs,kibana,xpack-watcher,logpoint,splunk,grep,fieldlist}]
[--target-list] [--config CONFIG] [--output OUTPUT]
[--backend-option BACKEND_OPTION] [--defer-abort]
[--ignore-not-implemented] [--verbose] [--debug]
[inputs [inputs ...]]

Convert Sigma rules into SIEM signatures.

positional arguments:
inputs Sigma input files

optional arguments:
-h, --help show this help message and exit
--recurse, -r Recurse into subdirectories (not yet implemented)
--filter FILTER, -f FILTER
Define comma-separated filters that must match (AND-
linked) to rule to be processed. Valid filters:
level<=x, level>=x, level=x, status=y, logsource=z. x
is one of: low, medium, high, critical. y is one of:
experimental, testing, stable. z is a word appearing
in an arbitrary log source attribute. Multiple log
source specifications are AND linked.
--target {es-qs,kibana,xpack-watcher,logpoint,splunk,grep,fieldlist}, -t {es-qs,kibana,xpack-watcher,logpoint,splunk,grep,fieldlist}
Output target format
--target-list, -l List available output target formats
--config CONFIG, -c CONFIG
Configuration with field name and index mapping for
target environment (not yet implemented)
--output OUTPUT, -o OUTPUT
Output file or filename prefix if multiple files are
generated (not yet implemented)
--backend-option BACKEND_OPTION, -O BACKEND_OPTION
Options and switches that are passed to the backend
--defer-abort, -d Don't abort on parse or conversion errors, proceed
with next rule. The exit code from the last error is
returned
--ignore-not-implemented, -I
Only return error codes for parse errors and ignore
errors for rules with not implemented features
--verbose, -v Be verbose
--debug, -D Debugging output

We test our new rule with “sigmac” and the target “splunk”.

$ python3 sigmac -t splunk ../rules/windows/sysmon/sysmon_quarkspw_filedump.yml
(EventID="11" TargetFileName="*\AppData\Local\Temp\SAM-*.dmp*")

Now the rule is ready for a pull request. Follow me or contact me on Twitter: @cyb3rops