HackBlue

Tools · Triage collection and timelines · 06 / 24

Plaso: read timestamp_desc before you call a time the start

A Plaso row has one datetime and a timestamp_desc that says which time it is. The earliest datetime in the sheet is not automatically the start of the incident.

12 min read · practice only with authorization

One row, one kind of time

A timeline export gives you datetime, timestamp_desc, source, parser, display_name, and a message. The datetime is only the instant named by timestamp_desc. Creation Time, Content Modification Time, Last Access Time, Last Time Executed, and Last Visited Time are different facts that happen to share a column.

Sorting by datetime alone floats whichever of those facts is earliest to the top. That top row can be the birth of an operating-system file from the day the lab image was built.

Match the description to the sentence

If the sentence is “this program ran,” the row you cite needs a description about execution, such as Last Time Executed on a prefetch parser, and the display_name of that prefetch file. If the sentence is “this document’s content changed,” cite Content Modification Time and the file path. A Creation Time row for the same path supports “the file was born then,” which on a lab image is often the build, not the exercise.

Last Access Time that lines up with the collection clock on a live copy is a weak activity claim. The collector or a later mount can refresh it. Say that in the note instead of calling it a user action.

Do not let the first row pick the story

The top of a sheet is an artifact of the sort. It is not a finding. Read timestamp_desc on that row before you write “the activity started here.” Then check whether your export filter, not the incident, is what placed the row in view.

Plaso’s datetimes are UTC. If you compare them with a screenshot from the lab desktop, write the host’s configured zone beside the comparison so the two clocks are not treated as the same kind of time.

Worked case: the image-build time at the top

The export for ACCT-04, filtered to 3 November, opens with notepad.exe at 08:00 and timestamp_desc Creation Time. The message and parser show a file-system record. That file has been on the image since it was built. Two later rows are the ones that belong to the lab hour: prefetch Last Time Executed for NOTEPAD.EXE at 15:10:02 UTC, and Content Modification Time for budget-notes.txt at 15:10:04 UTC.

The finding says the notes file’s content time and the prefetch execution time fall in the lab hour, and that the notepad creation time is the image, not the start of the exercise. The first row stays in the sheet. It is not the first sentence of the finding.

Snippet
2026-09-01T08:00:00Z  Creation Time            FILE  notepad.exe
2026-11-03T15:10:02Z  Last Time Executed       prefetch  NOTEPAD.EXE
2026-11-03T15:10:04Z  Content Modification Time FILE  budget-notes.txt

Diagram

timestamp_desc decides the sentence

Same datetime column, different claims.

  • Creation Time

    When the file record was born. On a lab image, often the build.

  • Content Modification Time

    When the contents last changed, not when the file was first created.

  • Last Time Executed

    An execution artifact, such as prefetch, says the program ran.

  • Last Access Time

    Easy to refresh. If it matches the collection clock, say so.

Check yourself

1. Which column tells you what a Plaso datetime actually is?

2. notepad.exe leads the sheet with Creation Time on the image-build day. What can you write?

3. Last Access Time equals the collection clock on a live copy. How should the note treat it?