Proposal: Registry Rule Field Separation

[Siopy]

Context

I am currently working on converting Sigma rules into multiple EDR technologies, such as CrowdStrike, Cortex XDR, and Microsoft Defender.

I have encountered an issue with the way Sigma handles registry rules: it only uses two properties:

• TargetObject (path + key name)
• Details (key value)

In most EDRs, these are separated into three distinct properties to clearly differentiate between the registry path and the key name.

---

Problem

This design in Sigma causes problems when converting queries for EDR backends, as it produces incorrect and unusable queries.

Example from the Sigma repository:
https://github.com/SigmaHQ/sigma/blob/master/rules/windows/registry/registry_set/registry_set_dbgmanageddebugger_persistence.yml

TargetObject|endswith: '\Microsoft\.NETFramework\DbgManagedDebugger'

Here, the path:

\Microsoft\.NetFramework\

and the key name:

DbgManagedDebugger

are merged together, which results in an incorrect query in an EDR (example with Cortex XDR):

action_registry_key_name contains "\Microsoft\.NETFramework\DbgManagedDebugger"

This is incorrect.
In Cortex XDR, registry data is separated as follows:

• action_registry_key_name → \Microsoft\.NETFramework\
• action_registry_value_name → DbgManagedDebugger
• action_registry_data → key value, e.g. "cmd.exe /c ipconfig"

Same logic for other EDRs:

CrowdStrike

• RegObjectName → \Microsoft\.NETFramework\
• RegValueName → DbgManagedDebugger
• RegStringValue → key value

Microsoft Defender

• RegistryKey → \Microsoft\.NETFramework\
• RegistryValueName → DbgManagedDebugger
• RegistryValueData → key value

---

Cause

The limitation comes from Sigma merging the path and the key name into a single property, while EDRs treat them as two separate fields.

---

Proposal

Sigma rules should explicitly separate registry information into three properties:

• TargetPath – the registry path
• TargetObject – the registry key name
• Details – the value contained in the key

I understand that this would deviate from the Sysmon-based field definitions that Sigma historically follows.
However, the current approach severely limits Sigma’s applicability in real-world production scenarios on EDR platforms.

[nasbench]

This issue was discussed a couple of times and its tricky to solve.

See SigmaHQ/sigma#3116 and SigmaHQ/sigma#1820

[Siopy]

Indeed, I apologize ! I didn’t check the previous discussions on this topic

I’m aware of the impact, but I think it would be necessary to include it as a breaking change in the next versions. Currently, Sigma does not correctly handle registry rule conversion, and therefore loses its usefulness in this case