Digital forensics and DFIR explained.

When a system is breached, two questions land at the same time and pull in opposite directions. The first is operational: make it stop — get the attacker out, restore service, limit the damage. The second is investigative: what actually happened — how did they get in, what did they touch, what did they take, and can we prove it well enough to tell a regulator, a court, or the board? Digital forensics answers the second question. DFIR — Digital Forensics and Incident Response — is the discipline that learned to answer both at once, because in a real incident you rarely have the luxury of doing them one after the other.

This article walks the whole field: what forensics is, how it fused with incident response, the lifecycle every response follows, the principles that make evidence hold up, the types of forensics grouped by evidence source, the tools practitioners reach for, and a start-to-finish triage of one compromised host. If you've read our what is a SOC primer, think of DFIR as the sharp end the SOC escalates into when an alert turns out to be real.

Forensics and DFIR: two words that merged

Digital forensics is the older, broader term: the scientifically defensible recovery, preservation, and analysis of data from digital devices. Its roots are in law enforcement and litigation, where the output is evidence that has to survive cross-examination — a stolen-IP case, fraud, child-exploitation material, an insider leak. The emphasis is on rigor and admissibility: prove that the data you are showing is exactly what was on the device, unchanged by your handling of it.

Incident response grew up alongside it in the corporate world, where the priority is speed: an intrusion is in progress and the business needs it contained now. For years these were separate crafts. They merged into DFIR because modern intrusions demand both mindsets at once — forensic discipline (so your evidence is sound and your root cause is correct) applied at incident speed (because the attacker is still moving). A DFIR analyst is equally comfortable pulling a memory image at 2 a.m. to catch a running implant and writing the hash-verified report that goes to legal three weeks later.

The incident response lifecycle (NIST SP 800-61)

Almost every response process in the industry is built on the same backbone: the lifecycle in NIST SP 800-61, the Computer Security Incident Handling Guide. It defines four phases, and forensics threads through all of them rather than living in just one.

• Preparation. Everything you do before the incident: response plans, an on-call rotation, pre-deployed logging and EDR, a jump kit of tools, write blockers on the shelf, and — critically — knowing what "normal" looks like so you can spot abnormal. Most of a response's success is decided here, long before anything is on fire.
• Detection and analysis. Recognizing that something is wrong (an alert, a report, an anomaly), then scoping it: which hosts, which accounts, what technique. This is where the bulk of forensic analysis happens — turning raw telemetry into a confident answer.
• Containment, eradication, and recovery. Stop the spread (isolate the host, disable the account, block the C2), remove the foothold (delete the implant, close the vulnerability), and restore to known-good. Containment decisions are forensically loaded: pulling the network cable preserves disk but a hard shutdown destroys memory, so you sequence acquisition around it.
• Post-incident activity. The lessons-learned review — what worked, what didn't, what detection or control should change so the same class of intrusion doesn't recur. Weak teams skip this; it is where the response actually pays for itself.

NIST also publishes a dedicated forensics companion, SP 800-86, Guide to Integrating Forensic Techniques into Incident Response, which is the document to read when you want the process itself — collection, examination, analysis, reporting — laid out formally.

The principles that make evidence hold up

Forensics is less about clever tools than about disciplined handling. A brilliant finding is worthless if a defense lawyer — or an internal auditor — can argue you altered the evidence while collecting it. Five principles do most of that defensive work.

Chain of custody. A documented, unbroken record of who collected each piece of evidence, when, from where, and everyone who has touched it since. Every transfer is logged; every storage location is accounted for. If there is a gap — a drive that sat unlogged in someone's desk for a weekend — the whole item can be thrown out. Chain of custody is bookkeeping, and it is the single most common place amateur investigations fall apart.

Order of volatility. Evidence decays at wildly different speeds, so you collect the most fragile first. The canonical ordering comes from RFC 3227: CPU registers and cache, then RAM, then network state and running processes, then the disk, then remote logs, then physical media and backups. In practice the line that matters most is memory before disk: a reboot or a clean shutdown wipes RAM forever, taking running malware, injected code, decryption keys, and open network connections with it.

Integrity and hashing. The moment you acquire evidence, you compute a cryptographic hash of it (SHA-256, historically MD5). You record that hash, and anyone can recompute it later to prove the data hasn't changed by a single bit. This is what makes a copy as good as the original in evidentiary terms.

$ sha256sum disk.E01
9f2c...e7ab  disk.E01     # recorded at acquisition
$ sha256sum disk.E01
9f2c...e7ab  disk.E01     # recomputed before analysis — identical, evidence intact

