FaresMorcy
  • Whoami
  • Footprinting Labs
    • Lab - Easy
    • Lab - Medium
    • Lab - Hard
  • Shells & Payloads
    • The Live Engagement
  • Password Attacks
    • Lab - Easy
    • Lab - Medium
    • Lab - Hard
  • Active Directory Enumeration & Attacks
    • Active Directory Enumeration & Attacks
    • AD Enumeration & Attacks - Skills Assessment Part I
    • AD Enumeration & Attacks - Skills Assessment Part II
  • SOC Hackthebox Notes & Labs
    • Security Monitoring & SIEM Fundamentals Module
    • Windows Event Logs & Finding Evil Module
    • Introduction to Threat Hunting & Hunting With Elastic Module
    • Understanding Log Sources & Investigating with Splunk Module
      • Introduction To Splunk & SPL
      • Using Splunk Applications
      • Intrusion Detection With Splunk (Real-world Scenario)
      • Detecting Attacker Behavior With Splunk Based On TTPs
      • Detecting Attacker Behavior With Splunk Based On Analytics
      • Skills Assessment
    • Windows Attacks & Defense
      • Kerberoasting
      • AS-REProasting
      • GPP Passwords
      • GPO Permissions/GPO Files
      • Credentials in Shares
      • Credentials in Object Properties
      • DCSync
      • Golden Ticket
      • Kerberos Constrained Delegation
      • Print Spooler & NTLM Relaying
      • Coercing Attacks & Unconstrained Delegation
      • Object ACLs
      • PKI - ESC1
      • Skills Assessment
    • Intro to Network Traffic Analysis Module
    • YARA & Sigma for SOC Analysts Module
      • Developing YARA Rules
      • Hunting Evil with YARA (Windows Edition)
      • Hunting Evil with YARA (Linux Edition)
      • Sigma and Sigma Rules
      • Developing Sigma Rules
      • Hunting Evil with Sigma (Chainsaw Edition)
      • Hunting Evil with Sigma (Splunk Edition)
      • Skills Assessment
  • TryHackme SOC 1
    • TShark
      • TShark: The Basics
      • TShark: CLI Wireshark Features
      • TShark Challenge I: Teamwork
      • TShark Challenge II: Directory
    • Tempest
    • Boogeyman 1
    • Boogeyman 2
    • Boogeyman 3
  • TryHackme SOC 2
    • Advanced Splunk
      • Splunk: Exploring SPL
      • Splunk: Setting up a SOC Lab
      • Splunk: Dashboards and Reports
      • Splunk: Data Manipulation
      • Fixit
    • Advanced ELK
      • Slingshot
    • Threat Hunting
      • Threat Hunting: Foothold
      • Threat Hunting: Pivoting
      • Threat Hunting: Endgame
  • TryHackme Rooms
    • Investigating Windows
    • Splunk 2
    • Windows Network Analysis
  • Powershell Scripting Fundamentals
  • SANS SEC504 & Labs
    • Book one
      • Live Examination
      • Network Investigations
      • Memory Investigations
      • Malware Investigations
      • Accelerating IR with Generative AI
      • Bootcamp: Linux Olympics
      • Bootcamp: Powershell Olympics
    • Book Two
      • Hacker Tools and Techniques Introduction
      • Target Discovery and Enumeration
      • Discovery and Scanning with Nmap
      • Cloud Spotlight: Cloud Scanning
      • SMB Security
      • Defense Spotlight: Hayabusa and Sigma Rules
    • Book Three
      • Password Attacks
      • Cloud Spotlight: Microsoft 365 Password Attacks
      • Understanding Password Hashes
      • Password Cracking
      • Cloud Spotlight: Insecure Storage
      • Multipurpose Netcat
    • Book Four
      • Metasploit Framework
      • Drive-By Attacks
      • Command Injection
      • Cross-Site Scripting
      • SQL Injection
      • Cloud Spotlight: SSRF and IMDS
    • Book Five
      • Endpoint Security Bypass
      • Pivoting and Lateral Movement
      • Hijacking Attacks
      • Establishing Persistence
      • Defense Spotlight: RITA
      • Cloud Spotlight: Cloud Post-Exploitation
  • SANS SEC511 & Labs
    • Resources
      • Primers
      • References
      • Tools
        • Network
        • Elastic Stack
      • Printable Versions
    • Book One
      • Part One
      • Part Two
      • Part Three
    • Book Two
      • Part One
      • Part Two
      • Part Three
      • Part Four
    • Book Three
      • Part One
      • Part Two
      • Part Three
      • Part Four
    • Book Four
      • Part One
      • Part Two
      • Part Three Lab
      • Part Four Lab
    • Book Five
      • Part One Lab
      • Part Two Lab
      • Part Three Lab
  • CyberDefenders
    • XXE Infiltration Lab
    • T1594 Lab
    • RetailBreach Lab
    • DanaBot Lab
    • OpenWire Lab
    • BlueSky Ransomware Lab
    • Openfire Lab
    • Boss Of The SOC v1 Lab
    • GoldenSpray Lab
    • REvil Lab
    • ShadowRoast Lab
    • SolarDisruption Lab
    • Kerberoasted Lab
    • T1197 Lab
    • Amadey Lab
    • Malware Traffic Analysis 1 Lab
    • Insider Lab
    • Volatility Traces Lab
    • FalconEye Lab
    • GitTheGate Lab
    • Trident Lab
    • NerisBot Lab
  • Practical Windows Forensics
    • Data Collection
    • Examination
    • Disk Analysis Introduction
    • User Behavior
    • Overview of disk structures, partitions and file systems
    • Finding Evidence of Deleted Files with USN Journal Analysis
    • Analyzing Evidence of Program Execution
    • Finding Evidence of Persistence Mechanisms
    • Uncover Malicious Activity with Windows Event Log Analysis
    • Windows Memory Forensic Analysis
  • Hackthebox Rooms
    • Campfire-1
    • Compromised
    • Brutus
    • Trent
    • CrownJewel-1
  • WEInnovate Training
    • Weinnovate - Active Directory Task One
    • Build ELK Lab
      • Configure Elasticsearch and Kibana setup in ubuntu
      • Configure Fluent-Bit to send logs to ELK
      • Set up Winlogbeat & Filebeat for log collection
      • Send Logs from Winlogbeat through Logstash to ELK
      • Enable Windows Audit Policy & Winlogbeat
      • Elasticsearch API and Ingestion Pipeline
    • SOAR
      • Send Alerts To Email & Telegram Bot
      • Integrate Tines with ELK
    • SOC Practical Assessment
    • Lumma C2
    • Network Analysis
  • Build ELK Lab
    • Configure Elasticsearch and Kibana setup in ubuntu
    • Configure Fluent-Bit to send logs to ELK
    • Set up Winlogbeat & Filebeat for log collection
    • Send Logs from Winlogbeat through Logstash to ELK
    • Enable Windows Audit Policy & Winlogbeat
    • Elasticsearch API and Ingestion Pipeline
  • Build Home Lab - SOC Automation
    • Install & configure Sysmon for deep Windows event logging
    • Set up Wazuh & TheHive for threat detection & case management
    • Execute Mimikatz & create detection rules in Wazuh
    • Automate everything with Shuffle
    • Response to SSH Attack Using Shuffle, Wazuh, and TheHive
  • Home Lab (Attack & Defense Scenarios)
    • Pass-the-Hash Attack & Defense
    • Scheduled Task Attack & Defense
    • Kerberoasting Attack & Defense
    • Kerberos Constrained Delegation
    • Password Spraying Attack & Defense
    • Golden Ticket Attack & Defense
    • AS-REProasting Attack & Defense
    • DCSync Attack & Defense
  • Home Lab (FIN7 (Carbanak Group) – Point of Sale (POS) Attack on Hospitality Chains)
  • Home Lab (Lumma Stealer)
