Using Sigma Rules inside Attack Flows as a Structured Way to Describe an Incident

If you are reading this blog post via a 3rd party source it is very likely that many parts of it will not render correctly (usually, the interactive graphs). Please view the post on our blog for the full interactive viewing experience.

tl;dr

It has become common place to classify detection rules using MITRE ATT&CK to describe the stage of the attack (Tactic) and subsequent Techniques they detect.

As I covered in Writing Advanced Sigma Detection Rules: Using Correlation Rules, as an industry we’ve largely moved on from detecting against single events, and now look at correlations of detections.

This “flow” of correlated detections ties in nicely with Attack Flows. In this post I’ll show you how you can use the two together to significantly improve your incident workflows.

Sigma Correlations

Before we begin, if you are unfamiliar with Attack Flows, read this post introducing Attack Flows on the dogesec blog.

Whilst that post looks at the flow of observables and TTPs being described in an intelligence report, ultimately it is also describing how these events could be detected too.

The missing part in the Attack Flow is the detection content.

In my post, Writing Advanced Sigma Detection Rules: Using Correlation Rules I touched on the types of Sigma Correlation Rules. To recap these are;

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.
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.
temporal: A cluster rule where an alert is generated if multiple distinct but related rules fire within a given timeframe.
ordered_temporal: A chain rule where an alert is generated if distinct but related rules fire within a given timeframe in a particular order.

ordered_temporal is the most immediately suited to Attack Flows because the correlation is defining the order the detections should be seen. The order of an attack.

Take this Sigma Correlation which can be explained as; fire a detection if the rule 1ddaa9a4-eb0b-4398-a9fe-7b018f9e23db is triggered less than 10s after the rule a902d249-9b9c-4dc4-8fd0-fbe528ef965c is triggered:

### CORRELATION RULE
title: CVE-2023-22518 Exploit Chain
description: Access to endpoint vulnerable to CVE-2023-22518 with suspicious process creation.
status: experimental
correlation:
  type: ordered_temporal
  rules:
    - a902d249-9b9c-4dc4-8fd0-fbe528ef965c
    - 1ddaa9a4-eb0b-4398-a9fe-7b018f9e23db
  timespan: 10s
level: high
---
### BASE RULE
title: CVE-2023-22518 Exploitation Attempt - Vulnerable Endpoint Connection (Webserver)
id: a902d249-9b9c-4dc4-8fd0-fbe528ef965c
related:
    - id: 27d2cdde-9778-490e-91ec-9bd0be6e8cc6
      type: similar
status: test
description: |
    Detects exploitation attempt of CVE-2023-22518 (Confluence Data Center / Confluence Server), where an attacker can exploit vulnerable endpoints to e.g. create admin accounts and execute arbitrary commands.
references:
    - https://confluence.atlassian.com/security/cve-2023-22518-improper-authorization-vulnerability-in-confluence-data-center-and-server-1311473907.html
    - https://www.huntress.com/blog/confluence-to-cerber-exploitation-of-cve-2023-22518-for-ransomware-deployment
    - https://github.com/ForceFledgling/CVE-2023-22518
author: Andreas Braathen (mnemonic.io)
date: 2023-11-14
tags:
    - detection.emerging-threats
    - attack.initial-access
    - attack.t1190
    - cve.2023-22518
logsource:
    category: webserver
detection:
    selection_method:
        cs-method: 'POST'
    selection_uris:
        cs-uri-query|contains:
          # Exploitable endpoints
            - '/json/setup-restore-local.action'
            - '/json/setup-restore-progress.action'
            - '/json/setup-restore.action'
            - '/server-info.action'
            - '/setup/setupadministrator.action'
    selection_status:
        # Response code may be indicative of exploitation success, but is not always the case
        sc-status:
            - 200
            - 302
            - 405
    condition: all of selection_*
falsepositives:
    - Vulnerability scanners
level: medium
---
### BASE RULE
title: CVE-2023-22518 Exploitation Attempt - Suspicious Confluence Child Process (Linux)
id: f8987c03-4290-4c96-870f-55e75ee377f4
related:
    - id: 1ddaa9a4-eb0b-4398-a9fe-7b018f9e23db
      type: similar
status: test
description: |
    Detects exploitation attempt of CVE-2023-22518 (Confluence Data Center / Confluence Server), where an attacker can exploit vulnerable endpoints to e.g. create admin accounts and execute arbitrary commands.
