A workstation starts beaconing to an unfamiliar IP at 02:14. By morning the machine is rebooted, the browser cache cleared, and the "helpful" admin has already run a cleanup script. The alert is still open. Everything the attacker touched is either gone or contaminated by the people trying to help. That moment — when an incident becomes an investigation — is where Digital Forensics & Incident Response (DFIR) lives, and it is far less glamorous than the tool screenshots suggest.
Two jobs that pull in opposite directions
Incident response wants speed: contain, eradicate, recover. Digital forensics wants preservation: don't touch anything until it's captured. The tension between those two is the whole discipline in miniature. Teams that lean too hard on response destroy evidence; teams that lean too hard on forensics keep a compromised host running for hours while the attacker moves laterally. More on the topic: Red Team & Application Security.
The usual compromise is capture first, then act — grab volatile state (memory, network connections, running processes) before pulling the plug, because RAM disappears on shutdown and a surprising number of investigations turn on what was in memory rather than on disk.
A walkthrough: one suspicious host, four hours
Imagine a mid-size company with a single laptop flagged by EDR. Here is roughly how a practitioner moves, and what breaks if the order changes.
Step 1 — Memory dump. Tools like WinPmem or Magnet RAM Capture pull a raw image. If the team instead reboots into a "clean" state first, injected code that only lives in memory is gone. Memory analysis with Volatility (or Rekall) then answers questions disk can't: what process was hidden, what was injected into lsass.exe, which network connections were live at capture time.
Step 2 — Triage collection. KAPE or Velociraptor pull the artefacts that matter — event logs, prefetch, Amcache, Shimcache, browser history, $MFT — without imaging a 500 GB disk. A full image is sometimes legally necessary; for a fast answer, targeted collection wins on time by hours. More on the topic: What Developers Get Wrong About GDPR, Licenses and IP.
Step 3 — Timeline. Plaso parses those artefacts into a single chronological stream, often viewed in Timesketch. This is where the story assembles: a phishing attachment opened at 01:58, a PowerShell child process at 02:03, outbound C2 at 02:14. Without a merged timeline, analysts stare at five tools and see five unrelated fragments. More on the topic: OSINT.
Step 4 — Network confirmation. PCAP from the sensor, or Zeek/Suricata logs, confirm whether the beacon actually left the network. A host artefact can lie; a packet capture rarely does.
Step 5 — Deleted data. If the attacker deleted staging files, carving from unallocated space (photorec, or filesystem-aware tools) may recover fragments. Success here depends heavily on how much the disk has been written to since — which is why the first rule is to stop writing to it. More on the topic: Stop Asking LLMs to Guess CVEs.
Full disk image vs targeted triage
| Criterion | Full disk image | Targeted triage |
|---|---|---|
| Time to collect | Hours per machine | Minutes |
| Storage cost | Hundreds of GB each | Tens to hundreds of MB |
| Best for | Legal proceedings, deep malware work | Fleet-wide hunting, fast scoping |
| What you lose | Nothing, in theory | Artefacts you didn't think to grab |
Neither is "correct." A regulated breach with litigation ahead needs the image and a documented chain of custody. A 300-endpoint ransomware wave needs triage on all of them before lunch. More on the topic: Cryptography in Practice.
Static vs dynamic malware triage
Static analysis — strings, PE headers, imports, YARA rules — is fast and safe, and tells you what a sample could do. Dynamic analysis in an isolated sandbox tells you what it does: which domains it resolves, which registry keys it touches. The trap is trusting static alone: packed samples show almost nothing until they run. The trap on the other side is running everything — some samples detect sandboxes and stay dormant, or worse, escape a poorly isolated VM.
Where self-study stalls
You can learn a lot free: Volatility's documentation, the SANS posters, Zeek's own docs, countless write-ups. The problem isn't material, it's feedback. When you carve a deleted file and get garbage, nobody tells you whether your offset was wrong or the data was simply overwritten. When you build a timeline and it makes no sense, there's no one to check your reasoning.
That gap is what structured courses close — Digital Forensics & Incident Response (DFIR) walks the full cycle from host and memory forensics through timeline analysis to NIST SP 800-61-aligned response playbooks, with lessons adapted to your current level. The alternative — a lab you build yourself plus a mentor — works too, but costs more time and depends on finding that mentor.
Who this suits, and who it doesn't
DFIR rewards patience and a tolerance for ambiguity. If you like clean answers, this field will frustrate you — half of every investigation is "probably." It suits sysadmins and SOC analysts who want to understand what happens after the alert, and it does not suit anyone hoping for quick cert-driven career jumps without hands-on lab time. The honest starting point is one machine, one memory dump, one timeline — and the discipline to capture before you click. More on the topic: ISO 27001 vs SOC 2.