System Integration Sets "@timestamp" to Ingest Time, Not Time of Event Occurring

[benferson]

Version

2.4.150

Installation Method

Security Onion ISO image

Description

other (please provide detail below)

Installation Type

Distributed

Location

airgap

Hardware Specs

Exceeds minimum requirements

CPU

24

RAM

64GB

Storage for /

300GB

Storage for /nsm

700GB

Network Traffic Collection

span port

Network Traffic Speeds

1Gbps to 10Gbps

Status

Yes, all services on all nodes are running OK

Salt Status

No, there are no failures

Logs

No, there are no additional clues

Detail

Hello, my team is having an issue with data ingestion while using Elastic Agent and the System integration. The target endpoints are largely Windows 10. The issue is that the "@timestamp" field is getting overwritten with the time the event was ingested. This makes it hard to search the data. In the past (SO v2.4.10), this field contained the timestamp when the event occurred on the host. Before, we would deploy an agent to a host and historical events would be placed into the index with an accurate timeline. Now, months of historical events all get timestomped and appear to have occurred in about a ten-minute window after the agent installation.

We're not clear why this is happening, but our research indicates a fallback timestamp processor in the global@custom ingest pipeline (which copies the event.created timestamp to @timestamp) is always running. The logs-system.security-* pipelines which come with the integration contain a processor to write the "winlog.time_created" field to @timestamp, but that is not successful for some reason. The "winlog.time_created" field does seem to be in the data stream mapping.

A potential workaround is to delete this processor from the global@custom pipeline, but this could have unintended consequences, and we'd prefer an actual fix.
{ "date": { "if": "ctx.event?.module == 'system'", "field": "event.created", "target_field": "@timestamp","ignore_failure": true, "formats": ["yyyy-MM-dd'T'HH:mm:ss.SSSX","yyyy-MM-dd'T'HH:mm:ss.SSSSSS'Z'"] } }

Integration/SecOnion versions where we can replicate the issue:
System integration where it works: 1.34.0
System integration versions where it doesn't work as expected: 1.59.0, 1.62.1, and 2.0.1
SO version that works: 2.4.10
SO versions that don't work as expected: 2.4.110, 2.4.141, and 2.4.150

If anyone has some knowledge about why this behavior changed, or a stable fix, we would be very happy to hear about it :)

Guidelines

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

[reyesj2]

The logs-system.security-* pipelines which come with the integration contain a processor to write the "winlog.time_created" field to @timestamp, but that is not successful for some reason.

Would you be able to share an event that resulted in this failure?

[benferson]

The testing environment I was using to work this issue got wiped; I apologize for the delayed response. I'm working on standing up another small lab to provide a sample from

[Jacob-gr]

I have also experienced issues with this global@custom pipeline, specifically this processor:

{ "date":       { "if": "ctx.event?.module == 'system'", "field": "event.created", "target_field": "@timestamp","ignore_failure": true, "formats": ["yyyy-MM-dd'T'HH:mm:ss.SSSX","yyyy-MM-dd'T'HH:mm:ss.SSSSSS'Z'"] } }

From my understanding, global@custom runs toward the end of the pipelines. This processor appears to affect any document coming in through the system integration. This processor will take the event.created field of the document and use that to set/overwrite the @timestamp field of the document (regardless of if the field is set).

From what I have observed and after double checking the event.created ECS documentation, this field is usually the time when the event was read by an agent or the pipeline, and not when the event was originally created on the system.

I was testing this by ingesting some logs into SO 2.4.150 from a Windows endpoint and looking at log-in events. All the documents had a @timestamp at roughly the same, and at the current time, because the @timestamp was being overwritten by event.created. This was the time when when the agent/pipeline was parsing the information and not the original time of the event (Image A).

When I removed that processor and re-ingested the logs, I saw the expected timestamps (@timestamp set to the time of the event itself) and historic events (Image B).

Image A: Ingested with processor:

Image B: Ingested without processor:

This issue would not be very obvious for new logs on a system being ingested into Elastic, but when you initially ingest documents and look for historic events, it becomes apparent.

[reyesj2]

Looking to get an example of a raw system log that is coming in and going through the system integrations unmodified ingest pipelines having a failure to set the timestamp field

This is related to #12814 & #11352

[Jacob-gr]

Sorry for the delayed response, I spent some time experimenting with the issue and learning how to get the raw logs being sent to logstash. A raw XML log can be found in the event.original field in the example document under the Troubleshooting section of this comment. The example document itself is what Elastic Agent is sending to logstash.

Observation and possible root cause

