ACSC Logo
© GEMXIT
GEMXIT Logo
Agent Foskett Case File • Microsoft Sentinel • Late-Arriving Data • Timeline Reconstruction • KQL

The Logs Arrived Two Days Late — And Rewrote the Timeline

The incident timeline looked finished.

Initial access.
Execution.
Persistence.
Response.

The evidence had been documented.

Then, two days later, more logs appeared.

They were not new attacker activity.

They were old events arriving late.

And when Agent Foskett placed them where they actually belonged, the beginning of the attack moved.

Discuss Microsoft SecurityBack to investigations
Agent Foskett investigating late-arriving Microsoft Sentinel telemetry that changed an incident timeline
Arrival Time Was Not Event Time.

Security telemetry can become queryable long after the activity occurred. Investigation timelines must preserve that distinction.

✓ Compare event and ingestion time
✓ Identify delayed telemetry
✓ Rebuild the attack timeline

The timeline had looked convincing

Every event originally available to the analyst pointed to the same sequence.

There was a clear first suspicious action.
A series of follow-on events.
Then containment.

Agent Foskett had no reason to invent evidence that was not present.

But an investigation timeline is always based on the evidence available at that moment.

Two days later, the available evidence changed.

The new records had old timestamps

The newly visible telemetry contained events whose source timestamps belonged near the beginning of the original incident.

That created two different clocks.

When did the activity occur?

And:

When did the data become available to the investigation?

Agent Foskett needed both.

Measure event time against ingestion time

Agent Foskett used ingestion_time() to compare the event's timestamp with the approximate time the record was ingested into the analytics platform. This makes unusually delayed telemetry visible.
late-arriving-events.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
DeviceProcessEvents
| where Timestamp > ago(7d)
| extend IngestionTime = ingestion_time()
| extend IngestionDelay = IngestionTime - Timestamp
| where IngestionDelay > 1h
| project Timestamp,
          IngestionTime,
          IngestionDelay,
          DeviceName,
          AccountName,
          FileName,
          ProcessCommandLine
| order by IngestionDelay desc

Some delay is normal. Two days was investigation-significant.

Ingestion delay is not automatically evidence of an attack or a broken connector.

Different data sources and pipelines have different delivery characteristics.

Agent Foskett therefore treated the delay as a telemetry fact, not an attacker indicator.

But when evidence arrived roughly two days after the activity it described, that delay materially affected the incident reconstruction.

The late data had to be inserted by event time — not appended to the end of the story.

Find the most delayed records

Instead of looking at one event, Agent Foskett measured the delay across the relevant device and period to determine whether the problem was isolated or systematic.
delay-distribution.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
DeviceProcessEvents
| where Timestamp > ago(7d)
| extend IngestionTime = ingestion_time()
| extend IngestionDelayMinutes =
    datetime_diff("minute", IngestionTime, Timestamp)
| summarize Events=count(),
            MaxDelayMinutes=max(IngestionDelayMinutes),
            AvgDelayMinutes=avg(IngestionDelayMinutes)
    by DeviceName, bin(Timestamp, 1h)
| order by MaxDelayMinutes desc

The missing beginning appeared

Once the delayed records were placed according to their event timestamps, activity appeared before what had previously been considered the first suspicious event.

The attacker had not started where the original timeline started.

The investigation had simply lacked the earlier telemetry.

The first observed event was not the first actual event represented by the now-complete evidence.

Rebuild the timeline using event timestamps

Agent Foskett preserved both clocks in the output. Timestamp was used to reconstruct the activity sequence, while ingestion time showed when each record became available to investigators.
rebuilt-timeline.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
let StartTime = datetime(2026-10-01 00:00:00);
let EndTime   = datetime(2026-10-04 00:00:00);
DeviceProcessEvents
| where Timestamp between (StartTime .. EndTime)
| extend IngestionTime = ingestion_time()
| extend IngestionDelay = IngestionTime - Timestamp
| project EventTime=Timestamp,
          IngestionTime,
          IngestionDelay,
          DeviceName,
          AccountName,
          FileName,
          ProcessCommandLine,
          InitiatingProcessFileName
| order by EventTime asc

Then ask why the data was late

Agent Foskett did not assume the attacker had delayed the logs.

