OpenSearch Security Analytics detector treats text fields as case-sensitive for contains matching – why and how to enable case-insensitive detection?

Versions (relevant - OpenSearch/Dashboard/Server OS/Browser):

Describe the issue:

I am trying to understand how OpenSearch Security Analytics detectors analyze incoming documents internally and match them against detection rules to generate findings, specifically around case sensitivity.

I created a detector on a custom index and added a Sigma-based detection rule that uses |contains on a field mapped as text. Based on my understanding of OpenSearch, text fields are analyzed and therefore should behave in a case-insensitive manner.

However, in practice, the detector only triggers when the value matches the exact case used in the rule. If the same logical value appears in a different case (for example, uppercase path segments), the detector does not create a finding.

This makes it look like Security Analytics detectors are treating text fields as case-sensitive for contains matching, which contradicts my understanding.

I want to clarify:

  1. Is this the expected behavior of OpenSearch Security Analytics detectors?
  2. How exactly does the detector evaluate documents internally when applying Sigma rules?
  3. Is there a supported way to make detectors perform case-insensitive matching at rule evaluation time, without modifying or normalizing the ingested data?

Configuration:

Index Mapping

I created an index with aliases for Sigma-style fields. The relevant mapping is shown below:

{
“EventId”: {
“type”: “alias”,
“path”: “eventName”
},
“EventType”: {
“type”: “alias”,
“path”: “log.attributes.EventType”
},
“Image”: {
“type”: “alias”,
“path”: “log.attributes.Image”
},
“TargetObject”: {
“type”: “alias”,
“path”: “log.attributes.TargetObject”
},
“log”: {
“properties”: {
“attributes”: {
“properties”: {
“EventType”: {
“type”: “keyword”
},
“Image”: {
“type”: “text”,
“fields”: {
“keyword”: {
“type”: “keyword”
}
}
},
“TargetObject”: {
“type”: “text”,
“fields”: {
“keyword”: {
“type”: “keyword”
}
}
}
}
}
}
}
}

TargetObject is intentionally mapped as a text field (with a keyword subfield) because I want case-insensitive behavior while preserving the original value for display.

Detection Rule:

id: 07bdd2f5-9c58-4f38-aec8-e101bb79ef8d
logsource:
product: xdr_windows
title: Terminal Server Client Connection History Cleared - Registry
description: Detects the deletion of registry keys containing the MSTSC connection history
level: high
status: test
detection:
selection1:
EventType: DeleteValue
TargetObject|contains: \Microsoft\Terminal Server Client\Default\MRU
selection2:
EventType: DeleteKey
TargetObject|contains: \Microsoft\Terminal Server Client\Servers
condition: 1 of selection*

I indexed the following document:

POST registry_delete_key/_doc
{
“traceId”: “31978fb5522c4e609d5e672aa8a6fa09”,
“eventName”: 40001,
“log.attributes.EventType”: “DeleteKey”,
“log.attributes.TargetObject”: “\REGISTRY\USER\MICROSOFT\TERMINAL SERVER CLIENT\SERVERS\Users”,
“log.attributes.Image”: “C:\Program Files\Microsoft Office\root\Office16\SDXHelper.exe”,
“time”: “2025-12-09T13:05:38.611Z”
}

This value logically matches the rule condition:

\Microsoft\Terminal Server Client\Servers\

but the detector does not trigger because the case differs (MICROSOFT, TERMINAL SERVER CLIENT, SERVERS).

If I index the same value using the exact same case as in the rule, the detector triggers correctly.

Expected vs Actual Behavior

Expected

Since TargetObject is a text field, |contains matching should be case-insensitive.The detector should generate a finding regardless of case differences.

Actual

The detector only matches when the case exactly matches the rule string.This makes text fields behave like case-sensitive fields for contains matching.

Questions:

  1. Is this case-sensitive behavior for text fields expected in OpenSearch Security Analytics detectors?
  2. How does the detector internally evaluate Sigma contains conditions against analyzed fields?
  3. Is there any supported way to make detectors perform case-insensitive matching at rule evaluation time, without:
    1. modifying ingested documents
    2. lowercasing values at ingest
    3. or switching to keyword fields with normalizers?

I want to preserve the original field values exactly as received (for customer visibility), while still allowing case-insensitive detection logic.