Write blockers. When you read a suspect drive, you must not write to it — even mounting a filesystem can update access timestamps. A write blocker (a hardware device like the Tableau line, or a software equivalent) sits between the drive and your workstation and physically permits reads while rejecting every write, guaranteeing the source is untouched.

Imaging. You almost never analyze the original. You take a bit-for-bit forensic image — every sector, including deleted files and slack space — and work on that copy. Images are stored raw (a dd-style .raw) or in the compressed, metadata-rich Expert Witness Format (.E01). The original goes into evidence storage, hash recorded, and you never touch it again.

Types of forensics, by where the evidence lives

The field splits naturally by evidence source, and each source has its own tools, artifacts, and volatility profile.

• Disk forensics. The classic discipline: filesystems, files, deleted-file recovery, timestamps, and OS artifacts like the Windows registry, prefetch, and event logs. Non-volatile, so it survives a shutdown — which is why it is the most mature area.
• Memory (RAM) forensics. Analyzing a snapshot of live memory. This is where fileless malware, injected code, decrypted secrets, credentials, and active network connections live — none of which ever touch disk. Increasingly the highest-value evidence in a modern intrusion, and the most fragile.
• Network forensics. Reconstructing what crossed the wire from packet captures or flow records — C2 beacons, data exfiltration, lateral movement. If you didn't capture it while it happened, it's gone; see our comparison of Wireshark vs tcpdump for the two workhorse capture tools.
• Mobile forensics. Phones and tablets — messages, app data, location history, call logs. Complicated by strong encryption, locked bootloaders, and proprietary storage, so it leans heavily on specialist commercial tooling.
• Cloud forensics. The hardest new frontier. You often can't image the underlying host at all, so you rely on provider audit logs (AWS CloudTrail, Azure/Entra sign-in logs, Google Workspace audit), API snapshots, and control-plane records. Evidence is bounded by whatever retention you configured before the incident.
• Log forensics. Authentication logs, process-creation events, web-server and application logs, and everything centralized into a SIEM. Cheap to keep, easy to correlate, and often the thread that ties every other source together.

The toolkit, by area

You could spend a career learning these, but a working DFIR analyst reaches for a fairly small, stable set. Grouped by job:

• Disk analysis: The Sleuth Kit and its GUI, Autopsy — the free, open-source foundation of file and filesystem forensics. On the commercial side, EnCase and FTK dominate law-enforcement and enterprise labs.
• Memory analysis: the Volatility Framework is the standard for pulling processes, injected code, network sockets, and credentials out of a RAM image. Acquisition itself uses tools like WinPmem or Microsoft's Linux collector AVML.
• Network analysis: Wireshark for deep packet inspection, and Zeek for turning traffic into high-level connection logs.
• Triage and collection at scale: KAPE (Kroll Artifact Parser and Extractor) grabs and parses the high-value artifacts from a live host in minutes, and Velociraptor does the same across a whole fleet of endpoints from one console.
• Timeline building: plaso / log2timeline is the engine that fuses artifacts from every source into one chronological "super timeline."
• Triage and hunting: YARA lets you write pattern rules to scan files and memory for known-bad indicators — indispensable for quickly finding "is this specific malware anywhere in the estate?"

Two things worth grabbing whole: SANS ships a free analysis VM, the SIFT Workstation, with most of the open-source stack installed, and Eric Zimmerman's suite of Windows forensic tools is the de-facto standard for parsing individual Windows artifacts.

Evidence, tools, and volatility at a glance

Here is the whole landscape in one table — the mental model to keep. Read it top to bottom and you are also reading the order of volatility: collect the top rows first.

Timeline analysis: the super timeline

Individual artifacts are puzzle pieces; the picture only appears when you order them in time. Timeline analysis merges timestamps from dozens of sources — filesystem MACB times, registry keys, event logs, browser history, prefetch — into a single chronological record so you can watch the intrusion unfold minute by minute.

The industry name for the fused version is a super timeline, and plaso is the tool that builds it. You point log2timeline at an image, then use psort to filter and export the result:

$ log2timeline.py timeline.plaso /mnt/evidence_image
$ psort.py -o l2tcsv -w super_timeline.csv timeline.plaso \
    "date > '2026-07-14 00:00:00' AND date < '2026-07-15 00:00:00'"

The payoff: instead of "this file is malicious," you get a narrative — a phishing attachment executes, writes a payload to disk, registers a scheduled task for persistence, then beacons out to an unfamiliar IP. That sequence is what turns a pile of evidence into a root-cause story.