The next investigation was operational: data-source availability, endpoint connectivity, forwarding, collection and ingestion behaviour all needed consideration.

If the affected source was monitored through Microsoft Sentinel health capabilities, health telemetry could also help identify collection or resource issues.

Late evidence requires two investigations: what the evidence says, and why the evidence arrived late.

Look for related Sentinel health evidence

Where SentinelHealth is available and enabled for the relevant resource type, Agent Foskett can inspect health events around the delay. Health coverage varies by supported Sentinel resource and configuration, so absence of a record is not proof that collection was healthy.
late-data-health.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
let StartTime = datetime(2026-10-01 00:00:00);
let EndTime   = datetime(2026-10-04 00:00:00);
SentinelHealth
| where TimeGenerated between (StartTime .. EndTime)
| project TimeGenerated,
          SentinelResourceType,
          SentinelResourceName,
          OperationName,
          Status,
          Description,
          Reason
| order by TimeGenerated asc

The incident report had to change

The original report was not dishonest.

It reflected the evidence available when it was written.

But the late-arriving records changed material facts: the earliest observed activity, the sequence of execution and the amount of time the attacker may have been active before detection.

Agent Foskett updated the timeline and documented why it changed.

A mature investigation records uncertainty and revises conclusions when new evidence arrives.

Build the two-clock timeline

Activity occursThe source records the original security event.
Initial evidence arrivesInvestigators build a timeline from the telemetry currently available.
Incident is documentedThe first reconstruction identifies an apparent beginning and sequence.
Delayed records arriveOlder events become queryable roughly two days later.
Timeline is rebuiltLate records are inserted according to event time, not arrival time.
Conclusions are revisedThe report records the new evidence, changed timeline and telemetry delay.

What Agent Foskett checked

Event timeWhen did the activity represented by the record occur?
Ingestion timeWhen did the record become available to the analytics platform?
DelayHow large was the gap between those two clocks?
ScopeWas delayed telemetry isolated to one event, device or source?
Timeline impactDid the new evidence change initial access, execution or dwell-time conclusions?
Collection healthWas there evidence explaining why the telemetry became available late?

What the evidence can and cannot prove

ingestion_time() can help analysts identify when a record was ingested relative to its event timestamp.

A large difference demonstrates delayed availability of that record; it does not, by itself, explain the cause of the delay or prove attacker interference.

Different tables also use different event-time columns, so investigators must understand the schema of the source they are reconstructing.

Separate what happened from when the evidence became searchable.

The lesson

The logs did not describe a new attack two days later.

They described an older part of the same attack that the investigation had not been able to see.

Agent Foskett did not append those events to the end of the timeline.

He put them where they belonged.

Security timelines should follow event time while preserving ingestion time as evidence about when the analyst could actually know what happened.
Investigation principle: When late telemetry arrives, rebuild the timeline. Do not force new evidence to fit the conclusions you already wrote.

Related investigations

Agent Foskett InvestigationsContinue through the complete collection of real-world Microsoft security investigations.KQL Threat HuntingUse timestamps, ingestion evidence and KQL to reconstruct activity accurately.SOC Analyst AcademyBuild practical investigation, timeline reconstruction and incident-response skills.
The logs were late. The attack wasn't.
Separate event time from evidence availability and rebuild the timeline.
Continue the Investigation

Final thought

An investigation is not a story carved in stone.

It is a reconstruction built from evidence.

When the evidence changes, the reconstruction may need to change with it.

Two days later, the logs did not merely add detail. They changed when the story began.

The Logs Already Knew! 🔎
Develop IT.. Protect IT.. GEMXIT.
GEMXIT PTY LTD | GEMXIT UK LTD
Talk to GEMXIT
ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT

The Logs Arrived Two Days Late — And Rewrote the Timeline

This Agent Foskett investigation examines late-arriving security telemetry that materially changes an established incident timeline.

Investigate Late-Arriving Logs with KQL

Use event timestamps, ingestion_time(), ingestion delay, DeviceProcessEvents, SentinelHealth and KQL to distinguish when activity occurred from when evidence became available.

Reconstruct Security Incident Timelines

Learn why analysts should rebuild timelines when delayed telemetry appears and revise conclusions when new evidence changes the beginning or sequence of an attack.