A Guide on Creating SIGMA Rules

Hello, cyber sentinels! Today, we’re going to make sense of SIGMA rules, piece by piece. Imagine it like a LEGO set. Each block has a purpose, and together, they form a powerful tool for threat detection. Let’s dig in!

SIGMA: Unpacking the Magic

SIGMA, in a nutshell, is a universal language for expressing threat detection rules. It’s like having a translator that speaks Splunk, QRadar, ElasticSearch, and more. But how does it work? Let’s break it down:

Phishing example

title: Detect Phishing Domains
id: e6a8b899-1c5c-492c-91a6-c5a7b730e6b0
status: stable
description: Detects access to potential phishing domains
author: John Doe
date: 2023/06/26
logsource:
  category: proxy
detection:
  selection:
    c-dns:
      - '*paypal*'
      - '*login*'
  condition: selection
falsepositives:
  - Legitimate websites with similar names
level: high

Title & ID

title: Detect Phishing Domains
id: e6a8b899-1c5c-492c-91a6-c5a7b730e6b0

These are your rule’s identity. The title gives a brief idea of what your rule does. The id is a unique identifier, usually a UUID. Think of it as the rule’s fingerprint.

Status, Description, Author, Date

status: stable
description: Detects access to potential phishing domains
author: John Doe
date: 2023/06/26

These fields provide more details about your rule. The status tells how mature the rule is. The description is a more detailed explanation of the rule’s purpose. The author is you, and the date is when you wrote the rule.

Logsource

logsource:
  category: proxy

This is where your rule looks for threats. It defines the type or category of the log data to analyze. In this example, it’s proxy logs. Different rules might require different sources.

Detection

detection:
  selection:
    c-dns:
      - '*paypal*'
      - '*login*'
  condition: selection

This is the heart of your SIGMA rule. The detection block describes the suspicious patterns to look for. selection defines the specific properties to match in the logs. The condition tells when to trigger the rule. Here, the rule triggers if any selection matches.

False Positives

falsepositives:
  - Legitimate websites with similar names

This field lists scenarios where the rule might give a false alarm. It helps you fine-tune your rule to minimize these false positives.

Level

level: high

This sets the severity level of the rule. It helps prioritize your response when the rule triggers.

Unmasking Mimikatz with SIGMA

Here’s how a SIGMA rule hunts down Mimikatz:

Title & ID

title: Mimikatz Use
id: 06d71506-7beb-4f22-8888-e2e5e2ca7fd8

First up, the title and id. The title is a short and sweet summary of the rule’s purpose. The id is a unique code, like a rule’s passport number.

Status, Description, Author, Date, References & Tags

status: test
description: This method detects mimikatz keywords in different Eventlogs
author: Florian Roth (Nextron Systems), David ANDRE (additional keywords)
date: 2017/01/10
modified: 2022/01/05
references:
    - https://tools.thehacker.recipes/mimikatz/modules
tags:
    - attack.s0002
    - attack.lateral_movement
    - attack.credential_access
    - car.2013-07-001
    - car.2019-04-004
    - attack.t1003.002
    - attack.t1003.004
    - attack.t1003.001
    - attack.t1003.006

These details tell us more about the rule. status shows the rule’s maturity level. The description provides a longer explanation of the rule. author is the rule’s creator. date and modified are the creation and modification dates, respectively. references provide sources for more information. The tags are keywords related to the rule. They can help categorize or search for the rule.

Logsource

logsource:
  product: windows

This is the rule’s hunting ground. It tells us where to look for Mimikatz. In this case, it’s windows.

Detection

detection:
  keywords:
    - 'dpapi::masterkey'
    - 'eo.oe.kiwi'
    - 'event::clear'
    - 'event::drop'
    - 'gentilkiwi.com'
    - 'kerberos::golden'
    - 'kerberos::ptc'
    - 'kerberos::ptt'
    - 'kerberos::tgt'
    - 'Kiwi Legit Printer'
    - 'lsadump::'
    - 'mimidrv.sys'
    - '\mimilib.dll'
    - 'misc::printnightmare'
    - 'misc::shadowcopies'
    - 'misc::skeleton'
    - 'privilege::backup'
    - 'privilege::debug'
    - 'privilege::driver'
    - 'sekurlsa::'
  filter:
    EventID: 15  # Sysmon's FileStream Events
  condition: keywords and not filter

This is the main event. The detection block describes what to look for. keywords are the specific signs of Mimikatz in the logs. The filter is there to ignore irrelevant data and reduce noise. The condition is the trigger. The rule activates when keywords match and filter does not.

And that’s it, folks! You’re now armed and ready to create your own SIGMA rules. Happy hunting!

Sources used: