If you are reading this blog post via a 3rd party source it is very likely that many parts of it will not render correctly. Please view the post on signalscorps.com for the full interactive viewing experience.
In this post I will show you how to use Sigmac to automatically transform your Sigma Rules into other target query languages.
Manually converting Sigma Rules into other query languages is a pain, requiring you to be an expert in all the other query languages for which you want to disseminate the rule (and this can be a long list).
You probably have numerous security tools in own your stack, each with different rule formats and languages, before considering those of your peers at other companies.
One of the founding ideas of the Sigma project was to create a generic rule format that could be automatically translated to other target formats to solve this problem.
Sigmac, a tool shipped in the core Sigma repository can do this.
I should point out Sigmac will soon be deprecated in favour of pySigma, but for now Sigmac is still the most fully featured option of the two to convert Sigma rules into other target query languages.
To download and install the Sigma repository (which includes Sigmac):
git clone https://github.com/SigmaHQ/sigma
cd sigma
python3 -m venv tutorial_env
source tutorial_env/bin/activate
pipenv install
cd tools
python3 sigmac -h
This will print a lot of arguments available to use with Sigmac.
Lets go through some of the common ones.
In order to view all available Backends (Targets), Configurations (Sources), and Modifiers, you can use the –lists argument;
python3 sigmac --lists
Jumping back a bit, let me explain these three concepts.
Backends (aka Targets) are the target format for your rule. It can be specified using the --target (-t) flag. For example --target splunk for Splunk, --target ala for Microsoft Sentinel, --target chronicle for YARA-L (used by Google Chronicle), etc. You can see a list of all the supported backends here.
The Configurations (aka Sources) defines the configuration file that contains logsources and field mappings for the target backends. The mappings are configured in a YAML file – you can see the currently available configurations here. A target backend can support more than one configuration.
Take Splunk as an example, if I try an convert a Sigma Rule using Sigmac like so;
python3 sigmac --target splunk ../rules/windows/builtin/application/win_av_relevant_match.yml
You will see the message;
The backend you want to use usually requires a configuration to generate valid results. Please provide one with --config/-c.
Followed by a list of supported configurations.
The supported backends are defined in the configuration file. For example the Splunk Windows configuration file supports 3 backend options;
backends:
- splunk
- splunkxml
- splunkdm
Remember I talked about Splunk sourcetypes in the last post? The configuration file is responsible for translating the Sigma field names into the field name used by the appropriate Splunk sourcetype.
You can see the field mappings defined in the configuration file in the format;
fieldmappings:
sigma_fieldname_1: target_fieldname
Using the Splunk Windows configuration file as an example again you will see;
fieldmappings:
EventID: EventCode
This is saying where the EventID field name is used in a Sigma Rule, convert it to EventCode for the target format field name when this configuration file is used.
Here is an example using the rule AD Object WriteDAC Access.
Note, the following fields are used in the Search Identifier named selection; EventID, ObjectServer, AccessMask and ObjectType
python3 sigmac --target splunk --config splunk-windows ../rules/windows/builtin/security/win_ad_object_writedac_access.yml
Which outputs the following Splunk search;
(source="WinEventLog:Security" EventCode="4662" ObjectServer="DS" AccessMask="0x40000" (ObjectType="19195a5b-6da0-11d0-afd3-00c04fd930c9" OR ObjectType="domainDNS"))
This time, not how all the fields have the same name as used in the Sigma version of the rule, except for EventID which has been renamed EventCode, as per the splunk-windows configuration file.
The configuration file also contains logsources definitions. These contain at least one category, product or service element that corresponds to the same fields in the logsource part of sigma rules.
Here is a snippet of the logsources definition in the the Splunk Windows configuration file;
logsources:
windows-application:
product: windows
service: application
conditions:
source: 'WinEventLog:Application'
The logsources section also contains a conditions part can be used to define field:value condition. In the example above, it is saying for rules where product: windows and service: application then the Splunk source field equals WinEventLog:Application.
Let me demonstrate with a sample rule (win_av_relevant_match.yml). You can see the logsource section of the rule contains product: windows and service: application which map directly to the snippet shown above from the Splunk Windows configuration file.
logsource:
product: windows
service: application
Now if I try the last command again, but this time passing the --config or -c flag using the Windows configuration file;
python3 sigmac --target splunk --config splunk-windows ../rules/windows/builtin/application/win_av_relevant_match.yml
It converts the inputted Sigma Rule into a valid Splunk search;
(source="WinEventLog:Application" ("HTool-" OR "Hacktool" OR "ASP/Backdoor" OR "JSP/Backdoor" OR "PHP/Backdoor" OR "Backdoor.ASP" OR "Backdoor.JSP" OR "Backdoor.PHP" OR "Webshell" OR "Portscan" OR "Mimikatz" OR ".WinCred." OR "PlugX" OR "Korplug" OR "Pwdump" OR "Chopper" OR "WmiExec" OR "Xscan" OR "Clearlog" OR "ASPXSpy" OR "Ransom" OR "Filecoder" OR "CobaltStr" OR "PWCrack" OR "DumpCreds" OR "MPreter" OR "Koadic" OR "Packed.Generic.347" OR "COBEACON" OR "Cometer" OR "Keylogger" OR "MeteTool") NOT (("Keygen" OR "Crack" OR "anti_ransomware_service.exe" OR "cyber-protect-service.exe") OR (Level="4")))
You’ll see the source="WinEventLog:Application" is added to the search (as per the condition definition in the configuration file), in addition to the converting the Sigma Rule into SPL.
If the logsource section of the Rule does not map to a logsources defined in the configuration file, the rule will still convert, but will not pickup any of the correct conditions.
As an example using the same rule, but this time using another configuration file supported by the Splunk backend (powershell);
python3 sigmac --target splunk --config powershell ../rules/windows/builtin/application/win_av_relevant_match.yml
Returns;
(("HTool-" OR "Hacktool" OR "ASP/Backdoor" OR "JSP/Backdoor" OR "PHP/Backdoor" OR "Backdoor.ASP" OR "Backdoor.JSP" OR "Backdoor.PHP" OR "Webshell" OR "Portscan" OR "Mimikatz" OR ".WinCred." OR "PlugX" OR "Korplug" OR "Pwdump" OR "Chopper" OR "WmiExec" OR "Xscan" OR "Clearlog" OR "ASPXSpy" OR "Ransom" OR "Filecoder" OR "CobaltStr" OR "PWCrack" OR "DumpCreds" OR "MPreter" OR "Koadic" OR "Packed.Generic.347" OR "COBEACON" OR "Cometer" OR "Keylogger" OR "MeteTool") NOT (("Keygen" OR "Crack" OR "anti_ransomware_service.exe" OR "cyber-protect-service.exe") OR (Level="4")))
This time note the omission of source="WinEventLog:Application".
Looking at the Powershell configuration file you can see why – the logsource section of the rule contains product: windows and service: application but the logsources defined in the configuration file does not contain this definition.
I could also create my own custom configuration file for the backend.
For example custom-backend.yml;
title: My custom backend
order: 20
backends:
- splunk
logsources:
windows-application:
product: windows
service: application
conditions:
sourcetype: 'windows'
fieldmappings:
EventID: EventCode
Using this backend;
python3 sigmac --target splunk --config custom-backend ../rules/windows/builtin/application/win_av_relevant_match.yml
Produces a Splunk search;
(sourcetype="Windows" ("HTool-" OR "Hacktool" OR "ASP/Backdoor" OR "JSP/Backdoor" OR "PHP/Backdoor" OR "Backdoor.ASP" OR "Backdoor.JSP" OR "Backdoor.PHP" OR "Webshell" OR "Portscan" OR "Mimikatz" OR ".WinCred." OR "PlugX" OR "Korplug" OR "Pwdump" OR "Chopper" OR "WmiExec" OR "Xscan" OR "Clearlog" OR "ASPXSpy" OR "Ransom" OR "Filecoder" OR "CobaltStr" OR "PWCrack" OR "DumpCreds" OR "MPreter" OR "Koadic" OR "Packed.Generic.347" OR "COBEACON" OR "Cometer" OR "Keylogger" OR "MeteTool") NOT (("Keygen" OR "Crack" OR "anti_ransomware_service.exe" OR "cyber-protect-service.exe") OR (Level="4")))
Not all backends require a configuration file. For example, using Microsoft Sentinel with the rule proc_creation_win_abusing_debug_privilege.yml without a configuration file specified;
python3 sigmac --target ala ../rules/windows/process_creation/proc_creation_win_abusing_debug_privilege.yml
Returns a valid Kusto query;
SysmonEvent | where (((ParentImage endswith @'\\\\winlogon.exe' or ParentImage endswith @'\\\\services.exe' or ParentImage endswith @'\\\\lsass.exe' or ParentImage endswith @'\\\\csrss.exe' or ParentImage endswith @'\\\\smss.exe' or ParentImage endswith @'\\\\wininit.exe' or ParentImage endswith @'\\\\spoolsv.exe' or ParentImage endswith @'\\\\searchindexer.exe') and (Image endswith @'\\\\powershell.exe' or Image endswith @'\\\\cmd.exe') and (User contains 'AUTHORI' or User contains 'AUTORI')) and not (CommandLine contains ' route ' and CommandLine contains ' ADD '))
However, not supplying a configuration file can cause issues. Using the rule win_av_relevant_match.yml again, but this time with the Sentinel backend and no configuration file;
python3 sigmac --target ala ../rules/windows/builtin/application/win_av_relevant_match.yml
Returns;
Error: The Sigma rule requires a feature that is not supported by the target system: No table could be determined from Sigma rule
Essentially Sigmac is unsure how to convert some of the Sigma rules logsource and/or detection, and/or condition values set. A configuration file could be built to show Sigmac how to perform the conversion correctly.
Finally, I can export my created rule to a file using Sigmac for dissemination.
Here is an example, exporting a Sentinel Rule in YAML format (--output-format) called SENTINEL_proc_creation_win_abusing_debug_privilege.yml (--output).
python3 sigmac --target ala ../rules/windows/process_creation/proc_creation_win_abusing_debug_privilege.yml --output SENTINEL_proc_creation_win_abusing_debug_privilege.yml --output-format yaml
And here is the resulting file.
Introducing pySigma
At the start of this post I mentioned Sigmac is being deprecated in favour of pySigma.
In the final part of this tutorial I will show you how pySigma works to parse and convert Sigma rules into other query languages automatically.
Sigma Certification (Virtual and In Person)
The content used in this post is a small subset of our full training material used in our Sigma training.
If you want to join a select group of certified Sigma professionals, subscribe to our newsletter below to be notified of new course dates.
Discuss this post
Never miss an update
Sign up to receive new articles in your inbox as they published.