SIGMAlarity jump. How to use Sigma rules in Timesketch

Information security specialists use multiple tools to detect and track system events. In 2016, a new utility called Sigma appeared in their arsenal. Its numerous functions will save you time and make your life much easier.


This article uses results received in the two previous articles: Timeline of everything. Collecting system events with Plaso and Cybercrime story. Analyzing Plaso timelines with Timesketch.

In the previous articles, you have learned how to extract various types of events from the image of the computer under investigation and how to generate a timeline. In addition, you have set up a joint analysis system and mastered its basic capabilities. The Timesketch interface allows this program to process not only Plaso files, but any CSV file containing a timeline of events – provides that it includes the key fields critical for Timesketch: datetime, timestamp_desc, and message. This feature makes it possible to add data from different sources to the same timeline.

The more sources of events you use (including those physically inaccessible to Plaso), the more accurately the incident picture will be reconstructed. For instance, you can load into your sketch logs generated by the network firewall, Surricata, a web proxy, event logs from Moloch, or results obtained using third-party utilities (e.g. autorunsc) that can provide plenty of useful information when executed dynamically.

As a result, you can get a pretty dense timeline of an incident with up to 250 thousand events per minute. Ideally, joint analysis of such a timeline requires some 250 thousand employees…

Fortunately, cybersecurity specialists are very lazy people, while laziness, as you know, is the engine of progress. Thanks to it, we have standards and protocols for incident analysis and powerful tools, such as Yara and Snort, developed by the collective mind. Not that long ago, a new project called Sigma was launched. Let’s see how can it help in your investigation.


The project started in 2016, and a year later, the first release appeared on GitHub. The developers position their creation as follows: “Sigma is for log files what Snort is for network traffic and YARA is for files.” It was designed as a universal format describing detection rules based on data extracted from logs. In addition, Sigma can be used as a converter that translates these rules into the format of any supported SIEM system, including generation of queries to Elasticsearch (hereinafter ES). To make this converter work, a respective configuration file is required; this file explains to Sigma how to convert a specific rule for a specific backend. Generally speaking, this is a YAML file that specifies the correspondence between fields used in the rules and real data in the backend.

Thanks to the efforts of numerous enthusiasts, the Sigma repository currently contains some 1200 rules for various situations (which is almost two orders of magnitude more than the number of analyzers present in Timesketch by default). These rules make it possible to detect all sorts of things: use of mimikatz, ProxyShell exploitation in Exchange, traces of the Silence APT group, etc. Most of the rules have references to the respective MITER techniques.

The path to the converter’s config on your virtual machine with Timesketch is /opt/timesketch/etc/timesketch/sigma_config.yaml. This file enables Sigma to work with Timesketch. Let’s take a closer look at it.

$ nano /opt/timesketch/etc/timesketch/sigma_config.yaml

In the backends section, you can see all backends required to use the Sigma rules in Timesketch:

- es-dsl
- es-qs
- es-qr
- es-rule

Then the two largest blocks, logsources andfieldmappings, are located. These blocks map various types of log sources from the backend to specific types of fields used in the rules (see below).

To integrate Sigma into Timesketch, the developers added a new analyzer to the Analyzer tab; recently, they added a tab of the same name that can be used to view and apply each individual rule directly in the web interface.


As you probably remember, in the first article, I said that Sysmon makes the life of admins and forensic specialists much easier. In Sigma, almost two-thirds of rules for Windows are based on Sysmon events. Too bad, not all admins use this powerful tool developed by M. Russinovich. Accordingly, don’t be surprised that in many situations, not all rules ensure the expected detection.

Cloning the project:

$ git clone

Structure of Sigma rules

All rules are stored in the rules folder (the path on your VM is /opt/timesketch/etc/timesketch/sigma/rules); they are described in the YAML file and consist of required and optional sections. For more detail, see the documentation.

I am going to use the rule windows/process_creation/win_susp_whoami_anomaly.yml to explain the purpose of some fields.

title: Whoami Execution Anomaly # Rule name
id: 8de1cbe8-d6f5-496d-8237-5f44a721c7a0 # UUID to identify the rule
status: experimental
description: Detects the execution of whoami with suspicious parents or parameters # Описание в свободной форме
references: # Any references to articles or whitepaper
author: Florian Roth # Author's personal information
date: 2021/08/12 # Creation date
modified: 2021/08/26 # Modification date
- attack.discovery
- attack.t1033
- car.2016-03-001
logsource: # Log source type. The main fields are: product, category, and service
category: process_creation
product: windows
detection: # Signature formation for detection
Image|endswith: '\whoami.exe'
- '\cmd.exe'
- '\powershell.exe'
- 'C:\Program Files\Microsoft Monitoring Agent\Agent\MonitoringHost.exe'
- ''
ParentImage: null
- 'whoami -all'
- 'whoami /all'
- 'whoami.exe -all'
- 'whoami.exe /all'
condition: ( selection and not filter1 and not filter2 and not filter3 ) or selection_special # Resultant signature
falsepositives: # An optional field for situations when false triggering is possible
- Admin activity
- Scripts and administrative tools used in the monitored environment
- Monitoring activity
level: high # Importance level: low, medium, high, or critical

Now let’s examine logsource category: process_creation in the file sigma_config.yaml.

title: Timesketch Sigma config
order: 20
- es-dsl
- es-qs
- es-qr
- es-rule
category: process_creation
product: windows
- 1
- 4688
- "Microsoft-Windows-Sysmon"
- "Microsoft-Windows-Security-Auditing"
- "Microsoft-Windows-Eventlog"
Image: NewProcessName
ParentImage: ParentProcessName

