Sigma → Wazuh/OpenSearch

The Conversion Problem

You have a Sigma rule in YAML. Your SIEM speaks a different language — Wazuh uses OpenSearch queries, Splunk uses SPL, Elastic uses KQL or Lucene, and Microsoft Sentinel uses KQL. The rule you wrote in Lesson 8.3 cannot be pasted into any of these SIEMs directly. It must be converted.

This is where sigma-cli comes in — the official command-line tool that transforms Sigma YAML into SIEM-specific queries. In your lab environment, sigma-cli is pre-installed with all the backends you need.

How Sigma Conversion Works

The conversion process has three components:

Click to enlarge

The basic command:

sigma convert -t opensearch -p windows rule.yml

Converting the PowerShell Detection Rule

Let's convert the suspicious PowerShell encoded command rule from Lesson 8.3. Here is the Sigma rule:

title: Suspicious PowerShell Encoded Command
logsource:
    category: process_creation
    product: windows
detection:
    selection_process:
        Image|endswith: '\\powershell.exe'
    selection_args:
        CommandLine|contains:
            - '-EncodedCommand'
            - '-enc'
    condition: selection_process and selection_args
level: high

Converting to OpenSearch (Wazuh)

sigma convert -t opensearch -p windows suspicious_powershell.yml

Output:

(process.executable.text:*\\powershell.exe) AND
(process.command_line.text:*\-EncodedCommand* OR
 process.command_line.text:*\-enc*)

Notice what happened:

Converting to Splunk

sigma convert -t splunk -p sysmon suspicious_powershell.yml

Output:

source="WinEventLog:Microsoft-Windows-Sysmon/Operational"
Image="*\\powershell.exe"
(CommandLine="*-EncodedCommand*" OR CommandLine="*-enc*")

Converting to Elastic

sigma convert -t elasticsearch -p ecs_windows suspicious_powershell.yml

Output:

{
  "bool": {
    "must": [
      { "wildcard": { "process.executable": "*\\\\powershell.exe" } },
      { "bool": {
          "should": [
            { "wildcard": { "process.command_line": "*-EncodedCommand*" } },
            { "wildcard": { "process.command_line": "*-enc*" } }
          ]
        }
      }
    ]
  }
}

Available Backends and Pipelines

Common Backends

Common Pipelines

List all available backends:

sigma list targets

List pipelines for a specific backend:

sigma list pipelines -t opensearch

Deploying to Wazuh

Converting a rule gives you a query. Deploying it to Wazuh means creating a custom alert that uses that query. Here is the end-to-end process:

Step 1: Convert the Rule

sigma convert -t opensearch -p windows suspicious_powershell.yml

Step 2: Create a Wazuh Alert Monitor

In the Wazuh dashboard (OpenSearch Dashboards):

1. Navigate to Alerting → Monitors → Create Monitor
2. Set the monitor name (e.g., "Sigma — Suspicious PowerShell Encoded Command")
3. Choose Extraction query as the monitor type
4. Paste the converted OpenSearch query
5. Set the schedule (e.g., every 1 minute)
6. Configure the trigger: if results > 0, fire the alert
7. Set the action: log the alert, send notification, or both

Step 3: Test the Detection

Generate a matching event and verify the alert fires. In Lab 8.3, you will trigger a simulated PowerShell encoded command event in the Wazuh environment and confirm your converted rule catches it.

Troubleshooting Conversion Failures

Not every Sigma rule converts cleanly. Here are the most common issues and how to fix them:

Unmapped Fields

sigma convert -t opensearch -p windows rule.yml
Error: Field 'TargetObject' is not mapped in the pipeline

Cause: The pipeline does not have a mapping for the Sigma field name to the target SIEM field name.

Fix: Check the pipeline documentation. You may need a different pipeline (sysmon instead of windows) or add a custom field mapping:

sigma convert -t opensearch -p windows -p custom_mappings.yml rule.yml

Unsupported Logsource

Error: No backend mapping for logsource category 'dns_query' product 'windows'

Cause: The selected backend does not know how to map this logsource combination to a concrete log index.

Fix: Check if the logsource requires a specific pipeline or if the backend supports it at all. Some logsource categories are backend-specific.

Aggregation Not Supported

condition: selection | count(IpAddress) > 5

Cause: Not all backends support Sigma's aggregation syntax (count, sum, min, max, avg).

Fix: Convert the base detection without aggregation. Configure the threshold in the SIEM's alerting system after deployment (Step 2 above).

Near-Time Correlation

condition: selection | near selection2

Cause: Sigma's near operator (temporal proximity) has limited backend support.

Fix: Convert the individual selections separately and use the SIEM's correlation engine to link them.

Click to enlarge

Batch Conversion

In Lab 8.6, you will convert multiple rules at once. Sigma-cli supports directory-level conversion:

# Convert all rules in a directory
sigma convert -t opensearch -p windows /opt/sigma-rules/rules/windows/process_creation/

# Convert and save to file
sigma convert -t opensearch -p windows rules/ > converted_rules.ndjson

# Convert with specific output format
sigma convert -t opensearch -p windows --output-format json rules/

Key Takeaways

• sigma convert -t <backend> -p <pipeline> rule.yml transforms Sigma YAML into SIEM-specific queries
• The backend determines the output format (OpenSearch, Splunk, Elastic, etc.)
• The pipeline maps Sigma's abstract field names to the target SIEM's concrete field names
• The same Sigma rule produces different output for each SIEM — this is the portability Sigma provides
• Deploying to Wazuh means creating an OpenSearch alert monitor with the converted query
• Common conversion failures include unmapped fields, unsupported logsource categories, and aggregation/correlation features
• Batch conversion allows deploying dozens or hundreds of rules at once from the SigmaHQ repository
• Some detections are better written as native Wazuh XML rules rather than converted from Sigma

What's Next

You can convert rules and deploy them. But deploying is just the beginning — every rule generates noise. In Lesson 8.5, you will learn the art of tuning: taking a noisy rule that fires 200 times a day and reducing it to fewer than 5 alerts without missing real threats. Lab 8.5 gives you a pre-deployed noisy rule to fix.