Difference between registry values and registry keys in Sigma

[rfackroyd]

I have an issue which relates quite closely to this pull request.

Taking a look at the accepted Sigma rules, TargetObject is currently used to describe both the registry key and value together, with Details consistently referring to the data stored under a given registry value.

Taking a look at some rules, it seems like TargetObject|endswith is used to denote a registry value - example

However in other cases it is a combination of key and value - example

When converting Sigma to Carbon Black land this doesn't matter, as key and value are both queried under the same regmod_name identifier. Therefore, the Carbon Black backend can map TargetObject to regmod_name no problem.

However, Microsoft Defender for Endpoint (mdatp) does discern between the two, so when it receives a TargetObject, the backend does not know whether this is a registry value or a registry key.

I can see this has been addressed in the Microsoft DfE backend, I could use ObjectValueName to denote registry values, however these Sigma rules will now struggle to be converted to other syntaxes which do not acknowledge ObjectValueName as an applicable field for conversion in their respective configurations & backends. As referred to above, TargetObject|endswith is also used interchangeably, so it is not a suitable candidate to represent registry values.

Please let me know if I am missing something fundamental here, but I am struggling to see how to distinguish between registry values and keys in a way that works for multiple backends.

[frack113]

Hi,

• Sigma rule is universal and it is not written for a backend/SIEM
• Sigma rule use original field name from the event only (here sysmon)

Elastic beat split too some original fields so get the same trouble.

If sysmon X introduced something like TargetKey and TargetValue some day , Sigma rule will use it of course. if you open a petition at MS to have it , I sign it. 😄

[Neo23x0]

I guess that this could be handled in the new pySigma (CC @thomaspatzke) as soon as someone wrote a backend for MDATP

I'm not sure if field values can be split up into two field values.

[Neo23x0]

But I see the problem. It would probably be much better to have these values in two different fields, because merging is much easier than splitting.

[thomaspatzke]

I guess that this could be handled in the new pySigma (CC @thomaspatzke) as soon as someone wrote a backend for MDATP

I'm not sure if field values can be split up into two field values.

It will be possible based on regular expression patterns. Anyways,

But I see the problem. It would probably be much better to have these values in two different fields, because merging is much easier than splitting.

I think this is the cleaner option.

[rfackroyd]

Thanks guys.

Based on the above, I will stick to using TargetObject|endswith for registry values and then I am doing a .replace('RegistryKey endswith','RegistryValueName contains') in python post-sigmatools conversion.

This is obviously a hacky fix and means I must use TargetObject|contains even when looking for the end of a registry key, which is not performant, but it works for now.

This also means I can still use my rules with other sigmatools converters for now. As pySigma grows I will be looking to move to use that instead as you have mentioned to me that it is the next-gen

For the long term fix, using two different fields for registry key and value sounds good to me. You already have 'Details' for the registry value data so this seems like the final step

[Neo23x0]

Yes, someone would have to rework all the registry rules and check the backend support. 😬

[nasbench]

Closing this as answered/won't fix for now since the issue is a lot trickier to fix and it's out of our hands for the moment.

• As @Neo23x0 someone needs to go fix all reg rules (which is practically impossible) since the context is lost once you combine the reg value+key
• Also it makes it harder to write rules if the source doesn't do this by default (for example Sysmon. Which most people use to collect reg values). We all need to use for example EID 4657 who does this split in the event.
• To make it work we also need to use a non-default field name which is confusing and goes against the ethos of SIGMA which aims to make it as painless as possible to translate/write rules
• Finally, needs a big change to all backends here in SIGMA to support this.