It looks like this issue has occured since version 2.4.70. I confirmed that 2.4.60 worked as expected, and then it was not working correctly in 2.4.70. The problem may have been accidently introduced as a result of #12881, which modified .fleet_final_pipeline_1:

-  { "date":       { "if": "ctx.event?.module == 'system'", "field": "event.created", "target_field": "@timestamp", "formats": ["yyyy-MM-dd'T'HH:mm:ss.SSSX"] } },Add commentMore actions


+  { "date":       { "if": "ctx.event?.module == 'system'", "field": "event.created", "target_field": "@timestamp","ignore_failure": true, "formats": ["yyyy-MM-dd'T'HH:mm:ss.SSSX","yyyy-MM-dd'T'HH:mm:ss.SSSSSS'Z'"] } },

It appears as though the newly added format check matches the format sent by filebeat in the event.created field (example: 2025-05-29T23:12:20.179Z), which causes the copy to @timestamp to then be applied. This overwrites the existing @timestamp field populated by filebeat when the original event is sent.

It appears as though this date processor was initially introduced for some issue related to so-import-evtx. The raw evtx logs use a more refined timestamp (example pulled from random log in Event Viewer: 2024-11-28T22:43:40.5630912Z), which did not match the format used by beats. However, once the processor was updated with the new format, it started matching and overwriting timestamps sent by Elastic Agent.

Therefore, it seems removing this processor completely could cause problems so-import-evtx. However, I have not experimented with this utility, so I'm not sure.

(EDIT: I did end up playing around with the so-import-evtx utility. When the date processor is removed, I observed that while all documents sent by Agents now have the correct @timstamp applied, all documents ingested by so-import-evtx had incorrect timestamps (they appeared to be the time of ingest). So, it does appear removing the processor may break the so-import-evtx utility.)

(Another EDIT: I somehow got a messed up evtx export that was only a recent subset of the entire log. Explains my odd results. Layer 8 issue as opposed to anything with the pipelines/processor)

Possible Solution

(EDIT: See me next comment for a better solution)

I recognize Security Onion is a complex system, and so I'm not sure what a good fix action would be. Some ideas I could think up:

• add an exculsion to the process: ctx.agent?.type != 'filebeat' or something similar. However, I'm not sure if so-import-evtx uses an agent to ship the logs to logstash
• add a check to only use event.created if @timestamp is null/not defined
• add a new logstash tag for logs ingested via so-import-evtx and perform some additional date parsing or timestamp checks only on documents that match that tag.

Troubleshooting

For transparency and awareness (and primarily for my own notes), I have included steps and experiments I took when exploring the problem. This also includes an example of the raw Windows log.

I am running a 2.4.150 Standalone Node with a modified System integration in the endpoints-initial policy (Preserve origin event turned on and "Ignore events older than" field cleared out)

1. Use Dev Tools to clear out any logs for my gwin test host:

   POST logs-*/_delete_by_query
   {
     "query": {
       "term": {
         "host.hostname": {
           "value": "gwin"
         }
       }
     }
   }

2. Copied the elastic agent logstash output from default to local:

   cp /opt/so/saltstack/default/salt/logstash/pipelines/config/so/9805_output_elastic_agent.conf.jinja /opt/so/saltstack/local/salt/logstash/pipelines/config/so/9805_output_elastic_agent.conf.jinja

3. Opened the local elastic agent logstash output:

   vim /opt/so/saltstack/local/salt/logstash/pipelines/config/so/9805_output_elastic_agent.conf.jinja

