What You'll Learn
- Combine disk artifacts, memory findings, and log data into a single unified forensic timeline
- Apply timestamp normalization techniques to correlate events across different data sources
- Reconstruct the complete attack narrative from initial access through data exfiltration
- Identify gaps in the timeline that indicate anti-forensic activity or collection blind spots
- Present findings in an industry-standard forensic timeline format suitable for legal or executive review
Lab Overview
| Detail | Value |
|---|---|
| Lab Profile | lab-velociraptor |
| Containers | Velociraptor Server, Velociraptor Client (Linux) |
| Estimated Time | 70–80 minutes |
| Difficulty | Expert |
| Browser Access | Velociraptor Web UI |
| Pre-Loaded Data | All artifacts from Labs 9.4 and 9.5 available for timeline construction |
| Deliverable | Complete forensic timeline document with minute-by-minute attack reconstruction |
Why Timelines Are the Ultimate Deliverable. Individual artifacts are puzzle pieces. The timeline is the assembled picture. When a CISO asks "what happened?", they don't want a list of IOCs — they want a story. When legal counsel prepares for litigation, they need a chronological chain of events. The forensic timeline is the single most important output of any investigation.
The Scenario
You've completed the disk forensics investigation (Lab 9.4) and memory forensics analysis (Lab 9.5) of the compromised linux-web-01 server. You now have data from multiple sources:
- Authentication logs — SSH brute force attempts, successful logins, account transitions
- Command history — Attacker's post-exploitation commands with timestamps
- Filesystem artifacts — Staged tools, exfiltration archives, persistence scripts with MAC timestamps
- Process data — Running implants, injected code, active C2 connections
- Network connections — C2 beaconing, backdoor listeners, data transfer volumes
- Persistence mechanisms — Cron jobs, systemd services, shell initialization modifications
Your final task is to weave all of these into a single, chronological, minute-by-minute timeline that tells the complete story of this attack.
Part 1: Data Source Inventory
Before building the timeline, catalog every data source you'll be pulling from. Launch a notebook in Velociraptor or use a local document.
Collect Final Artifacts
If you haven't already collected these from Labs 9.4 and 9.5, gather them now:
Linux.Sys.AuthLogs
Linux.Forensics.BashHistory
Linux.Sys.Crontab
Linux.Sys.Services
Linux.Forensics.Timeline
Linux.Sys.Pslist
Linux.Sys.Maps
Linux.Sys.Netstat
Linux.Forensics.Env
Create Your Source Inventory
TIMELINE DATA SOURCE INVENTORY
═══════════════════════════════════════
Source Artifact Time Range Events
Authentication Logs Linux.Sys.AuthLogs [start] - [end] [count]
Command History Linux.Forensics.BashHistory [start] - [end] [count]
Filesystem Timestamps Linux.Forensics.Timeline [start] - [end] [count]
Cron Jobs Linux.Sys.Crontab [creation dates] [count]
Systemd Services Linux.Sys.Services [creation dates] [count]
Process Listing Linux.Sys.Pslist [snapshot time] [count]
Network Connections Linux.Sys.Netstat [snapshot time] [count]
Memory Regions Linux.Sys.Maps [snapshot time] [count]
Timestamp Normalization. Different data sources use different timestamp formats and potentially different time zones. Before correlating events, normalize ALL timestamps to UTC. Auth.log uses local system time, filesystem timestamps may be in a different zone, and process start times use epoch seconds. Convert everything to a single format: YYYY-MM-DD HH:MM:SS UTC.
Part 2: Timeline Construction Framework
Phase Identification
Every attack follows a lifecycle. Map your events to these phases:
| Phase | MITRE ATT&CK | Description | Expected Evidence |
|---|---|---|---|
| Reconnaissance | TA0043 | Scanning / enumeration before exploitation | External scan logs (if available) |
| Initial Access | TA0001 | First successful entry into the system | Auth.log: successful SSH from attacker IP |
| Execution | TA0002 | Running attacker commands and tools | Bash_history: first post-login commands |
| Persistence | TA0003 | Installing mechanisms to maintain access | Cron, systemd, .bashrc modifications |
| Privilege Escalation | TA0004 | Moving from user to root | Sudo events, su commands, exploit execution |
| Defense Evasion | TA0005 | Hiding activity from defenders | History clearing, log tampering, LD_PRELOAD |
| Discovery | TA0007 | Learning about the environment | whoami, id, ifconfig, cat /etc/passwd |
| Collection | TA0009 | Gathering data for exfiltration | find, tar, zip commands on sensitive dirs |
| C2 | TA0011 | Command and control communication | Network connections to attacker IP |
| Exfiltration | TA0010 | Data leaving the network | Outbound data transfer, SCP/curl uploads |
Build the Timeline Grid
Create a spreadsheet or structured document with these columns:
UNIFIED FORENSIC TIMELINE
═══════════════════════════════════════════════════════════════════════════════
Timestamp (UTC) Source ATT&CK Phase Event Description Evidence
──────────────── ────────────── ────────────────── ───────────────────────────────────────── ──────────────
[HH:MM:SS] [data source] [TA00XX phase] [what happened] [artifact ref]
Part 3: Populate the Timeline
Step 1: Anchor Events
Start with the highest-confidence timestamps — events that are unambiguous and precisely timed:
- First brute force attempt (auth.log) — This is your timeline's starting point
- Successful authentication (auth.log) — The moment the attacker gained access
- C2 connection blocked (firewall alert) — The event that triggered the investigation
- Investigation start — When your team began the forensic response
These anchor events create the skeleton. Everything else fits between them.
Step 2: Fill in Disk Artifacts (Lab 9.4 Data)
Using your Lab 9.4 findings, add:
- Each command from bash_history with its approximate timestamp
- File creation timestamps from /tmp staging directory
- Cron job creation time
- Systemd service file creation time
- .bashrc modification time
Timestamp Precision. Auth.log timestamps are precise to the second. Bash_history timestamps (if HISTTIMEFORMAT was set) are precise to the second. But filesystem MAC times can be misleading — atime is often disabled (noatime mount), and mtime can be forged with touch. Note the reliability level of each timestamp in your timeline.
Step 3: Fill in Memory Artifacts (Lab 9.5 Data)
Using your Lab 9.5 findings, add:
- Process start times for suspicious processes
- C2 connection establishment time (from netstat connection age)
- Estimated implant deployment time (based on process start vs. disk artifact creation)
Step 4: Identify Gaps and Anti-Forensics
Examine your timeline for:
- Time gaps — Periods with no recorded activity despite the attacker being present
- Missing data — Expected events that don't appear (e.g., download commands for tools that exist on disk)
- Inconsistencies — Events that appear out of order or with conflicting timestamps
- Anti-forensic indicators — history -c commands, log deletion, timestamp manipulation
Document each gap:
TIMELINE GAP ANALYSIS
═══════════════════════════════════════
Gap Period: [start] to [end] ([duration])
Expected Activity: [what should have been happening]
Possible Explanation: [history clearing / log rotation / system offline]
Confidence: [High / Medium / Low]
Impact on Investigation: [what we can't determine due to this gap]
Part 4: Attack Narrative
Transform your timeline into a readable narrative. This is the "story" version of the timeline — written for an audience that includes technical staff, management, and potentially legal counsel.
ATTACK NARRATIVE
═══════════════════════════════════════
EXECUTIVE SUMMARY
On [date], the linux-web-01 server was compromised through an SSH brute-force
attack originating from [IP]. The attacker achieved initial access at [time],
escalated to root privileges within [duration], established persistent access
through [N] mechanisms, and attempted to exfiltrate data before the C2
connection was blocked by the perimeter firewall at [time].
DETAILED NARRATIVE
Phase 1: Initial Access ([time] - [time])
The attack began with an automated SSH brute-force campaign against the
'deploy' account from IP [address]. After approximately [N] failed attempts
over [duration], the attacker successfully authenticated at [time]. The
successful authentication suggests [weak password / credential reuse / etc.].
Phase 2: Reconnaissance ([time] - [time])
Within [duration] of gaining access, the attacker executed standard
reconnaissance commands: [list]. This revealed [what the attacker learned].
Phase 3: Privilege Escalation ([time] - [time])
The attacker escalated from 'deploy' to root using [method]. This was
possible because [root cause].
Phase 4: Persistence ([time] - [time])
Three persistence mechanisms were installed:
a) [Cron job - description and execution frequency]
b) [Systemd service - description and restart policy]
c) [Shell initialization - description and trigger condition]
Phase 5: Tool Staging and Data Collection ([time] - [time])
The attacker downloaded [tools] to [staging directory] and used them to
[describe data collection activity]. A [size] archive was created containing
[description of exfiltrated data].
Phase 6: C2 and Exfiltration ([time] - [time])
A fileless implant was deployed via [injection technique], establishing
a persistent connection to [C2 IP:port]. The connection beaconed every
[interval] seconds. At [time], the perimeter firewall blocked an outbound
connection to [IP], triggering the SOC alert that initiated this investigation.
[ANTI-FORENSIC NOTE]
A [duration] gap in command history between [time] and [time] indicates the
attacker cleared their bash history during the most sensitive phase of the
operation. [N] expected events are missing from the timeline due to this
anti-forensic activity.
Part 5: Recommendations and Lessons Learned
Complete your timeline document with actionable recommendations:
RECOMMENDATIONS
═══════════════════════════════════════
IMMEDIATE (0-24 hours):
1. Isolate linux-web-01 from the network (preserve memory state before shutdown)
2. Block [C2 IP] at perimeter firewall (both inbound and outbound)
3. Reset all credentials that were on linux-web-01 (deploy, root, service accounts)
4. Check other hosts for connections to [C2 IP]
SHORT-TERM (1-7 days):
5. Reimage linux-web-01 from known-good backup (do NOT attempt to clean)
6. Deploy SSH key-only authentication (disable password auth)
7. Implement fail2ban or similar brute-force protection
8. Audit all cron jobs and systemd services across the fleet
LONG-TERM (1-30 days):
9. Deploy EDR agent (Velociraptor) on all Linux servers for continuous monitoring
10. Implement network segmentation to limit lateral movement
11. Create YARA rules from the recovered implant for fleet-wide scanning
12. Establish forensic readiness plan (pre-deployed collection agents, log retention)
DETECTION GAPS IDENTIFIED:
- SSH brute force ran for [duration] before detection — implement real-time alerting
- No file integrity monitoring on /etc/systemd/system/ or /etc/cron.d/
- No process anomaly detection for web servers spawning shells
- Memory-only implants are invisible without EDR — Velociraptor deployment is critical
Deliverable Checklist
Before completing the lab, ensure you have:
- Data Source Inventory — All artifact sources cataloged with time ranges and event counts
- Unified Timeline — Minute-by-minute chronological reconstruction with ATT&CK phase mapping
- Gap Analysis — All timeline gaps documented with explanations and impact assessment
- Attack Narrative — Complete readable story covering all 6 phases of the attack
- Recommendations — Immediate, short-term, and long-term actions with detection gap analysis
Key Takeaways
- The forensic timeline is the single most important deliverable of any investigation — it transforms raw artifacts into a coherent attack story
- Always normalize timestamps to UTC before correlating events across different data sources
- Anchor your timeline with high-confidence events (auth.log, firewall alerts) before filling in lower-confidence data
- Timeline gaps are themselves evidence — they reveal anti-forensic activity or collection blind spots
- Map every event to a MITRE ATT&CK phase to provide standardized context for technical and non-technical audiences
- The attack narrative bridges the gap between technical findings and executive decision-making
What's Next
Congratulations — you've completed the Digital Forensics module! You've progressed from evidence handling fundamentals through disk analysis, memory forensics, and now timeline construction. In Module 10 — Malware Analysis Essentials, you'll learn to analyze the actual malicious code that attackers deploy, starting with static analysis techniques using YARA rules.
Lab Challenge: Build the Timeline
10 questions · 70% to pass
You're building a forensic timeline from auth.log (system local time, EST), bash_history (epoch seconds), and filesystem timestamps (UTC). What must you do before combining them?
Your timeline shows: 03:12 SSH login successful, 03:13 'whoami' command, 03:45 data_dump.tar.gz created, but NO commands between 03:14 and 03:44. What does this 30-minute gap most likely indicate?
Which events should serve as 'anchor points' when constructing a forensic timeline?
You need to determine the order of two events: a file created at 03:30 (mtime from filesystem) and a cron job installed at 03:28 (mtime from /var/spool/cron). Both timestamps come from filesystem metadata. What reliability concern should you note?
Your unified timeline maps events to MITRE ATT&CK phases. The attacker ran 'whoami', 'id', 'uname -a', and 'cat /etc/passwd' at 03:13. Which ATT&CK tactic does this map to?
Your timeline shows the C2 connection was established at 03:35 but the firewall didn't block it until 04:17. What does this 42-minute window represent from an impact perspective?
In your attack narrative, how should you describe the 30-minute bash_history gap to a non-technical executive audience?
You have a disk forensics finding (persistence cron job created) and a memory forensics finding (fileless implant active in process memory). How should these appear in the unified timeline?
Your completed timeline spans from 02:45 (first brute force) to 04:17 (C2 blocked). What is the FIRST recommendation you should make based on this timeline?
A forensic timeline is considered complete when which of the following criteria are met?
0/10 answered