Creating "Detections" Using BluSapphire Portal

Note: Please watch this video to follow along as needed.

Sigma Structure & Attributes:

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.

Required Condition	Search for Windows EventID “7045” Look for Windows service binary path’s pointing to suspicious/unwanted executables and alert

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 status: stable author: Blusapphire, SOC date: 2017/03/27 description: Detects known malicious service installs that only appear in cases of lateral movement, credential dumping, and other suspicious activities. references: - https://awakesecurity.com/blog/threat-hunting-for-paexec/ - https://blog.f-secure.com/wp-content/uploads/2019/10/CosmicDuke.pdf tags: - attack.persistence - attack.privilege_escalation - attack.t1035 - attack.t1050 level: critical falsepositives: - Penetration testing logsource: product: windows service: system detection: selection: EventID: 7045 malsvc_paexec: ServiceFileName|contains: '\PAExec' malsvc_wannacry: ServiceName: 'mssecsvc2.0' malsvc_persistence: 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.

Sections	Attributes	Value (Example)	Remark
Metadata	title	Installation of Malicious Service	Mandatory
id	2cfe636e-317a-4bee-9f2c-1066d9f54d1a	Optional
status	stable
author	Blusapphire, SOC
date	2017/03/27
modified	2021/07/06
description	Detects known malicious service installs that only appear in cases of lateral movement, credential dumping, and other suspicious activities.
references	- https://awakesecurity.com/blog/threat-hunting-for-paexec/ - https://blog.f-secure.com/wp-content/uploads/2019/10/CosmicDuke.pdf
tags	- attack.t1035 - attack.t1050
falsepositives	- Penetration testing
level	critical
Logsource	logsource		Mandatory
category		Optional
product	windows
service	system
definition
Detection	detection		Mandatory
	selection: EventID: 7045 malsvc_paexec: ServiceFileName|contains: '\PAExec' malsvc_wannacry: ServiceName: 'mssecsvc2.0' malsvc_persistence: ServiceFileName|contains: 'net user'
condition	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.

Understanding Sigma Operators/Attributes:

• 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

Logsource Example
logsource: product: windows service: powershell 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
logsource: category: process_creation product: windows

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

Data Type	Examples	Operator	Translates To
Lists	selection: EventID: - 4624 - 4625	OR	(EventID:”4624” OR EventID:”4625”)
Maps	selection: EventID: 1 Image: ‘*powershell.exe’	AND	(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.

Value Modifier	What changes, when value modifiers are used	Examples
contains	Adds ‘*’ to beginning & end of the field value	CommandLine|contains
all	Chages the default list behavior from ‘or’ to ‘and’	CommandLine|contains|all
startswith	Adds ‘*’ to the end of the field value	Image|startswith
endswith	Adds ‘*’ to the beginning of the field value	ParentImage|endswith

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

Operator	Examples
Logical and/or	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)

Basic Syntax:

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 '’

Rule Creation from BluSapphire Portal:

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.

Annexure-A

Field Attributes	Attribute Properties
Title	Provide a brief title for the rule, keep it simple and short Type: string
ID	Global unique identifier for rule, auto generated during rule creation and used internally (optional)
Status	Defines the maturity of the rule. (optional) Possible values: experimental - usable in test environment, which may require additional tuning to reduce noise and false-positives (FPs) testing - Tunning is required stable - Usable in production environments Note: Blusapphire offers a mixed set of base rules, which may require tuning and can vary between organizations depending on IT policies implemented. Any newly created custom rule for an organization, it is preferred to initially set it to experimental and change it overtime depending on tunning.
Author	Author of the rule (special should be inside single quotes), Comma is used to separate multiple users. (optional) Type: string
Date	Creation date of the rule. (optional) Format: YYYY/MM/DD
Modified	Modified date of the rule. (optional) Format: YYYY/MM/DD
Description	Short description of the rule and its context of detection. (optional) Type: String
References	List of references to external sources for the rule
Tags	Tag the rule based on the context of logsource or log data or even detection. Field allows lowercase, underscores hyphens and no-spaces. Type: String E.g., For windows rule you may tag it with Mitre Framework based on Technique like attack.t1086
Level	Field defines the criticality of the rule. Possible values: Low Medium High Critical
Logsource	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. Possible values: Category – logs which fall under a particular category (e.g., DNS, Server-Logs, Process_Creation, Network, etc.) Product – logs generated by a particular product (e.g., windows event channel, Linux, Firewall, etc.) Service – Subset of product log (e.g., Security, Powershell, Sysmon, etc.) Definition – Describes the
Detection	Defines a set of search-identifiers that represent searches on log data, support both lists, maps(dictionaries) data-structures. Search-Identifiers (selection) – are key/value pairs, what an analyst would want to select (or) search from the log data. Multiple values can be included in a Lists (OR – dash bulleted) or Maps (AND – new lines). Value Modifiers can be used to change the search-identifier behavior and are attached to the end of a field name after the pipe “|” character. Condition-Expression (condition) – ties the selection fields together, defining how the detection tool will process each selection, filter fields in relation to the others.

Note: Please watch this video to follow along as needed.