Plaso Super-Timeline — Correlating Host Artifacts Across Time

A memory dump shows you what’s running now. The super-timeline shows you how the attacker got there — every step, every file, every action, correlated by timestamp across the full forensic artifact set. Together they reconstruct the complete attack narrative.

The Super-Timeline Concept

Evidence sources → Plaso ingestion → Normalized timeline → Analysis

$MFT        ─────┐
Event Log   ─────┤
Prefetch    ─────┤  log2timeline → .plaso → psort → timeline.csv → Timesketch
Shellbags   ─────┤
Browser hist─────┤
Registry    ─────┘

Resulting timeline:
Time                | Source      | Description
2024-09-02 14:21:03 | MFT         | File created: C:\Users\jsmith\Downloads\invoice_Q4.docm
2024-09-02 14:21:09 | LNK         | File accessed: invoice_Q4.docm (LNK last access)
2024-09-02 14:23:11 | Sysmon:1    | WINWORD.EXE spawned cmd.exe (macro execution)
2024-09-02 14:23:44 | conn.log    | TCP ESTABLISHED → 185.220.101.9:443
2024-09-02 14:24:02 | MFT         | File created: C:\Users\jsmith\AppData\Temp\svcupd.exe
2024-09-02 14:24:07 | Prefetch    | svcupd.exe first execution
2024-09-02 14:24:15 | Registry    | Run key added: HKCU\...\Run → svcupd.exe

This is a complete attack reconstruction from a single timeline.

The Plaso Workflow

Step 1: Image Acquisition (via Velociraptor)

# Velociraptor artifact for targeted disk acquisition
name: Custom.Collect.TriageImage
sources:
  - name: CriticalArtifacts
    query: |
      -- Collect MFT, Event Logs, Prefetch, Registry hives
      SELECT OSPath, Size, upload(file=OSPath) AS Upload
      FROM glob(globs=[
        "C:/$MFT",
        "C:/Windows/System32/winevt/Logs/**",
        "C:/Windows/Prefetch/**",
        "C:/Windows/System32/config/SAM",
        "C:/Windows/System32/config/SYSTEM",
        "C:/Windows/System32/config/SOFTWARE",
        "C:/Windows/System32/sru/SRUDB.dat"
      ])

Step 2: Plaso Parsing

# Parse disk image (takes 30–120 min for 100GB image)
log2timeline.py \
  --storage-file output.plaso \
  --parsers win7,win10 \
  disk_image.dd

# Or parse a directory of collected artifacts
log2timeline.py \
  --storage-file output.plaso \
  --parsers winevt,mft,prefetch,winreg,lnk,srum \
  /path/to/collected_artifacts/

# Convert to timeline CSV
psort.py \
  --output-format l2tcsv \
  --write timeline.csv \
  output.plaso

Step 3: Timesketch Analysis

# Import into Timesketch for collaborative analysis
tsctl import \
  --username analyst \
  --sketch-id 42 \
  --name "jsmith_workstation_2024-09-02" \
  timeline.csv

In Timesketch, search queries narrow the timeline:

# Find all events within 2 minutes of the macro execution
timestamp:>"2024-09-02 14:21:00" AND timestamp:<"2024-09-02 14:26:00"

# Find all persistence artifact writes
data_type:"windows:registry:key_value" AND key_path:*Run*

# Find all new executable files
data_type:"fs:stat" AND filename:*.exe AND timestamp:>"2024-09-02 00:00:00"

Timestomping Detection: MFT Analysis

When a file’s SI timestamps look suspicious (too old for a recent attack), check FN timestamps:

# Plaso includes both SI and FN timestamps
# In timeline.csv, look for:
# data_type: windows:ntfs:mft:attribute — contains attribute_type field

# Filter for timestomping indicators
grep "ntfs:mft" timeline.csv | \
  awk -F',' '{print $1, $5, $6}' | \  # timestamp, SI_mtime, FN_mtime
  awk '{if ($2 < $3) print "TIMESTOMPED: " $0}'

Timestomping indicator in timeline:

