Task 23, Day 18, Sigma Lumberjack Lenny Learns New Rules

Threat detection involves proactively prusuing and analysing abnormal activity within an ecosystem to identify malicious signs of compromise or intrusion within a network.

IOCs - Indicators of compromise.

Attack Scenario

Logs pointed to a likely attack and can be mapped to the UKC. Use Sigma application to chop logs. Sigma is an open-source generic signature language for describing log events in a structured format. Format uses YAML, markup language with a designed syntax allowing for quick sharing of detection methods by security analysts. Common factors of note about YAML files:

  • YAML is case-sensitive
  • Files should have the .yml extention
  • Spaces are used for indentation and not tabs
  • Comments are attributed using #
  • Key-value pairs denoted using :
  • Array elements denoted using -

Sigma rules are vendor-agnostic, so the rules can be converted to a format that fits the preferred SIEM.

Sigma Rule Syntax

Rules guided by a given order of required/optional fields and values that create the structure for mapping needed queries.

  • Title - names the rulle based on what it’s supposed to detect
  • ID - globally unique ID that is mainly used to maintain the order of identification for the rules submitted to the public repository (in UUID format)
  • Status - The stage in which the rule maturity is at while in use
    • Stable: rule may be used in prod and dashboards
    • Test: trials being done to the rule and could require fine-tuning
    • Experimental: rule is very generic and is being tested. Could lead to false results, be noisy, and identify exciting events
    • Deprecated: rule has been replaced and would no longer yield accurate results
    • Unsupported: rule is not usable in its current state (unique correlation log, homemade fields)
  • Description - provides more context about rule and its intended purpose
  • Logsource - describes the log to be used for the detection. optional attributes:
    • Product: selects all outputs of a certain product (i.e. Windows, Apache, etc.)
    • Category: selects the log files written by the selected product (i.e. firewalls, web, antivirus)
    • Service: selects only subset of the logs (i.e. sshd on Linux, Security on Windows)
    • Definition: describes the log source and its applied configs
  • Detection - required field in the detection rule describes the parameters of the malicious activity we’re looking for. Two main parts:
    • Search identifiers: fields and values the detection should search for. Can be enhanced with different modifiers piped on end. (Main type known as Transfomation modifiers, i.e. contains, endswith, startswith, all)
    • Condition expression: sets action to be taken on detection, such as selection or filtering.
  • FalsePositives - list of known fales positives that may occur based on log data
  • Level - severity with which the team should take the activity written under rule. Informational -> Low -> Medium -> High -> Critical
  • Tags - adds information used to categorize the rule. Common tags include tactics and techniques from MITRE ATT&CK, defined list from Sigma devs at https://github.com/SigmaHQ/sigma/wiki/Tags

Tools include Sigmac (deprecated), pySigma, and Uncoder.io.

The Task

Use THM Sigma tool to generate rules/queries and get flags and details about each step of attack.

Flags gotten, fun had.