SIGMAlarity jump. How to use Sigma rules in 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.

Sigma

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.

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

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.

Cloning the project:

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.

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

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.

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

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:

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.

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.

$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.

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.

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.

Conclusions

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!