From Chaos to Chronology: The Power of Forensic Timelines
- 12 minutes ago
- 9 min read
If you can’t explain what happened before, during, and after an incident, you’re already losing.
That might sound harsh, but it’s the reality of incident response. If your timeline can’t clearly show what led up to the compromise, how the attacker gained access, and what actions occurred afterward, then your investigation has gaps. And gaps are exactly where threat actors hide. Remember, as responders and investigators, we’re already stepping into an incident several steps behind the attacker. We come into a losing battle from the start!
A well-built forensic timeline is the backbone of any investigation. It should bring together events from multiple artifacts to reconstruct the full story of the incident. Who logged in? What files were created or executed? What activity occurred on the system before the compromise? What authentication events or data access happened afterward?
If your timeline can’t answer those questions, then the investigation isn’t finished and it’s telling you exactly where to dig next. Remember, individual logs tell you what happened in isolation. Timelines show you how events relate to each other. Contextual evidence is master!
The Rundown
A timeline should bring order to investigative chaos
Timelining is paramount to a successful and detailed investigation. It needs to tell the complete story or the gaps
Missing events in a timeline may indicate a gap in analysis or anti-forensics
Timelines help tell the story of the incident and identify gaps
A timeline should be detailed and easy to understand
Timelines should only include relevant events that are confirmed malicious or suspicious, which can be utilized for later validation
A good timeline should include dates, system names, usernames, artifact type, if it's confirmed malicious or needs validation, file name, path, a summary and the raw event (if you need to validate further in the investigation). You can also add additional things such as network information, and MITRE tactics. Consistency is key
Timestamps should always be normalized to UTC and in ISO8601
Although this post won’t focus on how to conduct a full investigation, it will focus on how to build and use a timeline to drive one. Specifically, we’ll look at how to create a generic investigative timeline and how it can be used to correlate activity, identify patterns, and uncover gaps in the analysis.
The goal of a timeline isn’t just to collect events. It’s to reconstruct the attacker’s story. Anyone can collect findings and place them in order. However, to take it a step further and be able to contextualize the data and use the investigative mindset to explain why this event occurred or what this means. Now that, that right there, is on a whole nother level.
When done correctly, a timeline should answer the key investigative questions:
How did they get in?
Where did they go?
Are they still here?
What did they take?
Want to know more about this simple, yet accurate concept? Check out this post by Chris Brewer! https://www.linkedin.com/posts/cebrewer_introducing-sniper-incident-response-a-faster-activity-7325187584077299712-dW5h/
Stay tuned because we’ll walk through how to generate a host supertimeline using tools such as Plaso/Log2Timeline, as well as how to build file system timelines using tools like Eric Zimmerman’s MFTeCMD and The Sleuth Kit’s (TSK) FLS/MACtime in a separate blog post coming soon. I know, the anticipation is killing you!
It’s important to note that while this write-up focuses specifically on timelining, a real-world investigation timeline often resides inside a broader investigative spreadsheet. In addition to timeline events, this document typically includes other findings from the investigation such as compromised users, affected hosts, indicators of compromise (IOCs), and relevant network or host-based activity. The great thing is, this is your investigation, so you can customize this as needed. However, it's great to have a general template that can be used to spin up immediately when a case begins. Many incidents you may work could be 1000+ lines or even much more!
Before diving into the tooling, it’s important to first understand what a timeline actually is. As mentioned briefly in the introduction, a timeline is typically a spreadsheet that contains forensic artifacts and investigative findings organized in temporal (chronological) order. Once sorted by time, the timeline should allow you to follow the sequence of events and understand the “story” of the incident. A great analogy I’ve heard and use is to follow the “artifact constellations”.
In an ideal scenario, the timeline should tell the entire story of the incident; from activity that occurred before the compromise, to the attacker’s actions on the system, and finally to any post-compromise activity. More importantly, timelines help investigators correlate events across artifacts and quickly identify gaps in the analysis. For example, do you have a clear understanding of lateral movement? Did you identify how user X was compromised? Are you confident in the initial access?
One final note: while building timelines is critical, keeping detailed investigation notes is just as important. Notes provide context around findings, assumptions, and investigative decisions that may not always be obvious from timeline data alone.
The Tools
You don’t need anything fancy. A spreadsheet such as Excel, is perfect. Anything that supports rows, columns, and sorting.
The Format
There’s one rule you NEED to follow when building timelines: timestamps should ALWAYS be in UTC. No exceptions.
The reason is simple. Well, timezones cause confusion (daylight savings time?), and confusion leads to mistakes in investigations. Most forensic tools already default to UTC, but never assume that’s the case. Always double-check that the timezone is actually set to UTC or +0000 before trusting the data you’re looking at. Ever hear that old saying “trust but verify?”
If you run into timestamps that aren’t in UTC, convert them. This can easily be done with a quick script or even a simple Excel formula (which is honestly easier than most people think).
Also, if you’re using browser-based tools, like an EDR console, always check the timezone settings first. Make this the first thing you validate before running queries or exporting data. Many EDR platforms default to the browser’s local timezone, which can quickly throw off your timeline if you’re not paying attention. Trust me, I’ve made this mistake and it causes you to circle back to the timeline and spend time trying to understand what findings have the correct timestamp. It causes mass confusion as you’re trying to understand the story.
One small trick that helps avoid this entirely: set your forensic workstation’s system time to UTC. That way most tools, exports, and browser sessions will naturally align with UTC.
And if you ever need to convert timestamps in bulk, I’ll include a quick Excel formula below that makes it painless.
=A1 + TIME(7,0,0) “A” represents the column
“+” represents if you want to add or subtract hours
“7” represents how many hours you want to add or subtract
“0” is the minutes and the seconds
Timestamp format should be in ISO8601, which is formatted such as YYYY-MM-DD hh:mm:ss and typically in 24-hour format. For example; 2026-03-08 13:34:48. If you need to format a timestamp from “March 08, 2026 12:00:00” to ISO8601 or similar, consider using “format” options in Excel or G-Sheets to convert timestamps in bulk. Why is this important? Well, some regions that you’re working with may have an entirely different understanding of what your time format means.
The Data
A timeline shouldn’t be filled with noise or known false positives. It should primarily contain events that are relevant to the investigation and confirmed malicious findings. Remember, for events that occurred over a span of time that are duplicate events, you can consolidate or group these into two entries. The first and last time of occurrence. Just be sure to specify in the analysis summary column that this is one of X amount events. An example can be “1.exe executed | 1 of 323 until 2026-03-08 23:50:00”.
That said, I personally like to include events that look suspicious, even if they haven’t been fully validated yet. For example, a strange command line, unusual process activity, or something that occurred around the timeframe of interest. The key is making sure it’s clearly labeled as “suspicious” so it can be validated later as the investigation progresses. You may determine that based on new findings, that the command line is in fact related to the incident or you’re able to present this to the customer/team and determine its unexpected behavior.
Remember, if you’re doing DFIR consulting, you don’t know what’s normal in the environment you’re dropped into. If you need guidance on the mindset you need to identify normal and anomalies, “The DFIR Investigative Mindset” by Brett Shavers is my bible when it comes to needing a new perspective.
This is where having a clean and easy-to-read timeline becomes incredibly important. Clear column names and consistent formatting make it much easier to quickly scan events and understand what you’re looking at. Remember when I mentioned earlier to consider creating a template to use at the start of an investigation? Consistency is great; especially in the midst of the chaos that is an IR incident.
Depending on your role and the types of investigations you typically handle, your timeline fields may vary. However, the fields listed below are ones I’ve found to be particularly useful. Just keep in mind that this list isn’t meant to be all-inclusive. Your timeline will likely evolve based on the data sources and artifacts involved in your investigation or the type of matters you work.
Time of the event
Hostname
Username
Artifact type (IIS log, shellbag, LNK file, userassist, etc.)
Event Type (connection, execution, logon)
Path of the finding (if relevant)
Summary of event
Raw event
In the above GIF, we’ll utilize Eric Zimmerman’s Timeline Explorer to view the timeline CSV.
Threat Actors Hate Your Timelines
In many investigations, you’ll eventually run into anti-forensics or defense evasion techniques. Basically, this is when the threat actor attempts to hide their activity by manipulating or removing evidence. This can include things like clearing logs, deleting files, timestomping timestamps, disabling logging, or modifying artifacts that, we as investigators or responders, commonly rely on.
But here’s the interesting part that you’ll love and threat actors hate: a missing artifact can be an artifact in itself. You know those commercials or ads that are like “Threat Actors hate this one thing”. Yeah, well. A good timeline is something relatable.
When building a detailed timeline, gaps and anomalies often become just as important as the events that are actually present. For example, if timestomping is suspected, a timeline may reveal inconsistencies in file creation or modification times that don’t line up with surrounding activity. If logs were cleared, you may see the last recorded event followed by suspicious activity that suddenly appears without any normal system activity leading up to it. Good timelines don’t just show you what happened, they show you what should have happened but didn’t. For example, you see activity from a user account, but don’t see a correlating login event prior to the first activity. Why is that? Did event logs roll? Were these cleared? Disabled? Is it possible an exploit was leveraged that didn’t use standard logging API?
In other words, even when attackers try to hide their tracks, a well-built timeline can still expose the absence of expected events, which is often just as telling as the evidence they tried to erase. See. Now you’re getting why timelines are so critical, right?!
Common Timeline Mistakes
As a responder, these are some of the most common timeline mistakes I see during investigations. including a few I’ve made myself over the years. Actually, a lot of these have been from personal experience and mistakes that I’ve made! Live and learn!
Too much data in the timeline
A timeline shouldn’t contain every single artifact you collect. If it’s overloaded with noise, it becomes difficult to identify the events that actually matter. Focus on events that are relevant to the investigation or potentially suspicious.
Too many columns or fields
Your timeline shouldn’t take longer to maintain than the investigation itself. If there are too many required fields to populate, responders will either skip entries or stop updating the timeline altogether. Keep it simple and practical. This is a lot easier said than done sometimes.
Too many cooks in the kitchen
If the timeline is shared across a team without clear ownership, things can quickly become messy. Fields may be overwritten, formatting may change, and accountability can disappear. It’s helpful to have a primary owner responsible for maintaining the timeline structure.
Lack of standardization
If everyone enters data differently, the timeline becomes difficult to sort and analyze. Standardizing things like timestamp format, artifact naming, and event descriptions makes timelines significantly easier to work with.
Inaccurate timestamps or mismatched timezones
Mixing local time and UTC in the same timeline can completely derail an investigation. Always normalize timestamps and verify the timezone before adding data.
No consistent template
If a template isn’t used, timelines can look completely different from case to case. Having a reusable template ensures consistency and allows investigators to spin up a timeline quickly when a case begins.
Missing the raw event data
Whenever possible, include the raw event or log entry in the timeline. This allows you to validate findings later if something was misinterpreted or if timezone conversions need to be revisited.
Treating the timeline as a checklist instead of analyzing it
A timeline is only useful if it’s actually analyzed. Simply adding events without questioning them defeats the purpose. We should constantly ask: Does this make sense? What happened before this event? What happened immediately after?
This is where developing an investigative mindset becomes critical.
As you can see, the more evidence you review and build out your timeline, the more you can easily begin to piece together the story of the incident. When built properly, a timeline becomes the backbone of the investigation. It allows investigators to correlate artifacts, reconstruct attacker behavior, and identify gaps that still need to be investigated. Logs tell you what happened in a single event. A timeline tells you the story.