Powered by GitBook
On this page
  1. SOC Hackthebox Notes & Labs
  2. YARA & Sigma for SOC Analysts Module

Sigma and Sigma Rules

PreviousHunting Evil with YARA (Linux Edition)NextDeveloping Sigma Rules

Last updated 9 months ago

Sigma is a generic signature format used for describing detection rules for log analysis and SIEM systems. It allows SOC analysts to create and share rules that help identify specific patterns or behaviors indicative of security threats or malicious activities. Sigma rules are typically written in YAML format and can be used with various security tools and platforms.

SOC analysts use Sigma rules to define and detect security events by analyzing log data generated by various systems, such as firewalls, intrusion detection systems, and endpoint protection solutions. These rules can be customized to match specific use cases and can include conditions, filters, and other parameters to determine when an event should trigger an alert.

The main advantage of Sigma rules is their portability and compatibility with multiple SIEM and log analysis systems, enabling analysts to write rules once and use them across different platforms.

Sigma can be considered as standardized format for analysts to create and share detection rules. It helps in converting the IOCs into queries and can be easily integrated with security tools, including SIEM and EDRs. Sigma rules can be used to detect suspicious activities in various log sources. This also helps in building efficient processes for Detection as Code by automating the creation and deployment of detection rules.

Usages of Sigma

  • Universal Log Analytics Tool: We can write detection rules once and then convert them to various SIEM and log analytics tool formats, sparing us the repetitive task of rewriting logic across different platforms.

  • Community-driven Rule Sharing: With Sigma, we have the ability to tap into a community that regularly contributes and shares their detection rules. This ensures that we constantly update and refine our detection mechanisms.

  • Incident Response: Sigma aids in incident response by enabling analysts to quickly search and analyze logs for specific patterns or indicators.

  • Proactive Threat Hunting: We can use Sigma rules for proactive threat hunting sessions. By leveraging specific patterns, we can comb through our datasets to pinpoint anomalies or signs of adversarial activity.

  • Seamless Integration with Automation Tools: By converting Sigma rules into appropriate formats, we can seamlessly integrate them with our SOAR platforms and other automation tools, enabling automated responses based on specific detections.

  • Customization for Specific Environments: The flexibility of Sigma rules means that we can tailor them according to the unique characteristics of our environment. Custom rules can address the specific threats or scenarios we're concerned about.

  • Gap Identification: By aligning our rule set with the broader community, we can perform gap analysis, identifying areas where our detection capabilities might need enhancement.

