keyless identifiers cannot be converted

[nbareil]

Hello there!

First time user of chainsaw, it has a tremendous potential! 🚀

I was trying to use it with the current version of Sigma and I've got 93 errors (out of >2400 rules so gg) at the lint step for "keyless identifiers cannot be converted".

Here is a minimalist example of such behaviour:

$ cat windows/sysmon/sysmon_config_modification_status.yml
title: Sysmon Configuration Modification
id: 1f2b5353-573f-4880-8e33-7d04dcf97744
status: test
description: Detects when an attacker tries to hide from Sysmon by disabling or stopping it
references:
    - https://github.com/redcanaryco/atomic-red-team/blob/f339e7da7d05f6057fdfcdd3742bfcf365fee2a9/atomics/T1562.001/T1562.001.md
    - https://talesfrominfosec.blogspot.com/2017/12/killing-sysmon-silently.html
author: frack113
date: 2021/06/04
modified: 2022/08/02
tags:
    - attack.defense_evasion
    - attack.t1564
logsource:
    product: windows
    category: sysmon_status
detection:
    selection_stop:
        State: Stopped
    selection_conf:
        - 'Sysmon config state changed'
    filter:
        State: Started
    condition: 1 of selection_* and not filter
falsepositives:
    - Legitimate administrative action
level: high
$ /tmp/chainsaw/chainsaw --no-banner lint --kind sigma  windows/sysmon/sysmon_config_modification_status.yml
[+] Validating as sigma for supplied detection rules...
[!] : keyless identifiers cannot be converted
[+] Validated 0 detection rules out of 1

If I remove selection_conf part, it works:

$ cat windows/sysmon/sysmon_config_modification_status.yml
title: Sysmon Configuration Modification
id: 1f2b5353-573f-4880-8e33-7d04dcf97744
status: test
description: Detects when an attacker tries to hide from Sysmon by disabling or stopping it
references:
    - https://github.com/redcanaryco/atomic-red-team/blob/f339e7da7d05f6057fdfcdd3742bfcf365fee2a9/atomics/T1562.001/T1562.001.md
    - https://talesfrominfosec.blogspot.com/2017/12/killing-sysmon-silently.html
author: frack113
date: 2021/06/04
modified: 2022/08/02
tags:
    - attack.defense_evasion
    - attack.t1564
logsource:
    product: windows
    category: sysmon_status
detection:
    selection_stop:
        State: Stopped
    filter:
        State: Started
    condition: 1 of selection_* and not filter
falsepositives:
    - Legitimate administrative action
level: high
$ /tmp/chainsaw/chainsaw --no-banner lint --kind sigma  windows/sysmon/sysmon_config_modification_status.yml
[+] Validating as sigma for supplied detection rules...
[+] Validated 1 detection rules out of 1

I wish I could help but I have zero knowledge in Rust:

https://github.com/WithSecureLabs/chainsaw/blob/6aa5ae5a39e14c2b47e21e71ff4f2c79a33075f4/src/rule/sigma.rs#L489

[alexkornitzer]

Hi @nbareil,

So unfortunately not all the Sigma rules are written that well. The reason that Chainsaw won't parse this one into a Tau compatible format is because selection_conf does not specify a field to search upon for the string Sysmon config state changed.

If its intended behaviour for this rule to run upon all key value pairs within an event log entry then we can add support for that (it will be slow though) but I don't think that is what this rule is meant to do.

Let me know what you think.

[nbareil]

Thanks for your fast answer Alex!

I know almost nothing about Sigma but from its specifications, this construction looks to be allowed by the language:

2.9.4. Lists Lists can contain:

• strings that are applied to the full log message and are linked with a logical 'OR'.
• maps (see below). All map items of a list are logically linked with 'OR'.

Example for list of strings: Matches on 'EvilService' or 'svchost.exe -n evil'

detection:
  keywords:
    - EVILSERVICE
    - svchost.exe -n evil

Source: https://github.com/SigmaHQ/sigma-specification/blob/4b24c52e9e5edb8bcca688a82d0691bcde0b848f/version_1_x_0.md#294-lists

Now, as said, there are only 93 out of 2400 rules in SigmaHQ that do not parse, I don't think it is a big deal and I do not have any opinion if you should implement it or not, if you feel this change is more problematic than helpful, feel free to close this issue with WONTFIX 🤗

Kind regards

[alexkornitzer]

Exaclty, its allowed in their spec but its allows for inefficient rules to be written. It is basically saying look for those values anywhere in the entry (full log message). When we are processing structured data (like event logs, json, xml, etc) the concept of a full log message does not really make sense, the author must has fields in mind they would like to match. I would argue that its lazy rule writing to not specify the fields that would would like to search on.

Thanks for your understanding, I will mark as won't fix unless a burning desire arises to need this feature.

Oh and the other ones that can't convert are usually using thinks like inefficient regex which Rust does not support. I will have another look again when I get time to see if I can easily get any of the final 93 in.