# Clarification on ETW keywords Field Representation and Human-Readable Conversion

**URL:** <https://discuss.elastic.co/t/clarification-on-etw-keywords-field-representation-and-human-readable-conversion/376736>\
**Category:** Beats\
**Tags:** filebeat\
**Created:** [April 3, 2025, 10:43am UTC](https://discuss.elastic.co/t/clarification-on-etw-keywords-field-representation-and-human-readable-conversion/376736 "2025-04-03T10:43:44Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![sikson](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/sikson/32/142425_2.png) [@sikson](https://discuss.elastic.co/u/sikson)\
**Post date:** [April 3, 2025, 10:43am UTC](https://discuss.elastic.co/t/clarification-on-etw-keywords-field-representation-and-human-readable-conversion/376736/1 "2025-04-03T10:43:45Z")

</div>

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:

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

```

### Desired Output:

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

```

Thanks for your time and insights!

---

<div class="post-metadata">

**Author:** ![chemamartinez](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/chemamartinez/32/124508_2.png) [@chemamartinez](https://discuss.elastic.co/u/chemamartinez)\
**Post date:** [April 7, 2025, 8:56am UTC](https://discuss.elastic.co/t/clarification-on-etw-keywords-field-representation-and-human-readable-conversion/376736/2 "2025-04-07T08:56:48Z")

</div>

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](https://github.com/elastic/beats/issues/43724)), 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](https://github.com/elastic/integrations/issues/13438)).

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](https://www.elastic.co/guide/en/integrations/current/microsoft_dnsserver.html), as a workaround, a [script processor](https://www.elastic.co/guide/en/elasticsearch/reference/current/script-processor.html) could be added to a [custom ingest pipeline](https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html) to keep the hex representation and map that bitmask to its human-readable keywords.