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:
Sigma Rule - Installation of Malicious Service
title: Installation of Malicious Service
author: Blusapphire, SOC
description: Detects known malicious service installs that only appear in cases of lateral movement, credential dumping, and other suspicious activities.
- Penetration testing
ServiceFileName|contains: 'net user'
condition: selection and ( malsvc_paexec or malsvc_wannacry or malsvc_persistence)
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.
Installation of Malicious Service
Detects known malicious service installs that only appear in cases of lateral movement, credential dumping, and other suspicious activities.
- Penetration testing
ServiceFileName|contains: 'net user'
selection and (malsvc_paexec or malsvc_wannacry or malsvc_persistence)
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
definition: 'Script block logging must be enabled'
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.
Generic Logsource Example
- 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.
(EventID:”4624” OR EventID:”4625”)
(EventID:”1” AND Image:”*.powershell.exe”)
- 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.
What changes, when value modifiers are used
Adds ‘*’ to beginning & end of the field value
Chages the default list behavior from ‘or’ to ‘and’
Adds ‘*’ to the end of the field value
Adds ‘*’ to the beginning of the field value
- 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.
selection1 or selection2
1/all of search-identifier
1 of selection
1/all of them
all of them
1/all of search-id-pattern
all of filter_*
Negation with ‘not’
Selection and not filter
Order of operation ‘()’
1 of selection and not (filter1 or filter2)
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.
Provide a brief title for the rule, keep it simple and short
Global unique identifier for rule, auto generated during rule creation and used internally (optional)
Defines the maturity of the rule. (optional)
Author of the rule (special should be inside single quotes), Comma is used to separate multiple users. (optional)
Creation date of the rule. (optional)
Modified date of the rule. (optional)
Short description of the rule and its context of detection. (optional)
List of references to external sources for the rule
Tag the rule based on the context of logsource or log data or even detection.
Field allows lowercase, underscores hyphens and no-spaces.
E.g., For windows rule you may tag it with Mitre Framework based on Technique like attack.t1086
Field defines the criticality of the rule.
Defines the log data source which will be used to search data from. Logsource has additional sub-attributes 'Category, Product, Service, Definition' for pointing to a specific log source.
Instead of Logsource, you can use Generic Logsource format which only has two sub-attributes ‘Category, Product’. This is used internally during the conversion process, specifically for field mapping.
Defines a set of search-identifiers that represent searches on log data, support both lists, maps(dictionaries) data-structures.