references:
    - https://confluence.atlassian.com/security/cve-2023-22518-improper-authorization-vulnerability-in-confluence-data-center-and-server-1311473907.html
    - https://www.huntress.com/blog/confluence-to-cerber-exploitation-of-cve-2023-22518-for-ransomware-deployment
    - https://github.com/ForceFledgling/CVE-2023-22518
author: Andreas Braathen (mnemonic.io)
date: 2023-11-14
tags:
    - detection.emerging-threats
    - attack.execution
    - attack.t1059
    - attack.initial-access
    - attack.t1190
    - cve.2023-22518
logsource:
    category: process_creation
    product: linux
detection:
    selection_parent:
        ParentImage|endswith: '/java'
        ParentCommandLine|contains: 'confluence'
    selection_child:
        # Only children associated with known campaigns
        Image|endswith:
            - '/bash'
            - '/curl'
            - '/echo'
            - '/wget'
    filter_main_ulimit:
        CommandLine|contains: 'ulimit -u'
    condition: all of selection_* and not 1 of filter_main_*
falsepositives:
    - Unlikely
level: high

In the first rule a902d249-9b9c-4dc4-8fd0-fbe528ef965c the ATT&CK specific tags are;

attack.initial-access
attack.t1190 (Exploit Public-Facing Application)

MITRE ATT&CK Initial Access

In the second rule (to be triggered within 10 seconds of the first) f8987c03-4290-4c96-870f-55e75ee377f4 the ATT&CK specific tags are;

attack.execution
attack.t1059 (Command and Scripting Interpreter)
attack.initial-access
attack.t1190 (Exploit Public-Facing Application)

MITRE ATT&CK Execution

Representing as an Attack Flow

So from this Sigma Correlation Rule we have an Attack Flow with two Attack Flow Actions.

Now the question becomes… Should this be represented as one Sigma Correlation rule (made up of two Base Rules), linked to two Attack Flow Objects? Like so…

CVE-2023-22518 Sigma Attack Flow using Correlation Rule

Or; is it two Sigma Base Rules the make up the Correlation, linked to the two Attack Flow Objects based on the ATT&CK Objects in defined in each rule? Like so…

CVE-2023-22518 Sigma Attack Flow using Base Rules

In this case I believe the first option is better.

Sigma Correlation rules were designed to add additional conditions to a detection to reduce false positive detections. Splitting them out removes this context.

As Attack Flows grow, for example this one for Black Basta), you will want to include many more detections. However, these don’t always need to be Sigma Correlations, they could be a mix of Sigma Base Rules and Sigma Correlation Rules – the best available detection should be used at each stage.

You might now be thinking; why not use a single Sigma Correlations for the entire flow in this case.

The answer is simple; Sigma Correlations are not designed to detect an entire attack.

Attacks are fluid, actors often modify their techniques based on the victims infrastructure, therefore parallel paths of detections might be required, something that can’t be accounted for in Sigma Correlations.

Or thinking about it even more simply; the time between stages in an attack is not universal. Initial access might require much more time in one environment, actors might lay dormant inside a network for differing periods of time… you get the idea.

Creating rigid correlations with multiple detections across all stages of an attack will mean they almost immediately become outdated for the reasons described.

It also means you are not limited to ordered_temporal type Sigma Correlations when creating Attack Flows. For example, event_count Correlations (which contain only one Base Rule) can be represented using this approach.

Attack Flows answer the question “what’s next?” when detections are triggered

Fundamentally detections, whether Base or Correlation are often treated in isolation today. Which is odd, because analysts spend countless hours grouping alerts from triggered detection in their SIEM when triaging and dealing with an incident.

By adding the detection part into Attack Flows, the story of an attack is explained. If an analyst sees a detection triggered in the early stages of Attack Flow, they have an indication of what might have gone before, and what might be coming. This means; 1) they can put in place appropriate detection coverage should it not already exist, and 2) put in place measures to proactively defend against the next techniques known to be used.

This is why we built the ability to process threat intelligence reports into detection rules in SIEM Rules. The report not only provides the logic to generate Sigma Rules, but it also provides the context of what stage of an attack the Rule represent (using ATT&CK Tactics and Techniques in an Attack Flow).

Posted by: