Tools · Forensics tools · 02 / 25
Autopsy: build a timeline and read it in order
A folder tree shows what is on disk. A timeline shows what happened in time, and only after you know which timestamp source each row came from.
A timeline is a stack of clocks
Autopsy can lay filesystem times, web history, download records, and other parsed events on one strip. Each row has a time, a type, and a source. The source is the part people skip. A created time from NTFS, a visit time from a browser database, and a download time from another database are three different clocks that happen to share a column. You read them together only after each one has been parsed by a module you actually ran.
Sort by time when you want the order of the morning. Filter by the filename, the user path, or the event type when the strip is too long to see the payroll file. Zooming out until the whole year fits will hide the twenty minutes that matter. The useful window for NL-2026-041 is the morning of 15 April, plus a margin on either side so you can see what the account did before the workbook moved.
M, A, C, and B are different events
On NTFS, a file carries more than one timestamp, and more than one place stores them. Modified is content. Accessed is a read, and on many Windows systems it is updated loosely or not at all, so a stale access time is ordinary. Metadata change is the record itself changing: a rename, a permission, a flag. Born, or created, is when this file record was created. Autopsy’s timeline uses those letters so you can say which one you mean.
The same file also has times in the $STANDARD_INFORMATION attribute and in the $FILE_NAME attribute. They are allowed to differ. Copying a file, restoring it, or a program updating one attribute and leaving the other will do that. When they differ, you record both values and both sources. You do not average them, and you do not pick the one that makes the story smoother. A created time in 2024 next to a file-name time on the morning of the incident is a fact about the attributes. The reason for the gap is a later question, answered with the rest of the artifacts, and sometimes it stays unanswered.
- M, modified: the content changed.
- A, accessed: a read. Treat a quiet access clock as normal on modern Windows.
- C, metadata change: the file record changed.
- B, born: this name’s file record was created.
- Say which attribute the time came from when the two NTFS copies disagree.
Other events sit on the same strip
Recent-activity ingest adds rows that did not come from the file record. A Chrome visit, an Edge download, a Windows search entry, and a USB connection are events with their own databases. They belong on the timeline because the question is what the person did, and they need their source in the note because a download row can exist when the file itself was later deleted. The row is evidence of the record, and the file’s presence is a separate check.
Build the timeline after the ingest that feeds it. A timeline opened before recent activity finishes will look like the person never used a browser. If you generate it twice, keep the second one and note the time you generated it. The timeline is a view over the database. It is reproducible from the image plus the module list, which is why the case setup lesson insists on writing that list down.
What a row lets you say
A careful sentence names the artifact, the time, the zone, and the source. “Payroll-April.xlsx has a $FILE_NAME creation time of 15 April 2026 09:14 America/New_York, and the $STANDARD_INFORMATION creation time is 2 March 2024. A download record for the same name appears at 09:12 in the recent-activity results.” That is a finding a second examiner can check. “Avery stole payroll at 9 a.m.” is a motive you have not measured.
Use the timeline to pick the next artifact, then go look at it. The row for p4.xlsx in Temp should send you to that file’s hash, its parent folder, and the process artifacts you may have in Sysmon or memory. The timeline is the index. The file, the log, and the memory image are the exhibits.
Worked case: twenty minutes around the workbook
You filter the timeline to 15 April 2026, 08:30 to 10:00 America/New_York, and to paths containing Payroll or \Temp\. Three rows cluster. At 09:12 a download record names Payroll-April.xlsx. At 09:14 the Documents copy shows a $FILE_NAME creation time, while its $STANDARD_INFORMATION creation time stays in 2024. At 09:18 a file named p4.xlsx appears under AppData\Local\Temp with a created time and a content-modified time one second apart.
You write those three rows into the case notes with their sources. You do not yet claim the Temp copy was uploaded. You do mark 09:12 to 09:18 as the window the memory image and the Sysmon export have to cover, and you tag both files so the report can list them without a second search.
Diagram
Two ways to read the same pair of timestamps
What you do when the NTFS attributes disagree
Row. The April time is copied into the report. The 2024 time is left in the tool.
Source. The note says “created” and does not name an attribute.
Later reader. They cannot tell which clock you dropped, or why the file looks older in another view.
Row. April is recorded as $FILE_NAME. 2024 is recorded as $STANDARD_INFORMATION.
Source. The timeline source and the timezone sit in the same sentence.
Later reader. They can reopen the image and see the same split.
Check yourself
1. The $STANDARD_INFORMATION created time on Payroll-April.xlsx is in 2024. The $FILE_NAME created time is 15 April 2026 09:14. What do you put in the note?