As you can see, the rule uses Sysmon logs and standard Windows logs as data sources (namely eventID 1 or 4688). These data sources were processed by Plaso in the first article and subsequently loaded to ES in this format.

If some rule doesn’t work in Timesketch, make sure that the configuration file includes mapping for all logsources used in it and, if necessary, add your own mapping.


To make sure that your custom-made rules work on other SIEM systems, follow the requirements described in the Sigma Wiki.

Ultimately, the above rule will be applied to the Timesketch backend in the following form:

((data_type:"windows\:evtx\:record" AND event_identifier:("1" OR "4688") AND source_name:("Microsoft\-Windows\-Sysmon" OR "Microsoft\-Windows\-Security\-Auditing" \
OR "Microsoft\-Windows\-Eventlog")) AND ((data_type:"windows\:evtx\:record" AND event_identifier:("1" OR "4688") AND source_name:("Microsoft\-Windows\-Sysmon" \
OR "Microsoft\-Windows\-Security\-Auditing" OR "Microsoft\-Windows\-Eventlog") AND ((xml_string:*\\whoami.exe AND (NOT (ParentImage:(*\\cmd.exe OR *\\powershell.exe)))) \
AND (NOT (ParentImage:("C\:\\Program\ Files\\Microsoft\ Monitoring\ Agent\\Agent\\MonitoringHost.exe" OR "")))) AND (NOT (NOT _exists_:ParentImage))) OR xml_string:(*whoami\ \-all* \
OR *whoami\ \/all* OR *whoami.exe\ \-all* OR *whoami.exe\ \/all*)))

Generally speaking, there is nothing too difficult here. Now let’s get back to your investigation.

Detecting log clean-up attempts

In the previous articles, it was shown that clumsy attempts to clean-up logs don’t make the attacker more stealthy, but quite the opposite, ring alarm bells for the forensic investigator.

Let’s add the following rule to Timesketch:

$ sudo nano /opt/timesketch/etc/timesketch/sigma/rules/win_susp_security_eventlog_cleared.yml
title: Security Eventlog Cleared
id: f2f01843-e7b8-4f95-a35a-d23584476423
description: Some threat groups tend to delete the local 'Security' Eventlog using certain utitlities
- attack.defense_evasion
- attack.t1070
- car.2016-04-002
author: Florian Roth
date: 2017/02/19
product: windows
service: security
- 517
- 1102
condition: selection
- Rollout of log collection agents (the setup routine often includes a reset of the local Eventlog)
- System provisioning (system reset before the golden image creation)
level: high

Save it, switch to the browser, open your sketch, and go to the Sigma tab. As you can see the new rule is already there.

Rule has been added to Sigma
Rule has been added to Sigma

Now go to the Analyze tab and unleash the Sigma analyzer with all its rules on the timeline under investigation. The result will appear in a few seconds.

Analysis results
Analysis results

Voila!Voila! You can see that somebody had tried to clean-up the logs.

When the analyzer finds a suitable document in ES, it updates it by adding a new field, ts_sigma_rule, records in this field the name of the rule that was triggered, and adds the data from the tags section of this rule to the fields tag and ts_ttp. As a result, these fields become available for search and aggregation on the Aggregate tab.

Added fields
Added fields

Now you can use simple queries to find out what interesting information was found, for instance:


No doubt, this relatively small volume of information is much more suitable for analysis than hundreds of thousands of events displayed initially

In addition, you can open each individual rule on the Sigma tab and click the Search button without starting the analyzer. The rule will be automatically inserted into the search box, and you’ll see matching events.

Verifying new rules

Sigma includes a special tool whose purpose is to check whether a new rule (either found on the Internet or created by yourself) would work correctly on a specific system; it’s located in the tools directory and is called sigmac.

$ python3 sigmac -t es-qs --config /opt/timesketch/etc/timesketch/sigma_config.yaml /opt/timesketch/etc/timesketch/sigma/rules/win_susp_security_eventlog_cleared.yml

The backend you use is specified in the t parameter (if you convert a rule for your SIEM system, the respective value will be required), then the converter configuration file is passed, and the last parameter is the rule itself. Furthermore, it’s possible to verify the entire folder with rules at once.

Don’t forget to double-check the rules when the converter’s configuration file undergoes changes or the rules are updated. Measure thrice and cut once.

Further instructions

Too bad, you cannot simply copy all the rules to Timesketch and launch the analyzer. The Sigma engine consumes plenty of resources, and the integration of some rules into Timesketch may cause problems (usually due to the lack of required logsources). Therefore, it is better to review the list of rules and select those that are suitable for a specific case. After checking these rules with sigmac, you can add them to Timesketch. For instance, if Sysmon wasn’t installed on the system under investigation, there is no need to waste time on the respective rules.

Of course, you will need some practical experience to create workable rules.

There are some useful repositories on GitHub where people add records of events that occur during incidents. The easiest way to gain the required experience is to learn how to identify them. So, run Plaso, load the results to Timesketch, and write rules to detect these events. And don’t forget to submit commits to the project! 🙂

In addition, you can use Sigma for its intended purpose by connecting it to your SIEM system.


Hopefully, this article was useful both for security admins and valiant DFIR fighters. Success be to your forensic endeavors, and let the Force be with you! Good luck and see you soon!

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>