Photo by Vidar Nordli-Mathisen on Unsplash

Dive into Sigma Correlation Rules

And go hunting for Cicada3301 ransomware behaviors in the process

Getting Caught Up

It is amazing how much can change in less than a year! Since I last posted in October of 2023, one of my favorite detection engineering community projects, Sigma, has reached new heights of innovation and vitality. If you have dabbled in Sigma (maybe back in the days when Uncoder.io was the only game in town for UI-based rule conversion), I highly recommend revisiting the project, since a lot has changed. First of all, start at https://sigmahq.io, Sigma’s wonderful new(ish) homepage. From there, you can learn or refresh yourself on the basics, find updated documentation, and link to various rulesets and tools like https://sigconverter.io/ and https://sigmasearchengine.com/.

In recent months I’ve gotten in the habit of describing Sigma as three things — a format, a toolset, and a library:

1. A generic, open-source detection rule format that can capture threat detection ideas independently of any vendor specification,
2. A robust and ever-growing conversion toolset that can translate those concepts into your vendor-specific product of choice, and…
3. An epic library of quality, peer-reviewed detection rules that can be applied to detect and hunt for well-known, emerging, and highly-impactful threats.

However, I think it is past time to add a fourth component to my (unofficial) definition of Sigma — a vibrant community of analysts, developers, engineers, and students who build the tools, write the docs, craft the rules, and apply them to find threats.

Don’t Hesitate…Correlate!

Now that we are caught up, let’s dive into one of the most exciting and eagerly-anticipated capabilities of the new Sigma: Correlation Rules! Broadly speaking, log correlation allows an analyst or detection engineer to detect threats by linking multiple events or log messages together based on a meaningful relationship.

The classic example of correlation is brute force attack detection: by linking multiple failed logon events together, based on characteristics like source IP, target system, or other meaningful attributes, we can identify patterns which a single event would not reveal. Historically, Sigma rules have largely focused on detections of single significant events. However, as of Summer 2024, pySigma (the codebase which powers Sigma) now supports the application of several types of logical correlations to link related Sigma rule outputs together. I highly recommend reading the blog post by Thomas Patzke on Sigma Correlations, which does a great job introducing the new capability:

Introducing Sigma Correlations

Patzke describes the four types of correlation rules that are currently supported (which you can read about in the specification here). I’ve listed them and described them in my own words below:

1. Event Count: A threshold rule where and alert is generated if the number of times a particular rule fires is exceeded, with a field specified to meaningfully group the events.
2. Value Count: A threshold rule where an alert fires if the number of unique values for a certain field in a given rule is exceeded within a given timeframe, grouped by a particular field which links the events.
3. Temporal Proximity: A cluster rule where an alert is generated if multiple distinct but related rules fire within a given timeframe.
4. Ordered Temporal Proximity: A chain rule where an alert is generated if distinct but related rules fire within a given timeframe in a particular order.

Security analysts and detection specialists who have worked with large amounts of data in a SIEM will probably have a good idea of what these types of correlations can do. But if you are like me, learning happens best when you have a real example, where you can think through a problem and apply the solution. So, now that we are armed with new Sigma correlation capabilities, and with a real-world example which I’ll share in the next paragraph, let’s dive in!

Diving In

At the tail end of 2022, I wrote about HTML Smuggling and referenced the Sigma correlations concept (then in draft stage). Now that the real thing is in production and available to use with the Splunk Sigma backend plugin, I chose to try writing some Sigma rules and correlations based on a recent threat report on Cicada3301 ransomware. The report, written by Michael Gorelik from Morphisec, gives an insightful, procedure-level look at the tactics and techniques used by a new ransomware group. It requires entering some contact info to download the full report, but I definitely recommend it!

Decoding the Puzzle: Cicada3301 Ransomware Threat Analysis

First the easy stuff: Gorelik reports that Cicada3301 ransomware runs using renamed psexec, with custom command line flags like the ones shown below in the report:

Credit: Michael Gorelik, Morphisec

Using this understanding, the following rule will detect a renamed psexec performing some process creation using one or more flags associated with the malicious Cicada3301 binary:

title: Cicada3301 Ransomware Execution via PSExec
id: 79495647-d84d-4804-9a52-5263cfdf2c63
status: experimental
description: |
    Detects the use of a potentially-renamed psexec to run the Cicada3301 ransomware tool.
