Reconstruct an Incident Timeline from Misaligned Log Sources

Tier: Core · Workflow area: Incident response, DFIR & CTI

This playbook uses an LLM to merge and sequence disparate logs into a timeline, with a hard rule: every event in the narrative must cite the raw log line it came from, and unsupported connective tissue is flagged, not invented.

When to reach for this

• •
  An investigation spans multiple sources (EDR, firewall, auth, application logs) that must be correlated into one order of events.
• •
  Timestamp formats and time zones differ across sources and you need them normalized.
• •
  You want a first-draft narrative to accelerate the investigation, not a final report.

Skip AI when a single source already tells the whole story in order — reading it is faster than merging.

The workflow

1. 1.

   Normalize timestamps to one zone before merging. Clock skew is the silent killer of timelines. Convert every source to UTC (or one agreed zone) and note the skew you corrected for each source, so the model orders on a common clock.

2. 2.

   Provide the raw logs as citable evidence. Paste the (sample/redacted) log excerpts with a source tag on each block. The model must reference these lines; it cannot order what it cannot see.

3. 3.

   Prompt for a cited, gap-aware timeline.

   Copy

   Reconstruct a single chronological timeline from these log sources
   (sample data, all timestamps already normalized to UTC). For each event:
   - timestamp | source | what happened | RAW LINE it came from.
   Order strictly by timestamp. Do NOT infer causation between events unless the
   logs show it; if you believe two events are linked but the logs do not prove
   it, put it under "Hypotheses (unconfirmed)" separately.
   List any time gaps where you would expect evidence but see none.
   
   [EDR] ...
   [FIREWALL] ...
   [AUTH] ...
   

   Expected output: a single ordered table where every row quotes a raw line, plus separate "Hypotheses" and "Gaps" sections. The separation keeps proven facts apart from the model's storytelling.

4. 4.

   Verify each event against its raw line. Walk the timeline and confirm every quoted raw line actually exists in the source and actually says what the summary claims. The citation makes this a quick lookup rather than a re-investigation.

5. 5.

   Investigate the gaps and hypotheses yourself. The "Gaps" list points you at missing telemetry to go collect; the "Hypotheses" list is where you apply human judgment about causation. Neither goes into the confirmed timeline until you prove it.

6. 6.

   Promote only verified events to the case timeline. The authoritative timeline contains only rows you re-confirmed against raw evidence.

Verify before you trust it

• Raw-line citation check: for each event, find the quoted line in the source. A row citing a line that is not there is fabricated — the model filled a narrative gap. Remove it.
• Ordering check: confirm the sequence honors the normalized timestamps. Models occasionally reorder events to fit a tidier story; the timestamps are the arbiter, not the narrative.
• False-positive catch: watch for benign activity woven into the attack story. If the model places a routine backup job into the intrusion narrative as "possible staging," demand the evidence — coincidental timing is not causation.

Pitfalls

• Uncorrected clock skew. If sources are not normalized before merging, the model orders events wrong and every downstream conclusion inherits the error. Normalize first.
• Invented causation. "The logon at 02:14 led to the file access at 02:16" reads convincing and may be pure sequence, not cause. Keep causation in the hypotheses bucket until proven.
• Dropped events in long inputs. With many log lines, models silently omit some — often the quiet ones that matter. Cross-check the event count against the source.
• Trusting the summary phrasing. The model's paraphrase of a log line can shift its meaning ("failed logon" vs "logon"). Verify against the raw line, not the paraphrase.

Tools

• Open LLM run locally (Ollama): merges and sequences logs offline, keeping investigation data off third-party endpoints.
• DFIR toolkit (log2timeline/Plaso, jq): normalizes timestamps and formats before the model ever sees them.
• SIEM community edition (Elastic, Splunk Free): holds the source logs and lets you re-confirm each cited raw line during verification.

Client-safe variant

Incident logs are among the most sensitive data a client owns — they describe a live or recent breach. Run the reconstruction on a local Ollama model or the client's sanctioned endpoint inside their environment, never a personal account. Redact hostnames, usernames, and internal IPs to stable placeholders before prompting; timeline ordering depends on timestamps and event structure, which survive redaction. Do the timestamp normalization with local DFIR tooling so raw times never leave the boundary. Keep the confirmed timeline in the client's case system, and treat the "Gaps" list as a collection plan for their responders, not something to resolve with assumptions.