Windows event logs to detections ( sigma ) alerting with custom runtime field

[jmce123]

Version

2.4.190

Installation Method

Cloud image (Amazon, Azure, Google)

Description

other (please provide detail below)

Installation Type

Standalone

Location

cloud

Hardware Specs

Exceeds minimum requirements

CPU

16

RAM

128GB

Storage for /

1TB

Storage for /nsm

1TB

Network Traffic Collection

tap

Network Traffic Speeds

1Gbps to 10Gbps

Status

Yes, all services on all nodes are running OK

Salt Status

No, there are no failures

Logs

Yes, there are additional clues in /opt/so/log/ (please provide detail below)

Detail

I am trying to get a detection and alert for if a windows server's time change is greater than 5 minutes

Event 4616 logs time changes and I can get a simple alert working on just time change events.

I made a custom field that runs a script and compares the currentTime and PreviousTime in the event and outputs the field as time_changed_minutes and in kibana I can query against it and that runtime field works. kibana sees it as time_change_minutes

Now when I try to run a detection sigma event it fails and in the logs shows

{"_timestamp":"2025-12-09T03:43:51.286364Z","rule.name":"Windows System Time Change Greater Than 5 Minutes V2 -- 12345678-90ab-cdef-1234-567890abcdef","error_type":"runtime_status","error_message":"Error running query: RequestError(400, 'verification_exception', 'Found 1 problem\nline 1:96: Unknown column [winlog.event_data.time_change_minutes]')","detection_type":"sigma","event_module":"soc","event_dataset":"soc.detections","error_analysis":"Unknown"}

So sigma is looking for the field winlog.event_data.time_change_minutes, and I don't know how to point it to the field kibana is using.

And the sigma rule is:

title: Windows System Time Change Greater Than 5 Minutes V2
id: 12345678-90ab-cdef-1234-567890abcdef
status: stable
description: Detect Windows system time changes greater than 5 minutes (EventID 4616)
author: Your Name
date: 2025-12-08
references:
- https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4616
tags:
- attack.persistence
- attack.Temporal
logsource:
product: windows
service: system
index: .ds-logs-system.security-default-*
detection:
selection:
winlog.event_id: "4616" # compare as string to avoid type errors
time_change_threshold:
time_change_minutes: '>5' # numeric comparison: greater than 5
condition: selection and time_change_threshold
falsepositives:
- Legitimate NTP or admin-initiated changes (if expected)
level: high

If I was remove the parts about the runtime field, and just focus on the event 4616 it works without issue.

What is the proper way to set this up? I know I can change the ingestion pipeline to insert this value on ingestion. But then I have to reindex the index to update this.

I know I will continually be wanting to add more rules and alerts as I go so having to rewrite the ingestions pipeline rules every time I want to do a mutation against the logs does not seem like the best method.

What is the recommended approach to this?

Thanks community! I will make a detailed answer to this once I solve to to help the community should someone else find themselves in this situation.

Guidelines

• I have read the discussion guidelines at Read before posting! #1720 and assert that I have followed the guidelines.

[cm-ops]

What is your runtime field(s) you are created to search?

[jmce123]

runtime field(s): time_change_minutes

Works great in kibana and I can do KQL against the field.

In sigma I try to call is with the same:
detection:
selection:
winlog.event_id: "4616" # compare as string to avoid type errors
time_change_threshold:
time_change_minutes: '>5' # numeric comparison: greater than 5
condition: selection and time_change_threshold

But it errors and appears to be looking for winlog.event_data.time_change_minutes

[jmce123]

If I drop the runtime field and just have

detection:
selection:
winlog.event_id: "4616" # compare as string to avoid type errors
condition: selection

I get the alert just fine on all 4616 events.

[jmce123]

I will also point out I anticipate I will have to do this frequently as I tune to our environment. i.e. run a script against collected logs that in some way analyze the log and provide an output, and then need to alert on that output verses the raw log data captured.
So if there is a "best practices" way to do this in security onion I would prefer to start down that path now.

Thanks!

[jmce123]

I found that when I create a detection->sigma in the UI it will then write the file as below. I can then see in the file it translates my request for the runtime filed at the root time_change_minutes and translates to winlog.event_data.time_change_minutes. Why I don't know. How to stop this, I don't yet know either.

cat /opt/so/rules/elastalert/rules/12345678-90ab-cdef-1234-567890abc123.yml
detection_title: Windows System Time Change Greater Than 5 Minutes V1
detection_public_id: 12345678-90ab-cdef-1234-567890abc123
event.module: sigma
event.dataset: sigma.alert
event.severity: 4
sigma_level: high
alert:
- modules.so.securityonion-es.SecurityOnionESAlerter
- slack
- email
index: .ds-logs-*
name: Windows System Time Change Greater Than 5 Minutes V1 -- 12345678-90ab-cdef-1234-567890abc123
realert:
seconds: 0
type: any
filter:
- eql: any where winlog.channel:"Security" and (winlog.channel:"Security" and (winlog.event_data.time_change_minutes:"*" and winlog.event_data.time_change_minutes:">"))

[jmce123]

Apparently I am the only client asking SO how to manipulate ingested logs and alert ( via sigma ) on those manipulations.

Runtime fields attached to the index, would appear in KQL, but just did not work no matter how hard I tried to hack it for sigma. i.e. sigma is looking for the field in the wrong location, and I never could find how to adjust that.

Here is a solution!

I had to create a custom ingestion pipeline, and attach it to the agent policy "system-endpoints" and under the "Security channel" added the custom pipeline as a second pipeline. Then in the custom pipeline and a processor that run the same painless script I was using to create the runtime field. And now my sigma alerts can see the field when created this way!

Hope this saves someone else all the time I spent to get this working! I really appreciate everyone who provide feedback. Matt, thank you!