But here comes the magic. The true power of Sigma lies in its convertibility. We might ask, "If it's a standard format, how do we use it with our specific logging tools and platforms?" That's where the Sigma converter (sigmac) steps in. This converter is the linchpin of our workflow, transforming our Sigma rules into queries or configurations compatible with a multitude of SIEMs, log management solutions, and other security analytics tools.

Note: is increasingly becoming the go-to option for rule translation, as sigmac is now considered obsolete.

Sigma Rule Structure

As mentioned already, Sigma rule files are written in YAML format. Below is the structure of a Sigma rule.

Let's understand the structure of a Sigma rule with an example.

title: Potential LethalHTA Technique Execution 
id: ed5d72a6-f8f4-479d-ba79-02f6a80d7471 
status: test 
description: Detects potential LethalHTA technique where "mshta.exe" is spawned by an "svchost.exe" process
references:
    - https://codewhitesec.blogspot.com/2018/07/lethalhta.html
author: Markus Neis 
date: 2018/06/07 
tags: 
    - attack.defense_evasion 
    - attack.t1218.005 
logsource: 
    category: process_creation  
    product: windows
detection:
    selection: 
        ParentImage|endswith: '\svchost.exe'
        Image|endswith: '\mshta.exe'
    condition: selection
falsepositives: 
    - Unknown
level: high

The below screenshot shows the different components that form a Sigma Rule:

  • title: A brief title for the rule that should contain what the rule is supposed to detect (max. 256 characters)

  • status (optional): Declares the status of the rule.

    • stable: The rule didn't produce any obvious false positives in multiple environments over a long period of time

    • test: The rule doesn't show any obvious false positives on a limited set of test systems

    • experimental: A new rule that hasn't been tested outside of lab environments and could lead to many false positives

    • deprecated: The rule is to replace or cover another one. The link between rules is made via the related field.

    • unsupported: The rule can not be used in its current state (special correlation log, home-made fields, etc.)

  • description (optional): A short description of the rule and the malicious activity that can be detected (max. 65,535 characters)

  • references (optional): Citations to the original source from which the rule was inspired. These might include blog posts, academic articles, presentations, or even tweets.

  • author (optional): Creator of the rule (can be a name, nickname, twitter handle, etc).

  • date (optional): Rule creation date. Use the format YYYY/MM/DD.

