Transformations of decoded fields

[hitman28594]

Hello Team,

Is it possible to have some additional options for the normalization of decoded fields (related to the issue raised in #140).

Use cases:

• Changing usernames to upper/lowercase
• Removing white spaces from URL/filepath
• base64 encoding/decoding
• URL encoding/decoding
• hex encoding/decoding
• generating SHA or md5 hashes of a value
• DNS lookup to convert an IP to a hostname and vice versa.

Ideally these additional functions would work in a similar way to how modsecurity implements it’s transformation functions: https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-(v2.x)#Transformation_functions

Thank you for your continued support. :)

[davidjiglesias]

Hello @hitman28594,

That sounds like a great idea, I have moved the issue to Waiting R&D. Our team will study it for future versions.

Thank you for your contribution.

[hitman28594]

Hi, has anything been discussed about this?

I was thinking a separate phase in analysisd for “post-decoding”

As well as the use-cases originally described, this phase could also be used for:

• Normalising field names (field mappings)
• Tagging logsource types (like sigma)
• Field enrichment
• Field datatype (E.g. timestamp, IPv4, URL, sha256hash, email address). This functionality kind of exists when the sourceIP is decoded as (srcip) but we can’t do this for other field names or other field types such as timestamp or email.

Ideally, this additional phase in processing would allow us to normalise data in a very powerful way and can also enable wazuh fields to be mapped so they can be integrated into/with other solutions much more easily (E.g sigma and other open source threat intelligence).