Digital Forensics Triage Lab

A full forensic examination — imaging every disk, carving unallocated space, chasing artefacts across terabytes — runs for weeks. During a live breach you don’t have weeks. You have the length of one very bad afternoon to answer the questions that drive every containment decision: did they move laterally, did they take credentials, is data leaving right now? Wait for the full exam and you’re doing archaeology on an incident that already finished spreading.

The Digital Forensics Triage Lab is built for that afternoon. It pulls the high-value evidence first — memory, logs, registry, network capture — and reconstructs a timeline fast, without trampling the evidence a later deep-dive or a court will need. The discipline that makes it fast is knowing what to skip, and the discipline that keeps it admissible is never skipping the chain of custody.

Speed vs. Perfection

Triage is selective by design. Instead of imaging the whole disk, you extract the few percent of artefacts that carry most of the answer — KAPE pulls the event logs, browser history, registry hives and prefetch that reconstruct the story, in minutes rather than hours. The volatile evidence comes first because it’s the evidence you can lose: memory vanishes the instant the machine powers off, so it’s captured before anything else touches the box.

The genuine trade-off, stated plainly: triage answers what happened fast, but it is not a substitute for full forensics. It can miss the deeply buried artefact, and anti-forensic techniques can defeat the quick pass. So it’s scoped to inform the response, with the untouched original preserved for the deep-dive — you’re buying speed now without spending the evidence you’ll need later.

What We Actually Collect

Every OS leaves traces; the skill is knowing which ones answer the question at hand:

• Windows: Event logs for the sequence of activity, registry hives for configuration and user traces, memory for what was actually running (including things that never touched disk), prefetch for execution history. A caveat that catches people out: prefetch and similar artefacts prove a program ran, not what it did — evidence of execution, not of intent.
• Linux: Bash history, auth logs for login attempts, cron for persistence, SSH keys and known_hosts for lateral movement. Treat shell history as suggestive, not authoritative — it’s trivially edited or disabled.
• macOS: Unified logs, the Spotlight metadata store, shell history. Worth knowing /var/log/system.log has been effectively empty since Sierra, so the Unified Log is where the evidence actually lives.
• Network: Packet captures for what data left the host, and browser history for how they first got in.

The Toolset

Free or low-cost, so the capability isn’t gated behind a licence you have to justify mid-incident:

• Autopsy: Index and search the collected evidence and assemble the timeline.
• KAPE: Targeted collection — pulls exactly the artefacts that matter, fast, which is what makes triage triage.
• Volatility: Memory analysis for what was truly running — hidden processes, injected code, C2 — the things that leave no disk trace at all.
• Plaso: Merges disparate logs into one super-timeline down to the second, so cause and effect line up across sources.
• Wireshark: Reads the packet capture to show what left the network.
• CyberChef: Quick decoding of obfuscated or encoded payloads. Note KAPE and Volatility are Windows-centric; a Linux or macOS case leans harder on Plaso and manual artefact work, so don’t assume the same toolchain covers every host.

The Workflow (Don’t Skip Steps)

The same strict sequence every time — skip a step and defence counsel doesn’t argue with your findings, they get them excluded entirely:

1. Get Authorisation: Legal and HR sign-off before you touch anything, documented. This isn’t bureaucracy — evidence gathered without authority can taint the whole case and expose you personally, and “we were in a hurry” is not a defence.
2. Capture Memory First: RAM before anything else, because it’s gone the moment power drops. Then KAPE for targeted files, or a full image behind a write-blocker where the case warrants it. Order of volatility drives everything.
3. Hash Everything: SHA-256 each item on collection and re-verify later — the proof that nothing changed in your custody. A broken hash is a broken case.
4. Build a Timeline: Feed it all into Plaso for a minute-by-minute reconstruction across sources.
5. Find the Attack: Work the timeline around the suspected window — what executed, when, and what spawned it.
6. Cross-Check with Network Data: Tie host execution to the matching network traffic. The two corroborating each other is what turns a hypothesis into a finding.
7. Report & Hand Off Indicators: Give the Incident Commander a plain account plus the actionable IoCs — IPs, domains, hashes — to hunt the rest of the estate. The triage feeds containment; it doesn’t wait for the full report.

Questions We Answer

The questions leadership actually asks, and where the answer lives:

• How did they get in? Browser history and execution logs reconstruct the entry — phishing, stolen credentials, or an exploit.
• What ran on the system? Logs, memory and registry together: what executed, when, and under whose account.
• Did they move laterally? RDP logs, network traffic and credential use show whether one compromised host became several.
• What did they take or break? File-access logs, exfil traffic, and staged archives waiting to be pulled. The honest limit: if egress wasn’t logged and the capture missed it, “we can’t confirm exfiltration” often defaults to “assume it happened” under breach-notification rules.
• Did they cover their tracks? Cleared event logs, deleted files, gaps in the timeline. A cleared log is itself evidence — absence in the right place is a finding, not a dead end.

What You Get

• The Report: What happened, when, and what it means — written so a non-technical decision-maker can act on it, with the technical detail behind it.
• Chain of Custody: The documented handling record — who held each item, when, and for how long — that makes the evidence stand up if the incident becomes litigation.
• Evidence List: Every collected item with its verifying hash, so admissibility isn’t in question later.
• IoC Set: IPs, domains and hashes ready to feed the SIEM and EDR to hunt the same attacker across the rest of the estate.
• Next Steps: A clear call on whether this escalates to full forensics or can move straight to remediation — knowing which to recommend is much of the value.

Build It in 30 Days

The tools are the smallest part. What you’re really building is the process and the storage discipline behind them.

• Week 1: Stand up isolated, air-gapped forensic workstations, provision genuinely secure evidence storage (isolated, capacity-planned — disk images are large and evidence storage is never big enough), and get hardware write-blockers.
• Weeks 2–3: Install Autopsy, Volatility and Plaso, configure KAPE targets for your systems, and standardise the collection so any responder produces the same, defensible output.
• Week 4: Write the chain-of-custody and intake forms, then run a full dry-run against a deliberately infected test box end to end. The practice run is where you find the procedural gap — the unsigned form, the missed hash — while it’s harmless instead of during a real case.

Build this and a breach stops being a scramble. You move from reacting to reports to running a fast, methodical, defensible investigation — one whose findings hold up whether they land in a remediation ticket or a courtroom.