Security Analytics: Windows rule (Moriya Rootkit) incorrectly generating Findings on Okta logs

[k_osugi]

Hello OpenSearch community,

We are running Amazon OpenSearch Service 3.1 with the Security Analytics plugin enabled.

We encountered a strange behavior related to Findings generation.

Issue

• A Sigma rule for Moriya Rootkit (Windows / EventID 7045 / Service Control Manager / ServiceName = ZzNetSvc) is defined.

• This rule should only match Windows Event Logs.

• However, we are seeing Findings generated against Okta authentication logs (ocsf-1-1-0-3002-okta index).

• These Findings appear in the Findings list, but no Alerts are raised.

Example of the Okta log found in Findings

{
  "class_name": "authentication_audit",
  "class_uid": 3002,
  "displaymessage": "User login to Okta",
  "dst_endpoint": {
    "hostname": "/api/v1/authn",
    "svc_name": "/api/v1/authn?"
  },
  "dst_user": "user@example.com",
  "metadata": {
    "original_time": "2025-09-29T09:53:26Z",
    "product": {
      "vendor_name": "okta",
      "name": "Okta System Log"
    }
  },
  "src_endpoint": {
    "hostname": "/api/v1/authn",
    "ip": "xxx.xxx.xxx.xxx"
  },
  "user": {
    "type": "User",
    "name": "User Name",
    "email_addr": "user@example.com"
  },
  "status": "FAILURE",
  "status_detail": "INVALID_CREDENTIALS",
  "logon_type": "WEB",
  "severity": "WARN"
}

As shown above, this Okta log does not contain any Windows-specific fields like Provider_Name, EventID, or ServiceName.

Still, it was marked as a Finding for the Moriya Rootkit rule.

Observations

• The Detector is configured to use Okta log type only.
• Rule YAML is strictly Windows-specific:

logsource:
  product: windows
detection:
  selection:
    Provider_Name: Service Control Manager
    EventID: 7045
    ServiceName: ZzNetSvc
  condition: selection

• There is no mapping override; the Okta log documents do not contain EventID or ServiceName.
• It looks like the rule condition is being dropped or mis-translated during the Sigma → DSL conversion, resulting in a “match_all” like query.
• As a result, Findings are created on unrelated Okta events.

Questions

1. Is this a known issue in Security Analytics (3.1) where unused fields in rules are dropped, causing false Findings?
2. Should Detector rules be automatically restricted by logsource, or is there extra configuration needed to enforce logType scoping?
3. Has anyone else observed Windows rules generating Findings on non-Windows indices (e.g., Okta)?

Environment

• Amazon OpenSearch Service 3.1
• Security Analytics plugin (bundled version with 3.1)
• Detector configured only for Okta logs
• Rule: Moriya Rootkit (experimental Sigma rule from Detection rules library)

Additional Observation: Tag inconsistency

We also noticed another odd behavior regarding tags:

• In the Rule definition view, the tags are shown as:

  attack.persistence
  attack.privilege_escalation
  attack.t1543.003

• However, in the Finding details view for the same rule, the tags are different:

  medium

  okta

  attack.impact

  attack.t1531

This inconsistency suggests that the rule metadata may be altered or incorrectly mapped when Findings are generated.

It might also explain why a Windows-only rule ends up being applied to Okta logs (tag mismatch / log type misclassification).

Thanks!

[Leeroy]

Hey @k_osugi ,

Is this something that worked before moving to 3.x? If so I suggest reporting your findings in an issue here - GitHub · Where software is built .

Leeroy.

[k_osugi]

Hi @Leeroy

No, I found that the same issue still occurs on version 2.19.