build a super timeline with The Sleuth Kit

why timelines are the whole game in dfir

when something bad happens on a system, you don't get a nice little popup that says "here's what the attacker did." you get scattered breadcrumbs. a modified file here, a deleted log there, a registry key that changed at 3am for no good reason. a super timeline is what turns that mess into a story you can actually read, in order, with timestamps that hold up if you ever have to explain your findings to someone else. the sleuth kit does this for free, and it's still one of the most reliable ways to do it.

the command

fls -m / disk.img > body
mactime -b body > timeline.csv

two tools, two steps, one readable timeline out the other end. let's break down what's actually happening.

fls, pulling every timestamp off the image

fls walks the file system inside a disk image and lists every file and directory it can find, including deleted stuff that hasn't been overwritten yet. the -m / flag tells it to output in mactime format, using / as the mount point prefix so paths look normal in the final report instead of some internal inode reference.

what you get in that "body" file is raw material, one line per file, packed with the four timestamp types filesystems track: modified, accessed, changed, and created, often shortened to mac(b) times. this file isn't meant to be read by a human yet. think of it as the evidence dump before someone organizes it into a case file.

mactime, the part that makes it readable

mactime takes that body file and sorts everything by time instead of by file path. -b body tells it which file to read from. the output, timeline.csv, is a chronological list showing exactly what happened to what file at what second, across the entire filesystem.

this is the moment where scattered artifacts turn into a narrative. instead of "these 40 files have weird timestamps," you get "at 2:14am a shell dropped, at 2:15am it touched three config files, at 2:16am a scheduled task got created." that's the difference between guessing and proving.

narrowing to the incident window

a full disk timeline can be hundreds of thousands of lines. nobody's reading that top to bottom. once you have a rough idea of when things kicked off, whether from an edr alert, a log entry, or a user report, you filter mactime's output down to that window. even a simple grep for a date range turns an unreadable wall of text into a focused timeline you can actually work with.

grep '2024-03-14' timeline.csv

this is where you watch the actual sequence emerge. file drop, persistence mechanism, lateral movement artifact, cleanup attempt. seeing it in order is often the thing that finally makes an incident click into place.

why this matters even if you're not doing dfir for a living

you don't need to be running full incident response engagements for this to be useful. if you ever suspect a personal machine or a server you manage got touched by something it shouldn't have, being able to build a timeline from a disk image means you're not relying on vibes or your own memory of "when did that file last look normal." it's the difference between "something feels off" and "here's the exact sequence of events, with timestamps."

it's also just good practice to know how to image a drive properly before you start poking at it live. running fls straight against a mounted, live system risks changing the very timestamps you're trying to preserve. always work from a copy.

the takeaway

the sleuth kit isn't flashy, it doesn't have a dashboard, and it definitely won't hold your hand. but fls and mactime together can turn a raw disk image into a timeline solid enough to hand to a lawyer, a boss, or your own past self who swore nothing was wrong. learn this workflow on your own test images before you ever need it for real. the best time to practice building a timeline is before you're standing in the middle of an actual incident trying to figure it out under pressure.