AoC 2022 Day 18: Sigma Rules

Threat Detection

Cyber threats and criminals utilize cutting-edge strategies to steal information and wreak havoc. There are numerous ways to accomplish this, as you have already seen throughout the previous days. Security teams can prepare their defenses and recognize these threats in a number of ways. It would be clear that the majority of blue-team tasks would call for proactive methods of analyzing various logs, malware, and network traffic. The practice of threat detection stems from this.

Threat detection involves proactively pursuing and analysing abnormal activity within an ecosystem to identify malicious signs of compromise or intrusion within a network.

• Run – Submit your Sigma rule and see if it detects the malicious IOC.
• Text Editor – Write your Sigma rule in this section.
• Create Rule – Create a Sigma rule for the malicious IOC.
• View Log – View the log details associated with the malicious IOC.

Sigma Rules

To describe log events in a structured fashion, Florian Roth & Thomas Patzke created Sigma, an open-source generic signature language. Security experts can quickly share their detection methods using the format, which makes use of the markup language YAML. The common factors to note about YAML files include the following:

• YAML is case-sensitive.
• Files should have the .yml extension.
• Spaces are used for indentation and not tabs.
• Comments are attributed using the # character.
• Key-value pairs are denoted using the colon : character.
• Array elements are denoted using the dash - character.

Sigma makes it easy to perform content matching based on collected logs to raise threat alerts for analysts to investigate. Log files are usually collected and stored in a database or a Security Information and Event Management (SIEM) solution for further analysis. Sigma is vendor-agnostic; therefore, the rules can be converted to a format that fits the target SIEM.

Sigma was developed to satisfy the following scenarios:

• To make detection methods and signatures shareable alongside IOCs and Yara rules.
• To write SIEM searches that avoid vendor lock-in.
• To share signatures with threat intelligence communities.
• To write custom detection rules for malicious behaviour based on specific conditions.

Sigma Rule Syntax

Sigma rules are guided by a given order of required/optional fields and values that create the structure for mapping needed queries. The attached image provides a skeletal view of a Sigma rule.

Let’s use the first attack step challenge to define the syntax requirements, fill in the details into our skeletal rule, and detect the creation of local accounts. Use the text editor section of the SigHunt application to follow along.

• Title: Names the rule based on what it is supposed to detect.
• ID: A globally unique identifier that the developers of Sigma mainly use to maintain the order of identification for the rules submitted to the public repository, found in UUID format.
• Status: Describes the stage in which the rule maturity is at while in use. There are five declared statuses that you can use:
  • Stable: The rule may be used in production environments and dashboards.
  • Test: Trials are being done to the rule and could require fine-tuning.
  • Experimental: The rule is very generic and is being tested. It could lead to false results, be noisy, and identify exciting events.
  • Deprecated: The rule has been replaced and would no longer yield accurate results.
  • Unsupported: The rule is not usable in its current state (unique correlation log, homemade fields).

• Description: Provides more context about the rule and its intended purpose. Here, you can be as detailed as possible to provide information about the detected activity.

• Logsource: Describes the log data to be used for the detection. It consists of other optional attributes:
  • Product: Selects all log outputs of a certain product. Examples are Windows, Apache
  • Category: Selects the log files written by the selected product. Examples are firewalls, web, and antivirus.
  • Service: Selects only a subset of the logs. Examples are sshd on Linux or Security on Windows.
  • Definition: Describes the log source and its applied configurations.

• Detection:  A required field in the detection rule describes the parameters of the malicious activity we need an alert for. The parameters are divided into two main parts: 
  • The search identifiers are the fields and values the detection should search for.
  • The condition expression – sets the action to be taken on the detection, such as selection or filtering. The critical thing to look out for account creation on Windows is the Event ID associated with user accounts. In this case, Event ID: 4720 was provided for us on the IOC list, which will be our search identifier.

• False positives: A list of known false positives that may occur based on log data.
• Level: Describes the severity with which the security team should take the activity under the written rule. The attribute comprises five levels: Informational -> Low -> Medium -> High -> Critical
• Tags: Adds information that can be used to categorise the rule. Common tags are associated with tactics and techniques from the MITRE ATT&CK framework. Sigma developers have defined a list of predefined tags.