Clarification on ETW keywords Field Representation and Human-Readable Conversion

Hi!
I’m working with Filebeat (v8.15.3) to ingest Windows ETW events (provider.name: Microsoft-Windows-DNSServer) and noticed that the keywords field is represented as a large decimal integer (e.g., "keywords": "9223372036854775808"). In raw Windows XML events, the same value appears as a hexadecimal mask like <keywords>0x8000000000000000</keywords>, often mapped to human-readable names (e.g., QUERY_RECEIVED for DNS events).

Questions:

  1. Decimal vs. Hexadecimal:
    Why does Filebeat convert the keywords value to a decimal string instead of preserving the original hex format (0x...)? Is this intentional for compatibility reasons?
  2. Human-Readable Keywords:
    Is there a built-in way in Filebeat or Logstash to map these decimal/hex values back to their human-readable names (e.g., QUERY_RECEIVED)? For example:
    • Could Filebeat’s translate processor or a custom script resolve this using Microsoft’s official keyword masks?
    • Are there plans to add this as a feature?
  3. Workaround Suggestions:
    If this isn’t natively supported, would you recommend:
    • Using a Logstash filter (e.g., ruby or translate) to convert the decimal value to hex and then map it to keywords?
    • Modifying the Filebeat pipeline to retain the hex format?

Example Event Snippet:

"winlog": {
  "keywords": "9223372036854775808",  // Decimal representation of 0x8000000000000000
}

Desired Output:

"winlog": {
  "keywords": "QUERY_RECEIVED",  // Human-readable name
  "keywords_hex": "0x8000000000000000"  // Optional hex format
}

Thanks for your time and insights!

Hi @sikson,

I have opened a couple of public issues in the GH repos to fix the representation of the keywords field ([Filebeat] ETW input - Fix keywords fields representation in output events · Issue #43724 · elastic/beats · GitHub), and map the keywords to a human-readable format for the DNS Server integration ([Microsoft DNS Server] Map keywords output field to human-readable format · Issue #13438 · elastic/integrations · GitHub).

Regarding the human-readable keywords, this is something that should be added in the integration side instead of Filebeat as it depends on the specific mapping for each ETW provider.

If you are using the Microsoft DNS Server integration, as a workaround, a script processor could be added to a custom ingest pipeline to keep the hex representation and map that bitmask to its human-readable keywords.