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:
-
-
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 |-
-
- 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:
Note:
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:
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:
Defines a set of search-identifiers that represent searches on log data, support both lists, maps(dictionaries) data-structures.