4. Added a file output to the top of the logstash pipeline to dump all raw json events to a local file. (The path is relative to inside the so-logstash container. It will be in /nsm/logstash/logstash-output.json on the manager.)

   output {
   
   file {
       path   => "/usr/share/logstash/data/logstash-output.json"
       codec  => "json_lines"
   }
   
   if "elastic-agent" in [tags] and "so-ip-mappings" in [tags] {
       elasticsearch {
       hosts => "{{ GLOBALS.hostname }}"
       data_stream => false
       ...
   

5. Apply the new state with salt-call state.apply logstash. (Cancel current jobs if highstate is running and rerun: salt '*' saltutil.kill_all_jobs)

6. Installed an Agent on a Windows 11 box with hostname gwin at 2025-05-29 23:11:56.943 UTC and ingested logs

7. (Current time is May 29, 2025 @ 23:14). I checked Discover in Kibana for system logs using host.hostname: gwin AND event.module: "system". The query returned 34,810 results. I sorted @timestamp by oldest first and verified the oldest log was May 29, 2025 @ 23:12:18.862. Newest log was May 29, 2025 @ 23:15:59.486

   

8. I looked for an older login event using the /nsm/logstash/logstash-output.json file:

   grep '"event_id":"4624"' /nsm/logstash/logstash-output.json | grep 2025-02 | head -n 1
   

   and I got found this document:

   {
   "message": "An account was successfully logged on.\n\nSubject:\n\tSecurity ID:\t\tS-1-0-0\n\tAccount Name:\t\t-\n\tAccount Domain:\t\t-\n\tLogon ID:\t\t0x0\n\nLogon Information:\n\tLogon Type:\t\t0\n\tRestricted Admin Mode:\t-\n\tRemote Credential Guard:\t-\n\tVirtual Account:\t\tNo\n\tElevated Token:\t\tYes\n\nImpersonation Level:\t\t-\n\nNew Logon:\n\tSecurity ID:\t\tS-1-5-18\n\tAccount Name:\t\tSYSTEM\n\tAccount Domain:\t\tNT AUTHORITY\n\tLogon ID:\t\t0x3E7\n\tLinked Logon ID:\t\t0x0\n\tNetwork Account Name:\t-\n\tNetwork Account Domain:\t-\n\tLogon GUID:\t\t{00000000-0000-0000-0000-000000000000}\n\nProcess Information:\n\tProcess ID:\t\t0x4\n\tProcess Name:\t\t\n\nNetwork Information:\n\tWorkstation Name:\t-\n\tSource Network Address:\t-\n\tSource Port:\t\t-\n\nDetailed Authentication Information:\n\tLogon Process:\t\t-\n\tAuthentication Package:\t-\n\tTransited Services:\t-\n\tPackage Name (NTLM only):\t-\n\tKey Length:\t\t0\n\nThis event is generated when a logon session is created. It is generated on the computer that was accessed.\n\nThe subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.\n\nThe logon type field indicates the kind of logon that occurred. The most common types are 2 (interactive) and 3 (network).\n\nThe New Logon fields indicate the account for whom the new logon was created, i.e. the account that was logged on.\n\nThe network fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.\n\nThe impersonation level field indicates the extent to which a process in the logon session can impersonate.\n\nThe authentication information fields provide detailed information about this specific logon request.\n\t- Logon GUID is a unique identifier that can be used to correlate this event with a KDC event.\n\t- Transited services indicate which intermediate services have participated in this logon request.\n\t- Package name indicates which sub-protocol was used among the NTLM protocols.\n\t- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.",
   "@timestamp": "2025-02-12T17:24:32.680Z",
   "ecs": {
       "version": "8.0.0"
   },
   "type": "redis-input",
   "tags": [
       "preserve_original_event",
       "elastic-agent",
       "input-sostandalone",
       "beats_input_codec_plain_applied"
   ],
   "winlog": {
       "task": "Logon",
       "provider_guid": "{54849625-5478-4994-a5ba-3e3b0328c30d}",
       "computer_name": "gwin",
       "keywords": [
           "Audit Success"
       ],
       "record_id": 40467,
       "provider_name": "Microsoft-Windows-Security-Auditing",
       "opcode": "Info",
       "version": 3,
       "channel": "Security",
       "event_data": {
           "RestrictedAdminMode": "-",
           "TargetUserSid": "S-1-5-18",
           "TargetDomainName": "NT AUTHORITY",
           "TargetOutboundDomainName": "-",
           "LogonGuid": "{00000000-0000-0000-0000-000000000000}",
           "SubjectUserSid": "S-1-0-0",
           "ImpersonationLevel": "-",
           "TargetOutboundUserName": "-",
           "LogonProcessName": "-",
           "TargetLinkedLogonId": "0x0",
           "TransmittedServices": "-",
           "WorkstationName": "-",
           "ElevatedToken": "%%1842",
           "SubjectUserName": "-",
           "RemoteCredentialGuard": "-",
           "TargetUserName": "SYSTEM",
           "SubjectLogonId": "0x0",
           "LmPackageName": "-",
           "TargetLogonId": "0x3e7",
           "LogonType": "0",
           "IpAddress": "-",
           "AuthenticationPackageName": "-",
           "SubjectDomainName": "-",
           "ProcessId": "0x4",
           "VirtualAccount": "%%1843",
           "IpPort": "-",
           "KeyLength": "0"
       },
       "api": "wineventlog",
       "event_id": "4624",
       "process": {
           "pid": 836,
           "thread": {
               "id": 840
           }
       }
   },
   "log": {
       "level": "information"
   },
   "event": {
       "original": "<Event xmlns='http://schemas.microsoft.com/win/2004/08/events/event'><System><Provider Name='Microsoft-Windows-Security-Auditing' Guid='{54849625-5478-4994-a5ba-3e3b0328c30d}'/><EventID>4624</EventID><Version>3</Version><Level>0</Level><Task>12544</Task><Opcode>0</Opcode><Keywords>0x8020000000000000</Keywords><TimeCreated SystemTime='2025-02-12T17:24:32.6802172Z'/><EventRecordID>40467</EventRecordID><Correlation/><Execution ProcessID='836' ThreadID='840'/><Channel>Security</Channel><Computer>gwin</Computer><Security/></System><EventData><Data Name='SubjectUserSid'>S-1-0-0</Data><Data Name='SubjectUserName'>-</Data><Data Name='SubjectDomainName'>-</Data><Data Name='SubjectLogonId'>0x0</Data><Data Name='TargetUserSid'>S-1-5-18</Data><Data Name='TargetUserName'>SYSTEM</Data><Data Name='TargetDomainName'>NT AUTHORITY</Data><Data Name='TargetLogonId'>0x3e7</Data><Data Name='LogonType'>0</Data><Data Name='LogonProcessName'>-</Data><Data Name='AuthenticationPackageName'>-</Data><Data Name='WorkstationName'>-</Data><Data Name='LogonGuid'>{00000000-0000-0000-0000-000000000000}</Data><Data Name='TransmittedServices'>-</Data><Data Name='LmPackageName'>-</Data><Data Name='KeyLength'>0</Data><Data Name='ProcessId'>0x4</Data><Data Name='ProcessName'></Data><Data Name='IpAddress'>-</Data><Data Name='IpPort'>-</Data><Data Name='ImpersonationLevel'>-</Data><Data Name='RestrictedAdminMode'>-</Data><Data Name='RemoteCredentialGuard'>-</Data><Data Name='TargetOutboundUserName'>-</Data><Data Name='TargetOutboundDomainName'>-</Data><Data Name='VirtualAccount'>%%1843</Data><Data Name='TargetLinkedLogonId'>0x0</Data><Data Name='ElevatedToken'>%%1842</Data></EventData><RenderingInfo Culture='en-US'><Message>An account was successfully logged on.&#13;&#10;&#13;&#10;Subject:&#13;&#10;&#9;Security ID:&#9;&#9;S-1-0-0&#13;&#10;&#9;Account Name:&#9;&#9;-&#13;&#10;&#9;Account Domain:&#9;&#9;-&#13;&#10;&#9;Logon ID:&#9;&#9;0x0&#13;&#10;&#13;&#10;Logon Information:&#13;&#10;&#9;Logon Type:&#9;&#9;0&#13;&#10;&#9;Restricted Admin Mode:&#9;-&#13;&#10;&#9;Remote Credential Guard:&#9;-&#13;&#10;&#9;Virtual Account:&#9;&#9;No&#13;&#10;&#9;Elevated Token:&#9;&#9;Yes&#13;&#10;&#13;&#10;Impersonation Level:&#9;&#9;-&#13;&#10;&#13;&#10;New Logon:&#13;&#10;&#9;Security ID:&#9;&#9;S-1-5-18&#13;&#10;&#9;Account Name:&#9;&#9;SYSTEM&#13;&#10;&#9;Account Domain:&#9;&#9;NT AUTHORITY&#13;&#10;&#9;Logon ID:&#9;&#9;0x3E7&#13;&#10;&#9;Linked Logon ID:&#9;&#9;0x0&#13;&#10;&#9;Network Account Name:&#9;-&#13;&#10;&#9;Network Account Domain:&#9;-&#13;&#10;&#9;Logon GUID:&#9;&#9;{00000000-0000-0000-0000-000000000000}&#13;&#10;&#13;&#10;Process Information:&#13;&#10;&#9;Process ID:&#9;&#9;0x4&#13;&#10;&#9;Process Name:&#9;&#9;&#13;&#10;&#13;&#10;Network Information:&#13;&#10;&#9;Workstation Name:&#9;-&#13;&#10;&#9;Source Network Address:&#9;-&#13;&#10;&#9;Source Port:&#9;&#9;-&#13;&#10;&#13;&#10;Detailed Authentication Information:&#13;&#10;&#9;Logon Process:&#9;&#9;-&#13;&#10;&#9;Authentication Package:&#9;-&#13;&#10;&#9;Transited Services:&#9;-&#13;&#10;&#9;Package Name (NTLM only):&#9;-&#13;&#10;&#9;Key Length:&#9;&#9;0&#13;&#10;&#13;&#10;This event is generated when a logon session is created. It is generated on the computer that was accessed.&#13;&#10;&#13;&#10;The subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.&#13;&#10;&#13;&#10;The logon type field indicates the kind of logon that occurred. The most common types are 2 (interactive) and 3 (network).&#13;&#10;&#13;&#10;The New Logon fields indicate the account for whom the new logon was created, i.e. the account that was logged on.&#13;&#10;&#13;&#10;The network fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.&#13;&#10;&#13;&#10;The impersonation level field indicates the extent to which a process in the logon session can impersonate.&#13;&#10;&#13;&#10;The authentication information fields provide detailed information about this specific logon request.&#13;&#10;&#9;- Logon GUID is a unique identifier that can be used to correlate this event with a KDC event.&#13;&#10;&#9;- Transited services indicate which intermediate services have participated in this logon request.&#13;&#10;&#9;- Package name indicates which sub-protocol was used among the NTLM protocols.&#13;&#10;&#9;- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.</Message><Level>Information</Level><Task>Logon</Task><Opcode>Info</Opcode><Channel>Security</Channel><Provider>Microsoft Windows security auditing.</Provider><Keywords><Keyword>Audit Success</Keyword></Keywords></RenderingInfo></Event>",
       "created": "2025-05-29T23:12:20.179Z",
       "kind": "event",
       "outcome": "success",
       "provider": "Microsoft-Windows-Security-Auditing",
       "action": "Logon",
       "code": "4624",
       "dataset": "system.security"
   },
   "agent": {
       "id": "187f495d-48f7-40f7-9364-16ef1a0134b5",
       "name": "gwin",
       "type": "filebeat",
       "ephemeral_id": "846c3f2b-c7b0-4858-8402-66d6dd19415c",
       "version": "8.17.3"
   },
   "metadata": {
       "stream_id": "winlog-system.security-e27e9249-1d6a-4b40-aef5-df27f01736db",
       "type": "_doc",
       "beat": "filebeat",
       "input_id": "winlog-system-e27e9249-1d6a-4b40-aef5-df27f01736db",
       "input": {
           "beats": {
               "host": {
                   "ip": "10.111.50.6"
               }
           }
       },
       "raw_index": "logs-system.security-default",
       "version": "8.17.3"
   },
   "elastic_agent": {
       "id": "187f495d-48f7-40f7-9364-16ef1a0134b5",
       "snapshot": false,
       "version": "8.17.3"
   },
   "data_stream": {
       "namespace": "default",
       "dataset": "system.security",
       "type": "logs"
   },
   "input": {
       "type": "winlog"
   },
   "@version": "1",
   "host": {
       "id": "ae5005f7-fd3c-44bb-aecd-fea0e1f00518",
       "ip": [
           "fe80::1ac7:bae7:39de:75a0",
           "169.254.216.152",
           "fe80::cc61:f07a:6267:a944",
           "192.168.86.128",
           "fe80::2f35:66c5:9401:4884",
           "169.254.111.181"
       ],
       "hostname": "gwin",
       "os": {
           "platform": "windows",
           "type": "windows",
           "family": "windows",
           "build": "22631.5335",
           "name": "Windows 11 Pro",
           "kernel": "10.0.22621.5331 (WinBuild.160101.0800)",
           "version": "10.0"
       },
       "architecture": "x86_64",
       "name": "gwin",
       "mac": [
           "00-0C-29-1F-4A-48",
           "00-FF-3A-28-2D-B5"
       ]
     }
   }

9. Looking in Discovery for host.hostname: gwin AND event.code : 4624 AND winlog.record_id: 40467 I get one hit. All the fields match (including process pid, thread id, etc.), but the @timestamp is May 29, 2025 @ 23:12:20.179. The @timestamp in the original document is @timestamp: "2025-02-12T17:24:32.680Z", and the event.created field is "2025-05-29T23:12:20.179Z".

   

10. Used Dev Tools console to simulate the pipeline ingest using the below query. I observed the date processor modifying @timestamp on line 11541 of the returned result (not included).

    POST /_ingest/pipeline/logs-system.security-1.67.0/_simulate?verbose 
    {
        "docs": [
        {
          "_index": "index",
          "_id": "id",
          "_source": {
        "message": "An account was successfully logged on.\n\nSubject:\n\tSecurity ID:\t\tS-1-0-0\n\tAccount Name:\t\t-\n\tAccount Domain:\t\t-\n\tLogon ID:\t\t0x0\n\nLogon Information:\n\tLogon Type:\t\t0\n\tRestricted Admin Mode:\t-\n\tRemote Credential Guard:\t-\n\tVirtual Account:\t\tNo\n\tElevated Token:\t\tYes\n\nImpersonation Level:\t\t-\n\nNew Logon:\n\tSecurity ID:\t\tS-1-5-18\n\tAccount Name:\t\tSYSTEM\n\tAccount Domain:\t\tNT AUTHORITY\n\tLogon ID:\t\t0x3E7\n\tLinked Logon ID:\t\t0x0\n\tNetwork Account Name:\t-\n\tNetwork Account Domain:\t-\n\tLogon GUID:\t\t{00000000-0000-0000-0000-000000000000}\n\nProcess Information:\n\tProcess ID:\t\t0x4\n\tProcess Name:\t\t\n\nNetwork Information:\n\tWorkstation Name:\t-\n\tSource Network Address:\t-\n\tSource Port:\t\t-\n\nDetailed Authentication Information:\n\tLogon Process:\t\t-\n\tAuthentication Package:\t-\n\tTransited Services:\t-\n\tPackage Name (NTLM only):\t-\n\tKey Length:\t\t0\n\nThis event is generated when a logon session is created. It is generated on the computer that was accessed.\n\nThe subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.\n\nThe logon type field indicates the kind of logon that occurred. The most common types are 2 (interactive) and 3 (network).\n\nThe New Logon fields indicate the account for whom the new logon was created, i.e. the account that was logged on.\n\nThe network fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.\n\nThe impersonation level field indicates the extent to which a process in the logon session can impersonate.\n\nThe authentication information fields provide detailed information about this specific logon request.\n\t- Logon GUID is a unique identifier that can be used to correlate this event with a KDC event.\n\t- Transited services indicate which intermediate services have participated in this logon request.\n\t- Package name indicates which sub-protocol was used among the NTLM protocols.\n\t- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.",
        "@timestamp": "2025-02-12T17:24:32.680Z",
        "ecs": {
            "version": "8.0.0"
        },
        "type": "redis-input",
        "tags": [
            "preserve_original_event",
            "elastic-agent",
            "input-sostandalone",
            "beats_input_codec_plain_applied"
        ],
        "winlog": {
            "task": "Logon",
            "provider_guid": "{54849625-5478-4994-a5ba-3e3b0328c30d}",
            "computer_name": "gwin",
            "keywords": [
                "Audit Success"
            ],
            "record_id": 40467,
            "provider_name": "Microsoft-Windows-Security-Auditing",
            "opcode": "Info",
            "version": 3,
            "channel": "Security",
            "event_data": {
                "RestrictedAdminMode": "-",
                "TargetUserSid": "S-1-5-18",
                "TargetDomainName": "NT AUTHORITY",
                "TargetOutboundDomainName": "-",
                "LogonGuid": "{00000000-0000-0000-0000-000000000000}",
                "SubjectUserSid": "S-1-0-0",
                "ImpersonationLevel": "-",
                "TargetOutboundUserName": "-",
                "LogonProcessName": "-",
                "TargetLinkedLogonId": "0x0",
                "TransmittedServices": "-",
                "WorkstationName": "-",
                "ElevatedToken": "%%1842",
                "SubjectUserName": "-",
                "RemoteCredentialGuard": "-",
                "TargetUserName": "SYSTEM",
                "SubjectLogonId": "0x0",
                "LmPackageName": "-",
                "TargetLogonId": "0x3e7",
                "LogonType": "0",
                "IpAddress": "-",
                "AuthenticationPackageName": "-",
                "SubjectDomainName": "-",
                "ProcessId": "0x4",
                "VirtualAccount": "%%1843",
                "IpPort": "-",
                "KeyLength": "0"
            },
            "api": "wineventlog",
            "event_id": "4624",
            "process": {
                "pid": 836,
                "thread": {
                    "id": 840
                }
            }
        },
        "log": {
            "level": "information"
        },
        "event": {
            "original": "<Event xmlns='http://schemas.microsoft.com/win/2004/08/events/event'><System><Provider Name='Microsoft-Windows-Security-Auditing' Guid='{54849625-5478-4994-a5ba-3e3b0328c30d}'/><EventID>4624</EventID><Version>3</Version><Level>0</Level><Task>12544</Task><Opcode>0</Opcode><Keywords>0x8020000000000000</Keywords><TimeCreated SystemTime='2025-02-12T17:24:32.6802172Z'/><EventRecordID>40467</EventRecordID><Correlation/><Execution ProcessID='836' ThreadID='840'/><Channel>Security</Channel><Computer>gwin</Computer><Security/></System><EventData><Data Name='SubjectUserSid'>S-1-0-0</Data><Data Name='SubjectUserName'>-</Data><Data Name='SubjectDomainName'>-</Data><Data Name='SubjectLogonId'>0x0</Data><Data Name='TargetUserSid'>S-1-5-18</Data><Data Name='TargetUserName'>SYSTEM</Data><Data Name='TargetDomainName'>NT AUTHORITY</Data><Data Name='TargetLogonId'>0x3e7</Data><Data Name='LogonType'>0</Data><Data Name='LogonProcessName'>-</Data><Data Name='AuthenticationPackageName'>-</Data><Data Name='WorkstationName'>-</Data><Data Name='LogonGuid'>{00000000-0000-0000-0000-000000000000}</Data><Data Name='TransmittedServices'>-</Data><Data Name='LmPackageName'>-</Data><Data Name='KeyLength'>0</Data><Data Name='ProcessId'>0x4</Data><Data Name='ProcessName'></Data><Data Name='IpAddress'>-</Data><Data Name='IpPort'>-</Data><Data Name='ImpersonationLevel'>-</Data><Data Name='RestrictedAdminMode'>-</Data><Data Name='RemoteCredentialGuard'>-</Data><Data Name='TargetOutboundUserName'>-</Data><Data Name='TargetOutboundDomainName'>-</Data><Data Name='VirtualAccount'>%%1843</Data><Data Name='TargetLinkedLogonId'>0x0</Data><Data Name='ElevatedToken'>%%1842</Data></EventData><RenderingInfo Culture='en-US'><Message>An account was successfully logged on.&#13;&#10;&#13;&#10;Subject:&#13;&#10;&#9;Security ID:&#9;&#9;S-1-0-0&#13;&#10;&#9;Account Name:&#9;&#9;-&#13;&#10;&#9;Account Domain:&#9;&#9;-&#13;&#10;&#9;Logon ID:&#9;&#9;0x0&#13;&#10;&#13;&#10;Logon Information:&#13;&#10;&#9;Logon Type:&#9;&#9;0&#13;&#10;&#9;Restricted Admin Mode:&#9;-&#13;&#10;&#9;Remote Credential Guard:&#9;-&#13;&#10;&#9;Virtual Account:&#9;&#9;No&#13;&#10;&#9;Elevated Token:&#9;&#9;Yes&#13;&#10;&#13;&#10;Impersonation Level:&#9;&#9;-&#13;&#10;&#13;&#10;New Logon:&#13;&#10;&#9;Security ID:&#9;&#9;S-1-5-18&#13;&#10;&#9;Account Name:&#9;&#9;SYSTEM&#13;&#10;&#9;Account Domain:&#9;&#9;NT AUTHORITY&#13;&#10;&#9;Logon ID:&#9;&#9;0x3E7&#13;&#10;&#9;Linked Logon ID:&#9;&#9;0x0&#13;&#10;&#9;Network Account Name:&#9;-&#13;&#10;&#9;Network Account Domain:&#9;-&#13;&#10;&#9;Logon GUID:&#9;&#9;{00000000-0000-0000-0000-000000000000}&#13;&#10;&#13;&#10;Process Information:&#13;&#10;&#9;Process ID:&#9;&#9;0x4&#13;&#10;&#9;Process Name:&#9;&#9;&#13;&#10;&#13;&#10;Network Information:&#13;&#10;&#9;Workstation Name:&#9;-&#13;&#10;&#9;Source Network Address:&#9;-&#13;&#10;&#9;Source Port:&#9;&#9;-&#13;&#10;&#13;&#10;Detailed Authentication Information:&#13;&#10;&#9;Logon Process:&#9;&#9;-&#13;&#10;&#9;Authentication Package:&#9;-&#13;&#10;&#9;Transited Services:&#9;-&#13;&#10;&#9;Package Name (NTLM only):&#9;-&#13;&#10;&#9;Key Length:&#9;&#9;0&#13;&#10;&#13;&#10;This event is generated when a logon session is created. It is generated on the computer that was accessed.&#13;&#10;&#13;&#10;The subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.&#13;&#10;&#13;&#10;The logon type field indicates the kind of logon that occurred. The most common types are 2 (interactive) and 3 (network).&#13;&#10;&#13;&#10;The New Logon fields indicate the account for whom the new logon was created, i.e. the account that was logged on.&#13;&#10;&#13;&#10;The network fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.&#13;&#10;&#13;&#10;The impersonation level field indicates the extent to which a process in the logon session can impersonate.&#13;&#10;&#13;&#10;The authentication information fields provide detailed information about this specific logon request.&#13;&#10;&#9;- Logon GUID is a unique identifier that can be used to correlate this event with a KDC event.&#13;&#10;&#9;- Transited services indicate which intermediate services have participated in this logon request.&#13;&#10;&#9;- Package name indicates which sub-protocol was used among the NTLM protocols.&#13;&#10;&#9;- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.</Message><Level>Information</Level><Task>Logon</Task><Opcode>Info</Opcode><Channel>Security</Channel><Provider>Microsoft Windows security auditing.</Provider><Keywords><Keyword>Audit Success</Keyword></Keywords></RenderingInfo></Event>",
            "created": "2025-05-29T23:12:20.179Z",
            "kind": "event",
            "outcome": "success",
            "provider": "Microsoft-Windows-Security-Auditing",
            "action": "Logon",
            "code": "4624",
            "dataset": "system.security"
        },
        "agent": {
            "id": "187f495d-48f7-40f7-9364-16ef1a0134b5",
            "name": "gwin",
            "type": "filebeat",
            "ephemeral_id": "846c3f2b-c7b0-4858-8402-66d6dd19415c",
            "version": "8.17.3"
        },
        "metadata": {
            "stream_id": "winlog-system.security-e27e9249-1d6a-4b40-aef5-df27f01736db",
            "type": "_doc",
            "beat": "filebeat",
            "input_id": "winlog-system-e27e9249-1d6a-4b40-aef5-df27f01736db",
            "input": {
                "beats": {
                    "host": {
                        "ip": "10.111.50.6"
                    }
                }
            },
            "raw_index": "logs-system.security-default",
            "version": "8.17.3"
        },
        "elastic_agent": {
            "id": "187f495d-48f7-40f7-9364-16ef1a0134b5",
            "snapshot": false,
            "version": "8.17.3"
        },
        "data_stream": {
            "namespace": "default",
            "dataset": "system.security",
            "type": "logs"
        },
        "input": {
            "type": "winlog"
        },
        "@version": "1",
        "host": {
            "id": "ae5005f7-fd3c-44bb-aecd-fea0e1f00518",
            "ip": [
                "fe80::1ac7:bae7:39de:75a0",
                "169.254.216.152",
                "fe80::cc61:f07a:6267:a944",
                "192.168.86.128",
                "fe80::2f35:66c5:9401:4884",
                "169.254.111.181"
            ],
            "hostname": "gwin",
            "os": {
                "platform": "windows",
                "type": "windows",
                "family": "windows",
                "build": "22631.5335",
                "name": "Windows 11 Pro",
                "kernel": "10.0.22621.5331 (WinBuild.160101.0800)",
                "version": "10.0"
            },
            "architecture": "x86_64",
            "name": "gwin",
            "mac": [
                "00-0C-29-1F-4A-48",
                "00-FF-3A-28-2D-B5"
            ]
          }
        }
        }
      ]
    }

[Jacob-gr]

(EDIT: I somehow got a messed up evtx export that was only a recent subset of the entire log. Explains my odd results when attempting to test so-import-evtx. It was a layer 8 issue as opposed to anything with the pipelines/processor. The processor can likely be removed completely and doesn't need to be modified)

After looking into it a bit more, I realized that logs ingested via so-import-evtx already have some unique fields (such as an 'import' logstash tag, a data_stream.namespace: so, and data_stream.dataset: import.

I modified the logic of the date processor to include:

ctx.event?.module == 'system' 
  && ctx.data_stream?.namespace == 'so'
  && ctx.data_stream?.dataset == 'import'

So the new processor json is:

{ "date":       { "if": "ctx.event?.module == 'system' \r   && ctx.data_stream?.namespace == 'so'\r   && ctx.data_stream?.dataset == 'import'", "field": "event.created", "target_field": "@timestamp","ignore_failure": true, "formats": ["yyyy-MM-dd'T'HH:mm:ss.SSSX","yyyy-MM-dd'T'HH:mm:ss.SSSSSS'Z'"] } },

I tested this on 2.4.150 and documents sent by Agents now have the proper @timestamp applied. This should also allow any imported documents to still trigger the date processor.

(Honestly though, something still seems weird about the times from so-import-evtx logs with all the default settings. The timestamps are not all the same, but the times appear to only be in the last 24 hour window. However, I'm not familiar with the tool and may be using it wrong.)

[reyesj2]

Created #14693