MFT Record: C:\Users\jsmith\AppData\Temp\svcupd.exe
  $STANDARD_INFORMATION (SI):
    Created:  2019-03-15 08:00:00  ← attacker set to 5 years ago
    Modified: 2019-03-15 08:00:00
    Accessed: 2024-09-02 14:24:07  ← access time updates (can't be backdated this way)
    
  $FILE_NAME (FN):
    Created:  2024-09-02 14:24:02  ← NTFS driver recorded true creation
    Modified: 2024-09-02 14:24:02

SI_Created (2019) is 5 years before FN_Created (2024). Timestomping confirmed.

Prefetch Analysis for Deleted Binaries

Prefetch files survive 28 days and persist even after the source binary is deleted:

# Parse all prefetch files
vol.py -f memory.raw windows.prefetch.Prefetch

# Or from disk with Plaso
# Prefetch output in timeline:
# 2024-09-02 14:24:07 | Prefetch | svcupd.exe — run count: 1, last run: 14:24:07
# 2024-09-02 14:30:00 | MFT      | svcupd.exe DELETED (attacker cleanup)
# Prefetch entry remains, proving svcupd.exe executed even though binary is gone

SRUM for network usage of deleted process:

# srum-dump output
Process: svcupd.exe
  Bytes Sent:     1,247,884  (1.2 MB — C2 check-in data)
  Bytes Received: 82,440     (tasks received)
  Run duration:   8h 14m
  Last seen:      2024-09-02 22:38

Even after the attacker deleted svcupd.exe and cleared event logs, SRUM proves it ran for 8+ hours and sent 1.2 MB.

Worked Example

Super-timeline reconstruction: from phishing to lateral movement

Context: IR team has WS-JSMITH-01. Analyst knows WINWORD.EXE spawned cmd.exe on 2024-09-02 14:23. The goal: reconstruct the full attack chain from initial access to lateral movement.

Timeline excerpt (filtered, 24h window around incident):

14:18:22 | Browser hist | Received email attachment: invoice_Q4.docm (Outlook cache)
14:21:03 | MFT-Create   | C:\Users\jsmith\Downloads\invoice_Q4.docm
14:21:07 | LNK          | invoice_Q4.docm accessed by jsmith
14:23:11 | Sysmon:1     | WINWORD.EXE (PID 1644) → cmd.exe (PID 2188)
14:23:14 | Sysmon:1     | cmd.exe → powershell.exe -enc [base64]
14:23:44 | Sysmon:3     | powershell.exe → 185.220.101.9:443 ESTABLISHED
14:24:02 | MFT-Create   | C:\Users\jsmith\AppData\Temp\svcupd.exe
14:24:07 | Prefetch      | svcupd.exe first run (created prefetch)
14:24:15 | Registry      | HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\svcmon = svcupd.exe
14:24:18 | Sysmon:3     | svcupd.exe → 185.220.101.9:443 ESTABLISHED (beacon begins)
15:17:44 | Sysmon:1     | svcupd.exe → net.exe "view /domain" (recon)
15:18:02 | Sysmon:1     | svcupd.exe → nltest.exe /dclist:CORP (domain recon)
16:32:18 | Sysmon:8     | svcupd.exe → target PID: lsass.exe (CreateRemoteThread — credential dump)
16:33:01 | Sysmon:3     | svcupd.exe → 185.220.101.9:443 (large resp_bytes — creds exfiltrated)
18:45:12 | WinEvt:4624  | Logon Type 3 (network) from 10.1.2.33 → 10.1.4.55 as CORP\svc-backup
          |              | (lateral movement using dumped service account credential)

Narrative: Email → attachment download (14:18–14:21) → macro execution → PowerShell download → svcupd.exe dropper (14:24) → Run key persistence (14:24) → beacon established → domain recon (15:17) → LSASS credential dump (16:32) → credentials exfiltrated → lateral movement using svc-backup (18:45).

Critical for IR handoff: Lateral movement began at 18:45 to 10.1.4.55 using svc-backup. Scope extends beyond WS-JSMITH-01.

Retrieval Practice

A Windows endpoint's Event Log was cleared (Sysmon event data is gone from 2024-09-02 14:00–22:00 — the attacker cleared it). What artifacts survive the log clearing that can still reconstruct the attack timeline?

Reveal answer

Surviving artifacts after Event Log clearing: (1) $MFT — file creation, modification, and deletion timestamps are in NTFS metadata, not event logs. All file system activity remains. (2) Prefetch — execution timestamps for every binary, even deleted ones. The attacker's tools will have prefetch entries proving they ran. (3) Registry LastWrite times — registry key modifications (persistence installation, Run key, service installation) are recorded in the registry hive binary, not event logs. (4) SRUM (System Resource Usage Monitor) — 30-60 days of per-process network usage. Proves malware.exe ran and sent X bytes even with no event log. (5) Shellbags — folder access, even for folders since deleted. (6) Browser history / Outlook OST — shows email receipt timestamp and attachment opening. (7) LNK files — file access timestamps. (8) Network logs (Zeek, firewall) — external to the endpoint, attacker cannot clear them. Event 1102 (log cleared) itself is evidence; the absence of logs during a known incident window is also evidence of attacker log clearing (T1070.001).

Retrieval Practice

An MFT analysis shows a file svcupd.exe was created at 14:24:02 with $STANDARD_INFORMATION timestamps set to 2019-03-15. What is this technique called and what two additional MFT fields expose it?

Reveal answer

This is timestomping (T1070.006) — the attacker modified SI timestamps to make the malicious file appear old and blend in with legitimate 5-year-old system files. Two MFT fields that expose it: (1) $FILE_NAME (FN) attribute timestamps — recorded by the NTFS kernel driver at file creation and only updated by rename/move operations. Cannot be modified via the SetFileTime API that attackers typically use. The FN_Created timestamp (2024-09-02 14:24:02) contradicts the SI_Created (2019-03-15). (2) MFT entry sequence number / $LogFile journal entries — the MFT entry number is assigned sequentially at file creation. An entry number in the range of other September 2024 files that claims to have been created in 2019 is logically inconsistent. The $LogFile (NTFS journal) may also contain the original write record with the true creation time.