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
- Identify the TTP: Pinpoint the specific adversary action (e.g., a PsExec execution).
- Write the Generic Sigma Rule (YAML): Define the core logic using generic log sources.
- Translate to KQL: Use the Sigma converter tool to generate the native Kibana Query Language (KQL).
- 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
.rhysidafile 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:
- Navigate to the Kibana Security Detection Engine.
- Click “Create new rule” and select “Custom query”.
- Paste the generated KQL into the query box.
- Set the Index Pattern to match your endpoint data (e.g.,
logs-endpoint.events-*). - 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.
You must be logged in to post a comment.