The Forensics Mindset
Digital forensics is not detection engineering with extra steps — it asks fundamentally different questions, uses different evidence, and requires a different mental framework. This chapter explains what forensics actually is and why first-touch decisions can make or break an investigation.
A Tier-2 analyst in your SOC gets an alert: Cobalt Strike staging activity from a workstation belonging to a finance employee. The analyst's instinct — shaped by six months of detection work — is to immediately pull EDR telemetry, kill the process, and reset the user's password. That instinct is correct for minimizing current damage. But the CISO wants to know: how did the attacker get in, how long have they been here, what did they touch, and were they acting alone or is this part of something broader? The analyst just overwrote live memory artifacts, killed the process before capturing its handle tree, and initiated a remote remediation that flushed volatile network connections. The investigation is now months harder. The forensic mindset says: before you touch it, decide what you need to preserve, in what order, and at what cost to containment.
Two Fundamentally Different Questions
Detection engineering and digital forensics both deal with attacker activity, but they answer completely different questions:
Detection Engineering vs Digital Forensics
═══════════════════════════════════════════════════════════════════
DETECTION ENGINEERING asks:
"Did something bad happen here?"
"Is this behavior consistent with an attacker technique?"
"Should I fire an alert?"
→ Works in near-real-time
→ Works at scale (thousands of events/second)
→ Answers are binary or probabilistic: yes/no/maybe
→ Evidence: telemetry streams, logs, behavioral patterns
→ Success: reducing false negatives (missed attacks)
DIGITAL FORENSICS asks:
"What exactly did the attacker do, in what order, and when?"
"How did they first establish access — the specific CVE, the exact phish?"
"What data did they access, move, or exfiltrate?"
"Which accounts and systems are compromised — all of them?"
"Is this the same actor as last quarter's incident?"
→ Works on captured, preserved evidence
→ Works on individual systems or small scope
→ Answers are narrative and evidential
→ Evidence: artifacts, file timestamps, registry keys, MFT records
→ Success: complete reconstruction of attacker activity
THE CONNECTION:
Forensic findings inform detection engineering.
A forensic investigation that finds a novel persistence technique
should produce a new detection rule before the case is closed.
Detection gaps that caused the breach become the priority uplift items.
An archaeologist excavating a site doesn't bulldoze the top layer to get to the interesting stuff — they work systematically, documenting context before moving artifacts, because context is often more valuable than the artifact itself. The file a malware wrote to disk is interesting, but the timestamps on that file — what it was written before and after — tell the story. A forensic investigator treats a compromised system the same way: the goal is not just to find the bad file but to reconstruct what happened around it, and that requires preserving evidence in its original context before anything changes it.
Evidence Contamination: Why First-Touch Decisions Matter
Every action taken on a live system changes it. Some changes are small. Some destroy the most valuable forensic artifacts before you know you needed them.
| Action | What it destroys | What it preserves |
|---|---|---|
| Logging into the system (RDP/console) | Current RAM state changes. Authentication events generated. Pagefile modified. Last logon timestamps updated. | Nothing. Avoid until after memory acquisition if memory matters. |
| Running antivirus scan remotely | File access timestamps (last-accessed) on every file touched. Possibly quarantines malware before you've analyzed it. | May catch simpler malware — but you're better off with a forensic image. |
| Rebooting the system | Entire contents of RAM. Running processes, network connections, decrypted keys in memory, injected code, in-memory-only malware with no disk presence. | Clears malware from RAM if it's RAM-only. Captures crash dumps if configured. |
| Deleting attacker files | MFT records, file content, timestamps, evidence of attacker activity. | Stops the malware from running if it's file-based. |
| Network containment (EDR isolate) | Nothing significant — network isolation doesn't alter disk or RAM forensically. | RAM state, disk state, current attacker tooling. |
| Taking a memory image with WinPmem or Magnet RAM Capture | Small portion of RAM written by the tool itself — unavoidable but documented. | Everything in RAM at that moment: processes, connections, injected code, keys. |
Not every incident requires full forensic investigation. A workstation with confirmed ransomware after a phishing link click — where the scope is one machine, the entry vector is known, and the goal is rapid recovery — may warrant reimaging without full forensic analysis. But a silent intrusion on a domain controller, where the attacker may have been present for weeks and the scope is unknown, absolutely requires forensic investigation before any remediation. Applying full forensics to everything wastes time; applying triage-only to serious intrusions loses the evidence needed to understand the breach. Chapter 4 covers how to make the triage vs. full forensics decision.
Order of Volatility
Forensic evidence is collected in order from most volatile (disappears fastest) to least volatile (survives reboots, drives replacement). This principle — the order of volatility — is the foundation of all forensic acquisition planning.
Order of Volatility: Collect in this sequence
═══════════════════════════════════════════════════════════════════
Most volatile (lost instantly on shutdown):
1. CPU registers, cache ← Cannot practically capture
2. RAM (physical memory) ← WinPmem, Magnet RAM Capture
3. Network state (connections, ARP) ← netstat, arp -a, captured live
4. Running processes ← tasklist, ps, captured live
Medium volatility (survives reboot, not drive wipe):
5. Filesystem metadata (MFT, timestamps)← Affected by write activity
6. Event logs (in-memory buffer) ← Flushed periodically to disk
7. Registry (in-memory hives) ← NTUSER.DAT flushed at logoff
8. Prefetch, Amcache, Shimcache ← Updated on execution
Persistent (survives drive removal):
9. Disk image ← dd, FTK Imager, Paladin
10. Backup media, cloud storage ← Stable, controlled access
11. Archived logs (SIEM, cloud) ← Most stable — query independently
Rule: if you can only do one thing before reboot,
acquire RAM first.
How Forensic Findings Close Detection Gaps
The most valuable deliverable from a forensic investigation isn't the report — it's the list of attacker techniques that went undetected, translated into new detection rules.
| Forensic finding | What it reveals about detection | Detection uplift action |
|---|---|---|
| Attacker ran Mimikatz but no alert fired | LSASS access by non-OS processes isn't detected. Process privilege controls not enforced. | Enable Credential Guard. Create rule: process accessing LSASS with PROCESS_VM_READ from unexpected parent. |
| WMI event subscription used for persistence — present for 3 weeks undetected | WMI subscription creation (Event ID 5861) not alerted on. No regular WMI persistence hunts. | Alert on WMI subscription creation. Add WMI persistence check to quarterly threat hunting playbook. |
| Attacker used scheduled task named "WindowsUpdate" — in place for 2 months | Scheduled task creation with suspicious names not monitored. Baseline of legitimate tasks not established. | Alert on Task Scheduler Event 4698 (task created). Whitelist known-good tasks and alert on deviation. |
| Lateral movement via WMI Exec from compromised workstation to 14 servers | WMI remote execution from workstations to servers not baselined or alerted. | Create rule: WMI execution originating from non-admin workstation to multiple servers within 30 minutes. |
Detection rules fire on symptoms — they catch the observable behavior of a technique in progress. Forensics reveals the full story: what happened before the symptom appeared, what happened after the alert fired but before containment, and what the attacker actually accomplished versus what your rules detected. A detection engineer who has done forensic investigation writes better rules because they understand what the attacker's activity actually looks like in the artifact record — not just in the process execution logs that happen to be piped to the SIEM. Detection without forensic literacy produces rules that catch noisy, obvious techniques and miss the careful, methodical attacker who read your SIEM query before they attacked you.
Legal Considerations in Forensics
Forensic evidence may be used in legal proceedings — civil litigation, criminal prosecution, regulatory investigations. Handling evidence correctly from the start determines whether it remains admissible.
| Principle | What it means in practice |
|---|---|
| Chain of custody | Document every person who had access to evidence, in what form, from acquisition to presentation. A gap in the chain can invalidate evidence in court. Use an evidence log: item, hash, custodian, date, action taken. |
| Hash verification | Calculate SHA-256 of every acquired image at acquisition time. Verify it matches when analysis begins. A matching hash proves the evidence hasn't been modified. |
| Write-blockers | When acquiring disk images forensically, always use a hardware write-blocker — a device that allows reading but blocks any writes to the source drive. Without one, the act of connecting a drive to a computer modifies it. |
| Working copies | Never analyze the original. Acquire a forensic image, verify the hash, store the original in a sealed evidence bag, and work exclusively from copies. If you corrupt your working copy, you can re-image from the original. |
| Attorney-client privilege | In some jurisdictions, engaging outside counsel to direct the investigation — including forensic work — can protect the investigation findings under attorney-client privilege, preventing opposing parties from obtaining them in civil litigation. Discuss with legal before starting any investigation that may involve litigation. |
Q & A
Q: An attacker is actively stealing data right now. Do you stop for forensics or contain first?
Contain first, always. An active data exfiltration incident is not the time for forensic purity — isolate the affected systems via EDR immediately, block outbound connections, and stop the bleeding. You will have less forensic evidence for the investigation afterward, but you will have stopped the breach. The key is to take notes about what you did and when during containment: "isolated HOST-X via CrowdStrike at 14:32 UTC" becomes part of the forensic timeline. Most containment actions (EDR isolation, firewall block) don't destroy disk artifacts anyway. The exceptions — running antivirus, rebooting, deleting files — should be avoided unless absolutely necessary. Document what you did and why, and a good forensicator can still reconstruct most of the story from the preserved disk and SIEM logs.
Q: What's the difference between a forensic investigator and a SOC analyst?
A SOC analyst watches a stream of alerts and triages them in near-real-time: "is this alert real? what's the scope? escalate or close?" Their workflow is high-volume, fast-paced, and oriented around reducing mean time to detect. A forensic investigator takes a confirmed compromise and reconstructs exactly what happened: which artifacts prove the timeline, what did the attacker accomplish, what did they miss, what's the full scope of compromise. Their workflow is slow, methodical, and evidence-centric. In practice, the same person often does both — a small SOC may have one analyst who does initial triage AND does the detailed forensic investigation for P1 incidents. But understanding the difference in mindset — reactive stream processing versus retroactive evidence reconstruction — helps you switch modes appropriately. When you're doing forensics, you're acting like an investigator, not a monitor.