It consists of three attributes that are evaluated automatically by the converters and an arbitrary number of optional elements. We recommend using a "definition" value when further explanation is necessary.

  • category: The category value is used to select all log files written by a certain group of products, like firewalls or web server logs. The automatic converter will use the keyword as a selector for multiple indices. Examples: firewall, web, antivirus, etc.

  • product: The product value is used to select all log outputs of a certain product, e.g. all Windows event log types including Security, System, Application and newer types like AppLocker and Windows Defender. Examples: windows, apache, check point fw1, etc.

  • service: The service value is used to select only a subset of a product's logs, like the sshd on Linux or the Security event log on Windows systems. Examples: sshd, applocker, etc.

  • detection: A set of search-identifiers that represent properties of searches on log data. Detection is made up of two components:

    • Search Identifiers

    • Condition

The values contained in Sigma rules can be modified by value modifiers. Value modifiers are appended after the field name with a pipe character (|) as separator and can also be chained, e.g. fieldname|mod1|mod2: value. The value modifiers are applied in the given order to the value.

The behavior of search identifiers is changed by value modifiers as shown in the table below:

Value Modifier
Explanation
Example

contains

Adds wildcard (*) characters around the value(s)

CommandLine|contains

all

Links all elements of a list with a logical "AND" (instead of the default "OR")

CommandLine|contains|all

startswith

Adds a wildcard (*) character at the end of the field value

ParentImage|startswith

endswith

Adds a wildcard (*) character at the begining of the field value

Image|endswith

re:

This value is handled as regular expression by backends

CommandLine|re: '\[String\]\s*\$VerbosePreference

Search identifiers include multiple values in two different data structures:

  1. Lists, which can contain:

  • strings that are applied to the full log message and are linked with a logical OR.

  • maps (see below). All map items of a list are linked with a logical OR.

Example list of strings that matches on evilservice or svchost.exe -n evil.

detection:
 	keywords:
		- evilservice
 		- svchost.exe -n evil

Example list of maps that matches on image file example.exe or on a executable whose description contains the string Test executable.

detection:
	selection:
 		- Image|endswith: '\example.exe'
		- Description|contains: 'Test executable'
  1. Maps: Maps (or dictionaries) consist of key/value pairs, in which the key is a field in the log data and the value a string or integer value. All elements of a map are joined with a logical AND.

Example that matches on event log Security and (Event ID 517 or Event ID 1102)

detection:
    selection:
  	    EventLog: Security
  	    EventID:
  	      - 517
     	  - 1102
	condition: selection

Example that matches on event log Security and Event ID 4679 and TicketOptions 0x40810000 and TicketEncryption 0x17.

detection:
	selection:
		EventLog: Security
		EventID: 4769
		TicketOptions: '0x40810000'
		TicketEncryption: '0x17'
	condition: selection	
  • Condition: Condition defines how fields are related to each other. If there's anything to filter, it can be defined in the condition. It uses various operators to define relationships for multiple fields which are explained below.

Operator
Example

Logical AND/OR

keywords1 or keywords2

1/all of them

all of them

1/all of search-identifier-pattern

all of selection*

1/all of search-id-pattern

all of filter_*

Negation with 'not'

keywords and not filters

Brackets - Order of operation '()'

selection1 and (keywords1 or keywords2)

Example of a condition:

condition: selection1 or selection2 or selection3

Sigma Rule Breakdown (based on ):

id: Sigma rules should be identified by a globally unique identifier in the id attribute. For this purpose are recommended but not mandatory.

logsource: This section describes the log data on which the detection is meant to be applied to. It describes the log source, the platform, the application and the type that is required in the detection. More information can be found in the following link:

Sigma's specification
randomly generated UUIDs (version 4)
https://github.com/SigmaHQ/sigma/tree/master/documentation/logsource-guides
pySigma