Manual
Search…
⌃K

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
  1. 1.
    Search for Windows EventID “7045”
  2. 2.
    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. 1.
    From Blusapphire portal, navigate to “Rule Management" page available under “Entity Behavior” menu item.
  1. 1.
    To create a new rule, click on “New” button available on top right side. As described earlier in this document:
    1. 1.
      Provide an appropriate rule name
    1. 1.
      Provide the required metadata fields
    1. 1.
      Provide required Logsource as per specifications.
    2. 2.
      Define the search-identifiers (selection/filters) for the rule and the condition.
    1. 1.
      Finally check, validate and save the new rule.
    1. 1.
      Newly created rules will be enabled by default.
    1. 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.