Listen to this Post
Introduction:
Detection engineering is a critical cybersecurity discipline focused on identifying adversary activity through log analysis and alerting. The Sigma language provides a vendor-agnostic, open-source standard for writing detection rules that can be translated into numerous SIEM and EDR platforms. Moving from theoretical knowledge to practical, hands-on skill in writing effective Sigma rules is the key to building robust defensive capabilities.
Learning Objectives:
- Understand the core structure and syntax of a Sigma rule.
- Learn to convert raw log data into actionable detection logic.
- Develop proficiency in using the Sigma CLI to convert and validate rules across different platforms.
You Should Know:
1. Deconstructing Your First Sigma Rule
A Sigma rule is a YAML file that defines a detection pattern. Understanding its anatomy is the first step.
title: Suspicious PsExec Service Installation id: 98c9d8ea-4e74-4e75-8e75-7a15a15a15a1 status: test description: Detects the installation of a service using PsExec-like commands which is commonly used by adversaries for lateral movement. author: Kostas T. date: 2024/05/20 logsource: category: process_creation product: windows detection: selection: Image|endswith: '\psexesvc.exe' CommandLine|contains: ' -accepteula' condition: selection falsepositives: - Legitimate system administration using PsExec level: high
Step-by-step guide:
This rule targets Windows process creation logs. The `detection` section is the core: `selection` defines the criteria—a process image ending with `psexesvc.exe` and a command line containing the `-accepteula` flag. The `condition` states that if the selection is met, an alert should be triggered. This is a classic signature-based detection for a well-known tool.
- Converting Sigma Rules to Your SIEM with Sigma CLI
Sigma rules are not directly executed by SIEMs. They must be converted using the Sigma CLI tool.Install Sigma CLI and necessary converters (Python/pip required) pip install sigmatools Convert a Sigma rule to a Splunk SPL query sigma convert -t splunk ~/rules/suspicious_psexec.yml Convert a Sigma rule to an Elasticsearch Query DSL sigma convert -t es-qs ~/rules/suspicious_psexec.yml Convert an entire directory of rules for use in Azure Sentinel (KQL) sigma convert -t azure -r ~/rules/ -o ~/output/azure_rules/
Step-by-step guide:
The Sigma CLI (sigma convert) is the workhorse for making rules operational. The `-t` flag specifies the target backend (e.g., splunk, es-qs, azure). The `-r` flag recursively processes a directory, and `-o` defines the output directory. This allows a single, standardized rule to be deployed across a heterogeneous security tool environment.
3. Leveraging Field Mappings for Effective Detection
Different logging systems use different field names. Sigma’s field mapping is crucial for correct translation.
logsource: category: process_creation product: windows detection: selection: Image|endswith: '\whoami.exe' ParentImage|endswith: '\mshta.exe' condition: selection fields: - CommandLine - User
Step-by-step guide:
This rule detects `whoami.exe` being spawned by mshta.exe, a common script-based exploitation chain. The `Image` and `ParentImage` fields are abstract. The Sigma converter maps these to the correct fields in the target SIEM (e.g., `process_path` and `parent_process_path` in CrowdStrike, `NewProcessName` and `ParentImage` in Windows Security Event Logs). The `fields` section specifies additional data to include in the alert for context.
4. Hunting with Aggregation Conditions
Moving beyond single-event detections, Sigma allows for correlation across time using aggregation.
title: Multiple Failed Logons from a Single Source logsource: product: windows category: process_creation detection: selection: EventID: 4625 timeframe: 5m condition: selection | count() by SourceIpAddress > 10 fields: - SourceIpAddress - TargetUserName
Step-by-step guide:
This rule identifies brute-force attacks. The `selection` finds failed logon events (EventID 4625). The `timeframe` of 5 minutes and the `condition` using `count() by` groups these events by the source IP address and triggers only if the count exceeds 10. This demonstrates a more advanced, behavioral detection logic.
5. Validating and Testing Your Sigma Rules
Before deployment, rules must be validated for syntax and tested for logic.
Check the YAML syntax of all rules in a directory sigma check --v --relaxed ~/rules/ Test a specific rule against a sample log file to verify it triggers sigma test ~/rules/suspicious_psexec.yml ~/logs/attack_sample.evtx Use the Sigma plugin for YAML (e.g., in VSCode) for real-time syntax highlighting and validation.
Step-by-step guide:
The `sigma check` command is a linter that ensures your YAML is valid and the rule structure is correct. The `–relaxed` flag can bypass some strictness for development. The `sigma test` command is invaluable; it runs the rule against a provided log file to see if it correctly identifies the malicious activity, preventing false negatives in production.
6. Building a Detection-as-Code Pipeline
Integrate Sigma into a CI/CD pipeline for automated testing and deployment.
Example GitHub Actions workflow (.github/workflows/sigma-ci.yml) name: Sigma CI on: [push, pull_request] jobs: test-sigma: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - name: Set up Python uses: actions/setup-python@v4 with: python-version: '3.10' - name: Install Sigma run: pip install sigmatools - name: Validate Sigma Rules run: sigma check --v --fail-on-error --relaxed ./rules - name: Convert Rules to SIEM Formats run: | sigma convert -t splunk -r ./rules -o ./converted/splunk/ sigma convert -t es-qs -r ./rules -o ./converted/elasticsearch/
Step-by-step guide:
This GitHub Actions workflow automates the quality gate for your Sigma rules. On every push or pull request, it installs Sigma, validates all rules, and converts them to target SIEM formats. This ensures that only validated, syntactically correct rules are promoted to your detection repository, enforcing consistency and reliability.
7. Advanced Technique: Using Placeholders for Dynamic Values
For rules that require environment-specific values (like domain names), use placeholders to avoid hard-coding.
title: Suspicious Service Creation by Non-Admin logsource: category: process_creation product: windows detection: selection: Image: 'System' CommandLine|contains: 'create' CommandLine|contains: '%SUSPICIOUS_SERVICES%' filter: User|endswith: '%DOMAIN_ADMINS%' condition: selection and not filter
Step-by-step guide:
This rule uses `%SUSPICIOUS_SERVICES%` and `%DOMAIN_ADMINS%` as placeholders. When converting the rule with the Sigma CLI, you can provide a configuration file that maps these placeholders to actual values (e.g., SUSPICIOUS_SERVICES: badservice1.exe,badservice2.exe). This makes rules reusable across different organizational environments without modification.
What Undercode Say:
- The paradigm for detection engineering is shifting from platform-specific silos to open, portable standards like Sigma, which democratize advanced defensive techniques.
- True proficiency is not achieved by reading specifications but by iterative practice—writing, testing, and validating rules against realistic attack data in a safe environment.
The introduction of dedicated training platforms, as highlighted by Kostas T., is a direct response to the critical skills gap in applied detection engineering. While the theory of attack patterns is well-documented, the practical art of translating those patterns into precise, efficient, and low-noise detections has been a barrier. These platforms provide the essential “repetition” needed to build muscle memory. The future of SOC effectiveness hinges on this ability to rapidly develop and deploy high-quality detections, moving security operations from a reactive to a proactive and intelligence-driven stance.
Prediction:
The normalization of hands-on, gamified detection engineering training will lead to a significant rise in the overall maturity of organizational security postures within the next 2-3 years. As these skills become more widespread, we will see a corresponding evolution in adversarial tradecraft, with attackers developing new techniques specifically designed to evade these commonly deployed, standardized detection rules. This will create a new front in the cybersecurity arms race, centered on the quality and subtlety of detection logic rather than its mere presence.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Kostastsale Detectionstream – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
