[o365-plugin] Microsoft 365 audit events use collection time instead of the source event CreationTime

[mcjon3z]

Acknowledgements

• I have searched (https://github.com/utmstack/UTMStack/issues) for past instances of this issue
• I have verified that my UTMStack version is up-to-date

Describe the bug

Microsoft 365 audit records contain a CreationTime value representing when the audited activity occurred.

The Office 365 ingestion path appears to assign the time at which UTMStack collects or processes the record as the event timestamp, while retaining the Microsoft CreationTime only inside the raw event payload.

If no downstream normalization replaces the collector timestamp with CreationTime, Microsoft 365 events are indexed according to ingestion time rather than the time of the underlying activity.

Regression Issue

• Select this option if this issue appears to be a regression.

Expected Behavior

The primary normalized event timestamp should be derived from the Microsoft audit record's CreationTime field.

The time at which UTMStack receives the record should be preserved separately, where required, using an ingestion metadata field such as:

• ingested_at
• received_at
• collector_timestamp

This should preserve both the source-event time and the collection time without using one in place of the other.

Current Behavior

The Office 365 collector appears to submit events using the collector's current processing time as the event timestamp.

The original Microsoft CreationTime remains available in the raw JSON, but it does not appear to be used by the collector as the primary normalized timestamp.

As a result, delayed records may appear in UTMStack at the time they were retrieved rather than the time the audited Microsoft 365 activity occurred.

Reproduction Steps

1. Configure the UTMStack Office 365 plugin.
2. Generate a Microsoft 365 audit event and record the activity time.
3. Delay retrieval of the event by stopping the collector, interrupting network connectivity, or otherwise creating a measurable collection delay.
4. Restore collection and allow UTMStack to ingest the event.
5. Inspect the event's primary timestamp in UTMStack.
6. Inspect the CreationTime value in the raw Microsoft audit record.
7. Compare the two values.

Possible Solution

Parse and validate the Microsoft audit record's CreationTime field during normalization and use it as the primary event timestamp.

Recommended handling includes:

• Parsing the timestamp as UTC according to the Microsoft audit schema.
• Retaining the collector's receipt time as a separate metadata field.
• Falling back to ingestion time only when CreationTime is absent or invalid.
• Recording a parsing or normalization warning when fallback behavior is used.
• Adding tests for delayed ingestion, historical collection, invalid timestamps, and missing timestamps.

Additional Information/Context

No response

UTMStack Version

v11

Operating System and version

Ubuntu 24.4

Hypervisor and Version | Server Vendor and Model

ESX

Browser and version

Chrome