Comment on page
Creating "Detections" Using BluSapphire Portal
Assuming analysts might be interested in tracking installation of malicious windows services on a compromised workstation to achieve persistence or to move laterally between systems later on. Most common red team techniques involve installing a new service that would allow adversaries to run commands on remote machines or creating a new account upon execution of malicious service.
Here analysts would be more interested to look for Windows Event-ID: “7045 - Windows Service Installation”, which holds the details about the binary (ServiceFileName) that the service is using.
To detect malicious service installations on windows workstation, you know what and where to look for. The Sigma rule for this would be as follows:
Let’s break it down further to understand Sigma rule structure and attributes within, A Sigma rule has different attributes, each of which has a unique purpose. In the structure table below, sigma rule has been grouped into three sections “Metadata, Logsource, Detections” for understanding purposes.
Note: Additional information related to field attributes and their properties are available in Annexure-A.
- Metadata: This section has fields that are common across all Sigma rules of a collection.
- Logsource: This section describes the log data on which the detection is meant to be applied. It consists of three sub-attributes which define the details of the log source:
- Category – e.g.: Firewall, Web, Antivirus, Process_Creation
- Product – e.g.: Windows, Apache
- Service – e.g.: System, AppLocker, Security, Sysmon
- Definition – e.g.: Information that describes the log source
Note: Instead of referring to a particular service using the mentioned sub-attributes, a generic log sources can be used in the rule, which has category and product information.
- Detection (Detection-Expression): Defines a set of search-identifiers that represent ‘what an analyst would want to search for’ on the given log data source. This section is made up of the following sub-attributes “Search-Identifier and Condition-Expression”.
- Search-Identifier is at the core for detection, supports both “lists and maps” type data structures.
- Lists – Can have multiple items or strings, each of which are linked with a logical ‘OR’ as below.
- Maps (dictionaries) – Are key/value pairs, in which the key is a field in the log data and value can be string or integer. All the elements of map are linked with a logical ‘AND’ as below.
- Value Modifiers can be used to modify values in a rule, Value Modifiers can change search identifier behavior and are attached to the end of a field name after the pipe “|” character.
- Condition (Condition-Expression) – Uses operators to link ties Search-Identifier fields together, defining how the detection tool will process each field in relation to the others.
The following are some basic rules to be followed while writing a sigma rule:
- Follows YAML format, use spaces (not tabs).
- All values are case-insensitive strings
- You can make use of wildcard characters '*' and '?' in strings
- Wildcards can be escaped with '\' e.g., '\*'
- Special Field Values:
- Null values are defined with 'null'
- Empty value is defined with '’
This section provides information on creation/modification and deployment of new/existing sigma rules from within Blusapphire Portal.
Steps for Rule creation:
- 1.From Blusapphire portal, navigate to “Rule Management" page available under “Entity Behavior” menu item.
- 1.To create a new rule, click on “New” button available on top right side. As described earlier in this document:
- 1.Provide an appropriate rule name
- 1.Provide the required metadata fields
- 1.Provide required Logsource as per specifications.
- 2.Define the search-identifiers (selection/filters) for the rule and the condition.
- 1.Finally check, validate and save the new rule.
- 1.Newly created rules will be enabled by default.
- 1.To update an existing rule:
- Use filters to search for an existing rule
- Make the required changes in the rule, validate and save.