references:
    - https://engage.morphisec.com/threat-analysis-cicada3301
author: 'Micah Babinski, Based on Morphisec report by Michael Gorelik (@smgoreli)'
date: 2024-09-08
tags:
    - attack.execution
    - attack.t1569
    - attack.t1569.002
    - attack.s0029
logsource:
    category: process_creation
    product: windows
detection:
    selection_1:
        - Image|endswith: '\psexec0.exe'
        - OriginalFileName: 'psexec.c'
    selection_2:
        CommandLine|contains:
            - '--key'
            - '--path'
            - '-p '
            - '-s '
            - '--no_local'
            - '--no_net'
            - '--no_impl'
            - '--no_notes'
    filter:
        Image|endswith: '\psexec.exe'
    condition: all of selection_* and not filter
falsepositives:
    - Unknown
level: high

There are a couple of other single-event rules which could be useful to hunt or detect on this behavior, including an interesting one for the iisreset utility, which I had never heard of.

But “come on!” you say. “We’re here for the correlations!” Message received: let’s correlate! About halfway through the report, Gorelik reports on service stoppage and process killing activity performed in conjunction with these ransomware intrusions, and he goes on to provide a lengthy list of processes which are stopped and tasks which are killed. Here is a screenshot from the report showing the services which Cicada3301 ransomware intruders stop using the sc utility:

Credit: Michael Gorelik, Morphisec (annotations by the author)

I thought these two patterns of behavior could make could test cases for Sigma correlations. While a single service entering a stopped state would be no big deal, if this were to occur repeatedly, it might warrant an investigation (ditto for the use of taskkill.exe to terminate processes).

When writing a Sigma correlation rule, it’s best to start where you normally would — with a single Sigma rule. Since we are talking about killing processes with taskkill and offing services with sc, I found three rules in the main Sigma rule repo which were helpful as starting places:

1. Windows Defender Threat Detection Service Disabled (I LOVE that this one works in French!)
2. Taskkill Symantec Endpoint Protection
3. Stop Windows Service Via Sc.EXE

I used rules one and two, lightly modified to make them applicable to this list of processes and services referenced in the Cicada report. With these identified, we can simply add another YAML document in the same file file, separated by three hyphen characters:

---

Then, we define a separate rule that references the single event rule, and defines the parameters of the correlation. When I was done it looked like the screen capture below:

Note the event_count correlation type, referencing the rule at the bottom and grouping by Computer

For my test, I chose to use Windows System event 7036, showing that a service has entered the “stopped” state, repeated five or more times on a single computer within a 10 minute period. This could also be accomplished with a process creation rule using the sc.exe utility. Try that one out yourself!

For the process killing rule, I repeated the same format, just using a different log source. Note that the logsource only needs to be defined in the single-event rule referenced by the correlation.

title: Correlation - Mass Taskkill Usage Associated with Cicada3301 Ransomware
id: 135e717e-2b3a-485f-9976-40e74a2e558c
status: experimental
description: Detects repeated use of the taskkill utility to terminate processes as documented in the 2024 Morphisec Cicada3301 ransomware report.
references:
    - https://blog.morphisec.com/cicada3301-ransomware-threat-analysis
author: 'Micah Babinski, Based on Morphisec report by Michael Gorelik (@smgoreli)'
date: 2024-09-08
tags:
    - attack.impact
    - attack.t1489
correlation:
    type: event_count
    rules:
        - task_terminated_with_taskkill
    group-by:
        - Computer
    timespan: 10m
    condition:
        gte: 5
level: medium
---
title: Single Taskkill Usage Associated with Cicada3301 Ransomware
name: task_terminated_with_taskkill
id: 78689f2e-64e0-4363-942b-d676a7af7f12
status: experimental
description: Detects a single use of the taskkill utility to terminate processes as documented in the 2024 Morphisec Cicada3301 ransomware report.
author: 'Micah Babinski, Based on Morphisec report by Michael Gorelik (@smgoreli)'
date: 2024-09-08
tags:
    - attack.impact
    - attack.t1489
logsource:
    category: process_creation
    product: windows
