Using Sigma Rules in Attack Flows for Detection Coverage and SOC Triage

In this post

This post is a simple introduction to using Sigma detections with Attack Flows.

The goal is practical:

Map Sigma detections to individual Attack Flow actions so analysts can use triggered rules as position markers in an attack path.

This shift solves a practical SOC problem.

When an alert fires, analysts need to answer quickly:

• What exact behavior was detected?
• Where does that behavior sit in the likely attack path?
• Do we have coverage on the adjacent steps (before and after)?

This mapping gives you that visibility directly.

The key point is simple: each step can link to whatever detection type is most useful, including base rules and correlation rules.

Why rule-to-step mapping works

An Attack Flow action is the behavior step.

The linked Sigma rule is the detection evidence for that step.

That rule might be:

• a base rule for a direct behavior signal
• a correlation rule for a stronger multi-event signal

So the design pattern becomes:

• Attack Flow action = behavior step
• Sigma rule(s) = detection evidence for that step

Example: CVE-2023-22518 as a rule-linked flow

Here are two Sigma Base rules detecting an exploit of CVE-2023-22518. They are in attack order, that is, they should happen one after another (and yes, they could be covered in a temporal correlation to represent this logic).

First, vulnerable endpoint request:

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

Folllowed by Spawn suspicious child processes:

title: CVE-2023-22518 Exploitation Attempt - Suspicious Confluence Child Process (Windows)
id: 1ddaa9a4-eb0b-4398-a9fe-7b018f9e23db
related:
    - id: f8987c03-4290-4c96-870f-55e75ee377f4
      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
    - cve.2023-22518
logsource:
    category: process_creation
    product: windows
detection:
    selection_parent:
        ParentImage|endswith:
            - '\tomcat8.exe'
            - '\tomcat9.exe'
            - '\tomcat10.exe'
        ParentCommandLine|contains: 'confluence'
    selection_child:
        # Note: Only children associated with known campaigns
        - Image|endswith:
              - '\cmd.exe'
              - '\powershell.exe'
        - OriginalFileName:
              - 'Cmd.Exe'
              - 'PowerShell.EXE'
    condition: all of selection_*
falsepositives:
    - Unknown
level: medium

Jumping straight into the full flow view:

Using the Attack Flow Action steps you can see clearly the “flow” of the attack:

1. Exploit vulnerable Confluence endpoint
2. Spawn suspicious Confluence child process

This gives responders a more direct answer when one detection triggers:

• this is the known step we are currently observing
• these are the likely predecessor/successor steps
• these adjacent steps are covered / not covered by current detections

The same pattern works whether those linked detections are base rules, correlation rules, or a mix.

Coverage state: detected, detectable, or blind

Once rules are tied to flow actions like this, you can classify each step with a simple coverage state.

For each Attack Flow action:

• detected: one or more linked rules currently firing with expected fidelity
• detectable: rule exists
• blind: no rule exists for this step

This turns Attack Flow into a detection coverage map, not just an incident narrative.

SOC leads can then prioritize engineering work based on path criticality, not just rule count.

Example triage view for a triggered step:

1. Confirm which linked rule fired and on what entity scope (host/user/process).
2. Mark current flow position as detected.
3. Check immediate predecessor/successor actions for detectable or blind status.
4. Launch targeted hunts for uncovered adjacent actions.
5. Open engineering tasks for missing coverage with explicit flow-step references.

SOC triage playbook driven by flow-linked detections

This model is useful because it gives analysts a deterministic next-action pattern.

When a Sigma detection fires:

1. Anchor the current step: Map the fired rule to its linked Attack Flow action and ATT&CK technique.
2. Run look-back checks: Query for expected predecessor actions in a bounded time window and shared entity context.
3. Run look-forward checks: Pre-stage queries and detections for likely successor actions before they complete.
4. Assess coverage gaps immediately: If next-step actions are blind, escalate for temporary compensating controls and emergency rule creation.
5. Feed learning back to engineering: Record true-positive path, false-positive conditions, and missing telemetry for rule refinement.

This is the practical bridge between detection engineering and incident response.

Detection engineering workflows this enables

Mapping rules into attack flows creates a common planning unit for SOC and engineering teams.

1) Flow-scoped backlog management

Instead of a flat rule backlog, maintain work as:

• flow step
• expected telemetry
• current coverage state
• owner
• SLA based on attack-path criticality

This improves prioritization and makes coverage debt visible.

2) Rule quality measured by path impact

Measure rule quality beyond precision/recall in isolation.

Track whether a rule improves:

• earlier detection in the path
• confidence in current-step confirmation
• reduced time to investigate the next likely step

3) Content testing as sequence testing

Test detections as chains, not singles.

For key attack paths, validate:

• does each expected step have at least one viable detection?
• do detections fire in an order consistent with observed procedure variants?
• where do we lose visibility due to telemetry or enrichment gaps?

4) Threat intel to rule generation with context intact

When extracting detection ideas from CTI reports, preserve procedure sequence and attach generated rules to flow actions from day one.

That avoids the common failure mode where rules are created but lose procedural meaning.

In summary

If your goal is operational SOC support, the key requirement is not just detecting that “something bad happened.”

It is understanding where you are in the attack path, what likely happened before, what is likely next, and whether you have coverage to respond fast enough.

Linking Sigma rules to Attack Flow actions gives you exactly that.

It turns detections from isolated alerts into sequence-aware investigation guidance and turns coverage from a static matrix into a living, step-level engineering program.