Adding new RegistryPath, RegistryValue and RegistryData fields

[wietze]

Note: this PR is not ready for merging yet.

E.g. the following command:

tools/sigmac --target=sql --config sysmon rules/windows/registry_event/sysmon_comhijack_sdclt.yml

Generates:

SELECT * FROM eventlog WHERE (EventID IN ("12", "13", "14") AND TargetObject LIKE "HKCU\\Software\\Classes\\Folder\\shell\\open\\command" ESCAPE '\' AND TargetObject = "DelegateExecute")

which will never evaluate to true.

This problem is inherent to mapping two different keywords to the same field. Overrides don't seem able to fix the problem. I'll have a think about a solution.

[frack113]

Hello, For me this is not going in the right direction. You modify the rules to match your personal use of the sql backend. The rules have been corrected to match the actual field names in the logs. The logic is to use the mapping and options of the backend to convert. The sysmon schema for example

    <event name="SYSMON_REG_KEY" value="12" level="Informational" template="Registry object added or deleted" rulename="RegistryEvent" ruledefault="exclude" version="2">
      <data name="RuleName" inType="win:UnicodeString" outType="xs:string" />
      <data name="EventType" inType="win:UnicodeString" outType="xs:string" />
      <data name="UtcTime" inType="win:UnicodeString" outType="xs:string" />
      <data name="ProcessGuid" inType="win:GUID" />
      <data name="ProcessId" inType="win:UInt32" outType="win:PID" />
      <data name="Image" inType="win:UnicodeString" outType="xs:string" />
      <data name="TargetObject" inType="win:UnicodeString" outType="xs:string" />
    </event>
    <event name="SYSMON_REG_SETVALUE" value="13" level="Informational" template="Registry value set" rulename="RegistryEvent" ruledefault="exclude" version="2">
      <data name="RuleName" inType="win:UnicodeString" outType="xs:string" />
      <data name="EventType" inType="win:UnicodeString" outType="xs:string" />
      <data name="UtcTime" inType="win:UnicodeString" outType="xs:string" />
      <data name="ProcessGuid" inType="win:GUID" />
      <data name="ProcessId" inType="win:UInt32" outType="win:PID" />
      <data name="Image" inType="win:UnicodeString" outType="xs:string" />
      <data name="TargetObject" inType="win:UnicodeString" outType="xs:string" />
      <data name="Details" inType="win:UnicodeString" outType="xs:string" />
    </event>
    <event name="SYSMON_REG_NAME" value="14" level="Informational" template="Registry object renamed" rulename="RegistryEvent" ruledefault="exclude" version="2">
      <data name="RuleName" inType="win:UnicodeString" outType="xs:string" />
      <data name="EventType" inType="win:UnicodeString" outType="xs:string" />
      <data name="UtcTime" inType="win:UnicodeString" outType="xs:string" />
      <data name="ProcessGuid" inType="win:GUID" />
      <data name="ProcessId" inType="win:UInt32" outType="win:PID" />
      <data name="Image" inType="win:UnicodeString" outType="xs:string" />
      <data name="TargetObject" inType="win:UnicodeString" outType="xs:string" />
      <data name="NewName" inType="win:UnicodeString" outType="xs:string" />
    </event>

[wietze]

Hi @frack113 ,

Thanks for your message. You're right that for Eventlog/Sysmon-based targets, there is a single field for both registry key and value. A lot of (most?) other technologies however split these into two separate fields, distinguishing between them. (the SQL example in my PR was just a simple example to demonstrate a current problem, not the actual technology i'd like to use this for 😉)

I have tried to fix this in the backend of the technology itself, like you suggested, but this proved to be difficult as it causes new issues. For example, if the Sigma rule is:

detection:
  selection:
    TargetObject|contains: 'some\registry\path'
  condition: selection

, you wouldn't have enough information to establish whether path is supposed to be a registry key or value. Therefore, the translated rule may be either something like: registry_key contains 'some\registry' and registry_value contains 'path' or registry_key contains 'some\registry\path'. This gets complex very quickly when the rule contains multiple conditions. Without making this distinction in the Sigma rule itself, translated rules are either incorrect/incomplete or get really messy if you want to account for the different scenarios.

A couple of examples of such ambiguous rules: 1 2 3 4 5

As such, my proposal is to specify in the Sigma rule whether the logic relates to registry key or value, and for backends that use a single field for both (like Sysmon) to simply map them to the same field. As an extra benefit, I think the raw Sigma rules get more readable.

I hope that made sense - I'm open to feedback/suggestions.

[frack113]

Hi, I works with nxlog and winlogbeat , so I know the problem. nxlog keep the original field when winlogbeat transform and remove data... But this can not be a PR because this break the detection as the backend don't manage it. It is a issue to upgrade the way sigma works. rules/windows/other/win_defender_disabled.yml

        EventType: 'SetValue'
        TargetObject: 'HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\DisableAntiSpyware'
        Details: 'DWORD (0x00000001)'

evenType : winlog.event_data.EventType TargetObject: registry.path Details : winlog.event_data.Details detection works

become:

        RegistryKey: 'HKLM\SOFTWARE\Policies\Microsoft\Windows Defender'
        RegistryValue: 'DisableAntiSpyware'
        RegistryData: 1

How do you map ?

[wagga40]

Hi,

The logic is to use the mapping and options of the backend to convert.

I really agree with @frack113 this is not the way Sigma was intended to work.

Before correcting/adapting the rules, may be you can write a Sigma modification proposal but not specifically related to registry events ?

[wietze]

Just to reiterate, my proposal is not to remove/reduce functionality - all existing rules would still work with Sysmon and related targets. e.g. Sigma YAML files referencing RegistryKey would generate a TargetObject output for Sysmon.

In this Pull Request I also made changes to the backends to ensure nothing breaks - you may have missed it as it is buried under the rule changes.

[wagga40]

Before correcting/adapting the rules, may be you can write a Sigma modification proposal but not specifically related to registry events ?

@wietze reading again the thread and your last post, I think I went a little bit overboard on this one 😅 sorry.

But :

In this Pull Request I also made changes to the backends to ensure nothing breaks - you may have missed it as it is buried under the rule changes.

Indeed, I missed the changes to config files (and not to backends). But I think there will be some "surprises" because :

• people that use their custom config files will have to be informed of the change and adapt their config files
• some backends have no config files available in this repo

[frack113]

Hi, I we go this way , I think the name shoud use a prexif like logical_RegistryKey . When we read the rule it must be easy to see it is not a original field name. There is the trouble with user field witch is split to 2 fields "domain" and "user" by modern SIEM. So some rules example are invalid because of this functioning

[Neo23x0]

I wouldn't change all the rules and the field values. I would solve this kind of issue in the respective backends.

E.g. if the current value TargetObject contains the RegistryKey and RegistryValue, which are needed separately in one or two of the backends, I would split the value in the backend code and generate the two separate values.

[frack113]

Before make the change , We must have a discution in https://github.com/SigmaHQ/sigma-specification for the V2 . You can open one V2 proposal new RegistryPath, RegistryValue and RegistryData fields Thanks