detection:
    selection_proc:
        - Image|endswith: '\taskkill.exe'
        - OriginalFileName: 'taskkill.exe'
    selection_cmd:
        CommandLine|contains:
            - 'agntsvc'
            - 'onenote'
            - 'bedbh'
            - 'tv_x64'
            - 'dbeng50'
            - 'oracle'
            - 'vxmon'
            - 'CVMountd'
            - 'dbsnmp'
            - 'outlook'
            - 'benetns'
            - 'cvd'
            - 'encsvc'
            - 'powerpnt'
            - 'bengien'
            - 'cvfwd'
            - 'excel'
            - 'sqbcoreservic'
            - 'pvlsvr'
            - 'CVODS'
            - 'firefox'
            - 'sql'
            - 'beserver'
            - 'saphostexe'
            - 'infopath'
            - 'steam'
            - 'raw_agent_svc'
            - 'saposcol'
            - 'isqlplussvc'
            - 'synctime'
            - 'vsnapvss'
            - 'sapstartsrv'
            - 'msaccess'
            - 'tbirdconfig'
            - 'CagService'
            - 'avagent'
            - 'mspub'
            - 'thebat'
            - 'QBIDPService'
            - 'avscc'
            - 'mydesktopq'
            - 'thunderbird'
            - 'QBDBMgrN'
            - 'DellSystem'
            - 'mydesktopservic'
            - 'visio'
            - 'QBCFMonitorSe'
            - 'EnterpriseClient'
            - 'notepad'
            - 'winword'
            - 'SAP'
            - 'VeeamNFSSvc'
            - 'ocautoupds'
            - 'wordpad'
            - 'TeamViewer_Service'
            - 'VeeamTransportSvc'
            - 'oco'
            - 'xfssvccon'
            - 'TeamViewer'
            - 'VeeamDeploymentSvc'
            - 'ocssd'
            - 'sql'
            - 'tv_w32'
    condition: all of selection_*
falsepositives:
    - Unknown
level: informational

Kicking the Tires

With my correlation rules drafted, it was time to convert them to Splunk queries to test the output and ensure they work properly. For this it is currently necessary to use Sigma CLI, since a GUI-based Sigma rule converter like https://sigconverter.io/ will not yet handle correlation rules. For folks new to Sigma CLI who are looking to try this at home, here is my step by step process.

Install Python

Head to the Python downloads page and install the latest version. If you are on Windows and get an error running the installer, try running it as Administrator.

Download Python

Add Python to your Path

Again, if you are new, this one is helpful for running Python commands from the command line. Run the built-in IDLE utility to locate your Python executable:

Damn right I use IDLE

Then, if on Windows, enter “Edit environment variables” into Windows search and add the directory where your pythonw.exe is located to the Path environment variable as shown below:

You are ready to go

Install Sigma CLI with Pip

If you have added Python to your Path you should have no problem with the following commands (the virtual environment stuff can be skipped but is good if you want to be/are a cool kid 😎):

C:\Users\You\WorkingFolder>python venv .\SigmaDemo
C:\Users\You\WorkingFolder>cd SigmaDemo
C:\Users\You\WorkingFolder\SigmaDemo>Scripts\activate.bat
(SigmaDemo) C:\Users\You\WorkingFolder\SigmaDemo>pip install sigma-cli
...stuff happens

(SigmaDemo) C:\Users\You\WorkingFolder\SigmaDemo>sigma plugin install splunk
Successfully installed plugin 'splunk'
pySigma version is compatible with sigma-cli

(SigmaDemo) C:\Users\You\WorkingFolder\SigmaDemo>sigma plugin install sysmon
Successfully installed plugin 'sysmon'
pySigma version is compatible with sigma-cli

There, ready to go! Now, with the your correlation rules downloaded locally (or feel free to use mine here), you can convert a rule and witness the beautiful aggregation query that is generated:

Correlation station, here we come! Toot toot! 🚂

Wrapping Up

In summary, Sigma correlations are a great new way to hunt, detect, and research threats, and share those insights and findings with the cybersecurity community. I hope this article has shown Sigma newcomers how easy it is to get started taking novel research (like the Morphisec Cicada3301 report) and generating useful, interesting detection rule concepts that can be easily shared with others. From this point, you could fire up your home lab, safely emulate some of the techniques and procedures from the report, and test whether the output from these Sigma rules (correlation and single event) are actually any good. PLEASE let me know if you end up doing that, or if you have any questions or comments on this article. It is a pleasure hearing from you!

Detectionately Yours,

Micah

GitHub - mbabinski/Sigma-Rules: A repository of my own Sigma detection rules.