How to Build an Attack Timeline (Practice Scenario Included)

Ask an experienced analyst what separates a junior from a senior investigator, and a lot of them will say the same thing: the senior one can build a timeline. Everyone else is just collecting facts.

Here's what that actually means, and a scenario to practice it on.

What a Timeline Actually Is (It's Not Just "List of Events, Sorted by Time")

A pile of timestamped events isn't a timeline. A timeline is a causal story — this happened, which caused this, which enabled this.

The difference matters because incident reports, containment decisions, and even legal/compliance follow-up all depend on the causal version, not the raw list.

A Practice Scenario: Piece This Together

Say you're handed these five facts, out of order, from different log sources:

- 10:47 AM — Outbound connection from WKSTN-042 to an unfamiliar external IP

- 10:52 AM — New scheduled task created on WKSTN-042

- 8:15 AM — User on WKSTN-042 clicked a link in an email

- 11:03 AM — Authentication attempt using WKSTN-042's user credentials against a second host, FILESRV-01

- 8:16 AM — A process spawned from the default browser's process tree on WKSTN-042, then immediately exited

Sorted by time, that's just a list. Built into a timeline, it's a story:

8:15 user clicks link → 8:16 malicious process launches briefly (likely a dropper) → 10:47 the dropper (or something it installed) phones home → 10:52 it establishes persistence via scheduled task → 11:03 the stolen credentials get used to try to move to another host.

Same five facts. Completely different level of usefulness once they're causally connected.

The Method: Anchor, Then Work Outward

1. Find your anchor event. Usually the first clearly-suspicious thing you can confirm — here, the process spawning from the browser.

2. Work backward. What happened right before it that could explain it? (The email click, 1 minute earlier.)

3. Work forward. What happened after that this event could have caused? (Outbound connection, hours later — the delay itself is a clue; dormant malware often waits before phoning home.)

4. Cross-reference hosts. The moment credentials from WKSTN-042 show up on FILESRV-01, your timeline needs a new lane — this is now a lateral movement question, not just a single-host one.

Why the Gaps Matter as Much as the Events

Notice the gap between 8:16 AM and 10:47 AM — almost three hours of nothing. That gap is itself informative: it suggests staged or delayed execution, which is common with malware designed to evade sandboxed analysis (most sandboxes don't wait three hours before deciding a file is clean).

Beginners tend to only look at what's in the logs. Experienced analysts also pay attention to what's conspicuously not there yet, and when it eventually shows up.

Where People Usually Get This Wrong

- Treating log sources independently instead of merging them into one timeline

- Ignoring time zone / clock skew between systems — a genuinely common source of "this doesn't add up"

- Assuming chronological order equals causal order — two things happening close together isn't proof one caused the other

- Stopping at "what happened" instead of pushing to "what does this enable next"

Practicing This for Real

The scenario above is a simplified version of what you'd actually build during an active investigation — where the facts aren't handed to you pre-selected, they're buried in thousands of surrounding log lines you have to search through first.

That's exactly the structure of Adventures Season 0 on EpicDetect — the incident spans multiple episodes and multiple log sources, and building the timeline yourself (instead of being handed one) is most of the actual challenge. Part of getting hands-on SOC experience without a job or home lab. See how Adventures are structured. Free to start, no setup.

TL;DR – Facts Aren't a Timeline Until They're Connected

A timeline is causal, not just chronological. Anchor on your clearest suspicious event, work backward and forward from it, and pay attention to the gaps as much as the events themselves.

---

FAQs

How far back should a timeline go?

As far back as you can find a plausible initial entry point — often further than the first "obviously bad" event, since the actual compromise usually predates detection.

What tools do analysts actually use to build timelines?

Anything from a spreadsheet to dedicated DFIR timeline tools — the tool matters far less than the causal-reasoning skill behind it.

Is timeline-building the same as root cause analysis?

Related but not identical. The timeline is the evidence trail; root cause analysis is the conclusion you draw from it about how the incident actually started.

---

Final thought: Next time you're staring at a pile of logs, don't ask "what happened when." Ask "what caused what." That's the whole skill.

How EpicDetect Can Help

Reading about this stuff only gets you so far. If you want to actually practice it — not multiple choice, not flashcards, an actual case — Adventures drops you into a story-driven SOC investigation where you make the calls a real analyst makes. Season 0 is completely free, no credit card required.

Want the fuller skill tree too? Head to the EpicDetect Atlas for structured lessons on top of the Adventures scenarios.

New here? Sign up and start for free.