Anti-forensics: how attackers try to disappear

Competent adversaries know exactly what an investigator will look for and actively work to defeat it. Recognizing anti-forensics is half the job.

• Log clearing. Wiping Windows event logs (wevtutil cl) or truncating Linux logs in /var/log. Ironically, the clearing itself is often logged (Event ID 1102), so the gap becomes evidence.
• Timestomping. Altering a file's MACB timestamps to blend malware in with old system files. Defenders counter this by comparing the filesystem's $STANDARD_INFORMATION timestamps against the harder-to-forge $FILE_NAME attribute in the MFT.
• Secure deletion and wiping. Overwriting files or free space so deleted-file recovery returns nothing.
• Encryption and packing. Encrypting payloads and staged data, or packing binaries so static analysis and YARA signatures don't match on disk.
• Living off the land and fileless execution. Using legitimate built-in tools (PowerShell, WMI, certutil) and running entirely in memory so nothing incriminating is ever written to disk. This is precisely why memory forensics has become so important — the evidence exists only in RAM, and only until the next reboot.

A walkthrough: triaging one compromised host

Theory sticks better attached to a scenario. A SOC analyst escalates an EDR alert: a finance workstation, WIN-FIN-07, spawned PowerShell from a Word document and made an outbound connection to an unfamiliar IP. You are the DFIR responder. Here is the sequence.

1. Preserve, most volatile first. You do not shut the machine down — that would destroy the memory-resident evidence the alert implies. You isolate it at the network level (EDR host-isolation, keeping the management channel), then acquire RAM before anything else, hashing the output immediately:

$ winpmem.exe WIN-FIN-07.mem
$ sha256sum WIN-FIN-07.mem > WIN-FIN-07.mem.sha256   # integrity baseline

2. Acquire the disk. With memory captured, you take a forensic image of the disk through a write blocker (or via the EDR's remote-acquisition feature), again recording the hash. Original preserved, chain-of-custody form filled in. From here you work only on copies.

3. Analyze memory for the live threat. You run Volatility against the RAM image to see what was actually executing:

$ vol -f WIN-FIN-07.mem windows.pslist        # a powershell.exe child of winword.exe
$ vol -f WIN-FIN-07.mem windows.malfind       # injected, unbacked executable memory
$ vol -f WIN-FIN-07.mem windows.netscan       # established connection to 203.0.113.77:443

That confirms the alert: a macro spawned PowerShell, code was injected into a process, and a live C2 channel was open — none of which is obvious from disk alone.

4. Build the timeline. You run plaso over the disk image to place events in order, and the story falls out: the document opened at 09:26, dropped a payload to %APPDATA% at 09:27, registered a scheduled task for persistence at 09:28, and beaconed out at 09:31.

5. Extract IOCs. From memory and timeline you now have concrete indicators of compromise: the payload's SHA-256 hash, the C2 IP and domain, the scheduled-task name, the dropped filename. You write a YARA rule for the payload and sweep the rest of the fleet with Velociraptor to find every other infected host. (For the full taxonomy of what makes a good indicator, see what are IOCs.)

6. Report. The deliverable is a clear narrative — timeline, root cause (macro-enabled phishing), scope (which hosts, which data), the IOCs, and remediation — backed by hash-verified evidence and an intact chain of custody. That report is what feeds the eradication plan and the post-incident review, closing the NIST loop you opened at detection.

Careers and certifications

DFIR is one of the most respected specializations in security, and it sits at the senior end of the defensive path — often the Tier 3 tier of a SOC (see how the tiers are structured in inside a SOC: team roles). The work suits people who like methodical investigation, deep technical detail, and building a defensible narrative out of fragments.

On certifications, the GIAC family is the recognized standard: GCFE (GIAC Certified Forensic Examiner) for Windows disk forensics fundamentals, and GCFA (GIAC Certified Forensic Analyst) for advanced incident-response forensics. They pair with the SANS DFIR courses (FOR500, FOR508, FOR572, and others) that many people take alongside them. For hands-on practice without spending a cent, the free SIFT Workstation plus public memory and disk images from CTFs and DFIR challenges will teach you more than any slide deck.

Strip it back and DFIR is a promise about the past: that after the worst has happened, someone can reconstruct exactly what occurred, prove it, and make sure the organization learns from it. The tools change every year; the discipline — preserve first, handle carefully, follow the evidence — does not.

Frequently asked questions