Part 2: From Threat Intel to Alert – Deploying Sigma Rules in an Elastic SOC

This final installment provides the practical, step-by-step guide on how to integrate Sigma into an Elastic Security Operations Center (SOC) workflow, using a relevant and recent threat, Rhysida Ransomware, as a concrete example.

---

The first part of this series established Sigma as the universal language of threat detection, designed to overcome vendor lock-in. Now, it’s time to put that theory into practice.

This guide focuses on implementing a complete Detection as Code (DaC) workflow within an Elastic Security environment, transforming raw threat intelligence into functional, high-fidelity alerts using the power of Sigma.

1. The Elastic Integration Workflow: Bridging Schema Gaps

The fundamental challenge in deploying any detection rule is ensuring the query fields match your ingested data. For Elastic, this means aligning the Sigma rule’s expected fields with the Elastic Common Schema (ECS).

The Four-Step Implementation Process

1. Identify the TTP: Pinpoint the specific adversary action (e.g., a PsExec execution).
2. Write the Generic Sigma Rule (YAML): Define the core logic using generic log sources.
3. Translate to KQL: Use the Sigma converter tool to generate the native Kibana Query Language (KQL).
4. Deploy and Validate: Configure the KQL as an Elastic Security Detection Rule in Kibana.

2. Case Study: Detecting Rhysida Ransomware Activity

To demonstrate Sigma’s agility, we are using the Rhysida Ransomware group as our case study. According to recent threat reports, Rhysida frequently relies on legitimate, but abused, system tools for lateral movement.

We will focus on two critical, actionable TTPs mentioned in the Barracuda report:

• TTP 1 (Lateral Movement): Use of PsExec to execute the ransomware binary remotely. (MITRE ATT&CK: T1570).
• TTP 2 (Impact): Creation of files with the distinctive .rhysida file extension. (MITRE ATT&CK: T1486).

---

3. Practical Implementation: PsExec Detection via Sigma

Our goal is to write a rule that detects the specific process creation events associated with PsExec deploying a payload—a common precursor to encryption.

Step 3A: The Sigma Rule (YAML)

This generic Sigma rule defines the logic to detect the creation of the PSEXESVC.exe service, a key artifact of PsExec remote execution:

YAML

title: Rhysida PsExec Remote Payload Execution
logsource:
  product: windows
  category: process_creation
  service: sysmon # Assumes Sysmon or similar EDR data collection
detection:
  selection:
    # PsExec's key artifact is the creation of the PSEXESVC service
    ParentImage|endswith: '\services.exe'
    Image|endswith: '\PSEXESVC.exe'
  condition: selection
level: high
tags:
  - attack.execution
  - attack.t1570 # Lateral Tool Transfer

Step 3B: Translation to KQL

When the above YAML is fed into a Sigma converter tool (configured for the elasticsearch-kibana backend), the output is the required KQL:

Code snippet

(process.parent.executable: "services.exe" AND process.executable: "PSEXESVC.exe")

Note: The converter automatically maps ParentImage and Image to the correct ECS fields (process.parent.executable and process.executable) based on the logsource definition.

Step 3C: Deployment in Elastic Security

Once you have the KQL, deployment is straightforward:

1. Navigate to the Kibana Security Detection Engine.
2. Click “Create new rule” and select “Custom query”.
3. Paste the generated KQL into the query box.
4. Set the Index Pattern to match your endpoint data (e.g., logs-endpoint.events-*).
5. Configure the Risk Score and Severity (matching the Sigma rule’s level: high).

---

4. Advanced Rule: Detecting File Artifacts (The Kill Switch)

A crucial companion rule detects the final impact—the creation of the encrypted files. This rule is often considered “critical” because it signals active impact.

Rhysida File Extension Sigma Rule

YAML

title: Rhysida Ransomware File Extension Impact
logsource:
  product: windows
  category: file_event # Requires File System Monitoring
detection:
  selection:
    # Detects the creation or modification of files with the unique ransom extension
    TargetFilename|endswith: '.rhysida'
  condition: selection
level: critical
tags:
  - attack.impact
  - attack.t1486 # Data Encrypted for Impact

The corresponding KQL would be: (file.path: "*.rhysida") (assuming proper ECS mapping for file paths).

Conclusion: Achieving Detection Agility

By leveraging Sigma, your SOC is no longer beholden to vendor syntax. You can consume high-fidelity threat intelligence—like the TTPs used by Rhysida—and transform it into production-ready detection rules in your Elastic environment with unprecedented speed. This agility not only closes detection gaps faster but transforms your engineering team from query translators into strategic threat hunters.

Did you miss Part 1? Go back and read “Sigma – The Universal Language of Threat Detection,” where we cover the history, structure, and strategic benefits of this essential detection format.