DFIR in 2026: A Complete Guide to Digital Forensics and Incident Response

The attackers entered your network 181 days ago. They moved laterally through three servers, exfiltrated 40 GB of data to a Cloudflare Tunnel endpoint, and cleaned their tracks before triggering the ransomware. Your monitoring detected the encryption noise. The breach had already happened months before the alert fired.

This is the average breach in 2025. Digital Forensics and Incident Response (DFIR) is the discipline that answers: what happened, how did they get in, what did they take, and how do we stop it from happening again?

TL;DR

• The average breach in 2025 had a 241-day lifecycle before full containment
• DFIR combines digital forensics (what happened) and incident response (stop it now)
• Evidence must be collected in order of volatility — memory first, disk second, logs third
• Windows stores attacker evidence in dozens of artifact types: Event Logs, Prefetch, Amcache, MFT, registry hives
• Proper IR saves organizations ~$474K on average vs. having no IR plan
• Organizations with AI-assisted detection contain breaches 108 days faster

What Is DFIR?

DFIR stands for Digital Forensics and Incident Response — two related but distinct disciplines that work together during a security incident.

Digital Forensics is the investigative side: collecting, preserving, and analyzing digital evidence to reconstruct what happened. Think of it as crime scene investigation, but for computers. The goal is to answer:

• When did the attacker enter?
• How did they get in (initial access vector)?
• What did they do (lateral movement, persistence, exfiltration)?
• Where are they now?

Incident Response is the operational side: taking immediate action to stop the bleeding, contain the attacker, remove their presence, and restore normal operations.

In practice, these happen simultaneously. You’re collecting evidence while also isolating infected hosts. You’re analyzing malware while also rebuilding systems. The tension between “preserve evidence” and “stop the attack” is one of the defining challenges of the field.

The DFIR Lifecycle

DFIR follows a structured lifecycle, commonly aligned with NIST SP 800-61 (Computer Security Incident Handling Guide). The six phases are:

Preparation → Detection → Containment → Eradication → Recovery → Post-Incident

Each phase has specific objectives, tools, and outputs. Let’s walk through each one in depth.

Phase 1: Preparation

The best incident response happens before the incident. Organizations that invest in preparation cut breach costs by nearly $500,000 compared to those who scramble when the alert fires.

What Preparation Looks Like

Incident Response Plan (IRP): A documented, tested plan covering who does what, when, and how. Should include:

• Escalation matrix (who to call at 2 AM)
• Legal and regulatory obligations (GDPR 72-hour notification, NIS2)
• Communication templates for executives, customers, press
• Contact list for external forensics firms, legal counsel, law enforcement

IR Playbooks: Scenario-specific runbooks for the most common incident types:

• Ransomware playbook
• Business Email Compromise (BEC) playbook
• Data exfiltration playbook
• Insider threat playbook
• Compromised domain admin playbook

Technical Preparation:

• Centralized logging (SIEM) with at least 90 days of retention — ideally 12+ months
• EDR deployed on every endpoint
• Network flow logging (NetFlow/sFlow) from all core switches
• DNS query logging
• Memory acquisition capability pre-staged on critical servers
• Forensic workstation ready with licensed tools

Legal Preparation:

• Evidence handling procedures (chain of custody forms)
• IR retainer with a forensics firm (faster response than cold-calling)
• Data breach notification requirements documented per jurisdiction

Phase 2: Detection and Identification

You can’t respond to what you don’t see. Detection is where most organizations fail.

Initial Alert Triage

Not every alert is an incident. The first job is determining whether you have a real compromise or a false positive. The SANS PICERL model suggests validating five things immediately:

1. Is the alert credible? Check whether the detection logic fires on legitimate behavior.
2. Is there supporting evidence? One alert alone — or corroborating events from other sources?
3. What’s the blast radius? How many hosts, users, and systems are involved?
4. Is this still ongoing? Active compromise or historical artifact?
5. What’s the initial hypothesis? Ransomware pre-deployment? Data exfiltration? C2 beaconing?

Incident Classification

Classify the incident before mobilizing resources:

Initial Scope Identification

Before touching anything, build a picture of the scope:

# Quick SIEM queries to scope the incident

# Who communicated with the suspicious IP in the last 30 days?
source=firewall dest_ip="<ioc>" | stats count by src_ip | sort -count

# Which hosts ran the suspicious process?
source=edr process_name="malware.exe" | dedup host | table host, user, cmdline

# What accounts logged in from unusual locations?
source=auth | eval is_unusual=if(country!="FI","yes","no") | where is_unusual="yes"

Phase 3: Evidence Collection and Preservation

This is the most critical phase. Evidence collected incorrectly is evidence that may be inadmissible in court, destroyed by mistake, or missed entirely. The fundamental principle: collect in order of volatility.

Order of Volatility

Volatile evidence disappears when power is lost. Collect it first:

1. CPU registers, cache, running processes — disappears on reboot
2. RAM (memory dump) — disappears on shutdown
3. Network connections — change constantly
4. Running processes and open files — change constantly
5. Disk (filesystem, logs, registry) — survives reboot but can be modified
6. External/remote logging (SIEM, cloud logs) — most persistent
7. Backups and archival storage — most persistent

Golden rule: never pull the power on a running system without first dumping memory. Many responders have destroyed critical evidence by rebooting before taking a memory image.

Memory Acquisition

Memory holds what disk doesn’t: running processes, decrypted keys, network connections, injected shellcode, and attacker tools that never touched disk (fileless malware).

# Windows — dump memory with WinPmem (free, open source)
winpmem_mini_x64.exe memory.raw

# Windows — dump with DumpIt (single binary, fast)
DumpIt.exe /output memory.raw

# Remote acquisition with Velociraptor
velociraptor --config server.config.yaml artifacts collect \
  Windows.Memory.Acquisition --args dump_path="C:\evidence"

# Linux
sudo avml /tmp/memory.lime
# or LiME kernel module
sudo insmod lime.ko "path=/tmp/memory.lime format=lime"

Store the memory image immediately on write-protected media or a forensic share. Hash it:

# Always hash evidence files (SHA256)
sha256sum memory.raw > memory.raw.sha256

Disk Imaging

For a forensically sound disk image, use tools that create bit-for-bit copies without modifying the original:

# FTK Imager (Windows GUI — industry standard)
# File → Create Disk Image → select Physical Drive

# dd on Linux (with hashing)
sudo dd if=/dev/sda of=/mnt/evidence/disk.img bs=4M status=progress conv=noerror,sync
sha256sum /mnt/evidence/disk.img > disk.img.sha256

# dcfldd (dd with built-in hashing and logging)
dcfldd if=/dev/sda of=/mnt/evidence/disk.img hash=sha256 hashlog=disk.hash

For live systems where you can’t take offline, collect a triage image — key artifacts without a full disk copy:

# Velociraptor triage collection (collects key Windows artifacts in minutes)
velociraptor artifacts collect Windows.KapeFiles.Targets \
  --args _SANS_Triage=true \
  --output triage_collection.zip

# KAPE (Kroll Artifact Parser and Extractor) — gold standard for triage
kape.exe --tsource C: --tdest C:\evidence --target !BasicCollection

Network Evidence

Collect network state before any containment action changes it:

# Windows — active connections
netstat -anob > connections.txt
Get-NetTCPConnection | Export-Csv connections.csv

# DNS cache — what domains did this host resolve recently?
ipconfig /displaydns > dns_cache.txt
Get-DnsClientCache | Export-Csv dns_cache.csv

# ARP table — who was this host talking to on the local network?
arp -a > arp_table.txt

Phase 4: Containment

Containment stops the attacker from doing more damage while you investigate. There are two types:

Short-term containment: Immediate actions to stop the bleeding without destroying evidence.

• Isolate the affected host from the network (VLAN, firewall rule, EDR isolation)
• Block known malicious IPs and domains at the perimeter
• Disable compromised accounts
• Kill malicious processes on running systems

Long-term containment: Stable measures that allow investigation to continue safely.

• Rebuild compromised systems in isolated environment for forensic analysis
• Deploy additional monitoring on adjacent systems
• Implement enhanced authentication for privileged accounts
• Block C2 infrastructure at DNS and proxy level

Isolation Without Rebooting

# EDR-based isolation (CrowdStrike Falcon example)
# Isolate host while preserving evidence collection capability

# Manual network isolation preserving management access
New-NetFirewallRule -DisplayName "IR-Isolate" -Direction Outbound -Action Block
New-NetFirewallRule -DisplayName "IR-Analyst-Allow" -Direction Outbound `
  -RemoteAddress "192.168.1.100" -Action Allow  # allow IR analyst to connect

Important: Isolation decisions are a business call, not just a technical one. Isolating a critical production server may cause more damage than the attacker. Always escalate the containment decision to management.

Phase 5: Forensic Analysis

This is where the investigation happens. The goal: reconstruct the full attacker timeline from initial access to detection.

Windows Forensic Artifacts

Windows is the most common incident target and leaves extensive evidence of attacker activity across dozens of artifact types. Here’s what to look for and where:

Event Logs

Windows Event Logs are the primary source of authentication, process execution, and lateral movement evidence. Key log locations:

C:\Windows\System32\winevt\Logs\
├── Security.evtx      — authentication, account changes, object access
├── System.evtx        — service installs, crashes, driver loads
├── Application.evtx   — application errors, crash dumps
└── Microsoft-Windows-*  — hundreds of operational logs

Critical Event IDs:

For a deeper dive on Windows Event Log analysis, see Windows Event Log Security Analysis.

Prefetch Files

Windows Prefetch records the last 8 execution times of every program run, even if the executable has been deleted.

C:\Windows\Prefetch\
MIMIKATZ.EXE-XXXXXXXX.pf       ← attacker ran mimikatz
PSEXEC.EXE-XXXXXXXX.pf         ← psexec lateral movement
COBALT_STRIKE_ARTIFACT.EXE-*.pf

Parse with PECmd:

PECmd.exe -d C:\Windows\Prefetch --csv output_prefetch.csv
# Look for: execution time, run count, files loaded by each executable

Amcache and ShimCache

Amcache tracks every executable that’s been run — including the SHA1 hash of the binary. This lets you identify malware even after it’s been deleted.

# Parse AmCache hive
AmcacheParser.exe -f C:\Windows\appcompat\Programs\Amcache.hve --csv output_amcache

# ShimCache (AppCompatCache) — program compatibility, also shows execution evidence
AppCompatCacheParser.exe -f SYSTEM --csv output_shimcache

MFT — Master File Table

The NTFS MFT tracks every file that has ever existed on a volume, including deleted files. It preserves creation, modification, and access timestamps — critical for timeline reconstruction.

# Extract MFT
MFTECmd.exe -f $MFT --csv output_mft.csv

# Look for:
# - File creation timestamps matching the suspected intrusion window
# - Executable files created in unusual locations (temp, appdata, public)
# - Files with timestamps in the future or from the epoch (anti-forensics)

LNK Files and Jump Lists

Windows automatically creates LNK (shortcut) files when you open a file. These persist long after the original file is deleted and include the original file path, size, host name, and MAC address.

C:\Users\[user]\AppData\Roaming\Microsoft\Windows\Recent\
C:\Users\[user]\AppData\Roaming\Microsoft\Windows\Recent\AutomaticDestinations\

LECmd.exe -d "C:\Users\victim\AppData\Roaming\Microsoft\Windows\Recent" --csv output_lnk.csv

An LNK pointing to \\malicious-server\share\payload.exe is strong lateral movement evidence even if the share is gone.

Registry Forensics

The Windows Registry is a goldmine of attacker persistence and activity:

# Autorun / persistence locations
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
HKLM\SYSTEM\CurrentControlSet\Services  ← malicious service installs

# Recent files / typed URLs
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\TypedPaths

# USB devices connected
HKLM\SYSTEM\CurrentControlSet\Enum\USBSTOR

# RDP cached hosts
HKCU\SOFTWARE\Microsoft\Terminal Server Client\Servers

# Shell Bags (folder access history)
HKCU\SOFTWARE\Classes\LocalSettings\Software\Microsoft\Windows\Shell\BagMRU

Parse registry hives with RegRipper or Registry Explorer (Eric Zimmermann).

Memory Analysis with Volatility 3

After capturing a memory image, Volatility 3 is the standard tool for analysis:

# Identify OS profile automatically
python3 vol.py -f memory.raw windows.info

# List running processes (including hidden processes)
python3 vol.py -f memory.raw windows.pslist
python3 vol.py -f memory.raw windows.pstree  # shows parent-child relationships

# Compare process list with PEB (detect process hiding / rootkits)
python3 vol.py -f memory.raw windows.psscan   # scan memory for EPROCESS structures

# Find injected code in processes (malware injection, shellcode)
python3 vol.py -f memory.raw windows.malfind

# Network connections at time of capture
python3 vol.py -f memory.raw windows.netstat

# Extract command line arguments from processes
python3 vol.py -f memory.raw windows.cmdline

# Dump suspicious process for static analysis
python3 vol.py -f memory.raw windows.dumpfiles --pid 1337

# Find DLL injection
python3 vol.py -f memory.raw windows.dlllist --pid 1337

# Extract strings from memory (find URLs, C2 domains, credentials)
python3 vol.py -f memory.raw windows.strings | grep -i "http://"

Key indicators in memory:

• Processes with malfind hits (injected PE headers or shellcode in memory regions)
• cmd.exe or powershell.exe spawned by unusual parents (e.g., Word, Excel, IIS)
• Network connections from non-network processes (e.g., notepad.exe connecting out)
• Processes with no corresponding disk file (fileless malware)
• Hollowed processes: PEB shows svchost.exe but mapped DLLs don’t match

Timeline Reconstruction with Plaso/Log2timeline

Timeline analysis correlates artifacts from multiple sources into a single chronological view:

# Create supertimeline from collected artifacts
log2timeline.py --parsers win7,winevt,prefetch,mft,lnk,registry timeline.plaso /evidence/

# Filter to the incident window
psort.py -o l2tcsv timeline.plaso "date > '2026-04-01 00:00:00' AND date < '2026-04-08 23:59:59'" > timeline.csv

# Analyze in Timeline Explorer (Eric Zimmermann's GUI tool)

A good timeline will show you the full attacker story: initial access event → first tool dropped → lateral movement → persistence installed → exfiltration commenced.

Phase 6: Eradication

Once you understand the full scope, remove the threat:

1. Identify all persistence mechanisms — registry autorun, scheduled tasks, malicious services, backdoor accounts, web shells, implants
2. Remove all attacker footholds — don’t miss secondary access paths; attackers routinely install multiple backdoors
3. Rotate all compromised credentials — assume any credential that existed on compromised hosts is stolen
4. Patch the initial access vulnerability — close the door before you kick the attacker out
5. Rebuild from clean images — don’t “clean” infected systems; rebuild them

Common mistake: Eradicating too early, before full scope is known. If you kick the attacker out before understanding all persistence mechanisms, they’ll be back in 24 hours using a different path.

For ransomware-specific eradication and recovery, see Ransomware Backup Strategy 2026.

Phase 7: Recovery

Recovery is not just “restore from backup and move on.” Validate before you reconnect:

• Verify system integrity — compare against known-good baselines or reinstall from scratch
• Restore from pre-compromise backups — confirm the backup predates the intrusion (check the timeline)
• Enhanced monitoring during recovery — attackers sometimes re-enter during the recovery window
• Incremental reconnection — don’t bring all systems online at once; bring them up in phases with monitoring

Phase 8: Post-Incident Activity

The lessons learned phase is where organizations improve. Skipping it means repeating the same incident.

Post-Incident Report Structure

1. Executive Summary (1 page, non-technical)
   - What happened, business impact, total cost, root cause

2. Technical Timeline
   - Chronological reconstruction of attacker activity
   - Evidence sources for each event

3. Root Cause Analysis
   - Initial access vector
   - Why existing controls failed to detect/prevent

4. Impact Assessment
   - Systems compromised
   - Data accessed or exfiltrated
   - Duration of attacker presence

5. Recommendations
   - Immediate fixes (patch, config change)
   - Short-term improvements (detection rule, monitoring coverage)
   - Strategic improvements (architecture changes, tooling gaps)

DFIR Toolkit: Essential Tools

Chainsaw and Hayabusa: Fast Event Log Analysis

When you have hundreds of Event Log files and need answers in minutes, not hours:

# Chainsaw — hunt for attacker TTPs using Sigma rules
chainsaw hunt C:\Windows\System32\winevt\Logs\ \
  --sigma sigma_rules/ \
  --mapping mappings/sigma-event-logs-all.yml \
  --output chainsaw_results.csv

# Hayabusa — timeline-based Windows event log analysis
hayabusa csv-timeline -d C:\Windows\System32\winevt\Logs\ -o timeline.csv
hayabusa summary -d C:\Windows\System32\winevt\Logs\

Both tools use Sigma rules and produce results in minutes from raw .evtx files. See Wazuh for Threat Hunting for SIEM-based hunting workflows.

IR in Cloud Environments

Cloud incidents require different techniques. Traditional disk imaging doesn’t apply.

AWS:

# Create snapshot of compromised EC2 instance volume
aws ec2 create-snapshot --volume-id vol-xxxxxx --description "IR-Evidence-$(date +%Y%m%d)"

# Export CloudTrail logs for the incident window
aws cloudtrail lookup-events \
  --start-time 2026-04-01T00:00:00 \
  --end-time 2026-04-08T23:59:59 \
  --lookup-attributes AttributeKey=EventName,AttributeValue=AssumeRole

Azure:

# Export Azure Activity Logs
az monitor activity-log list \
  --start-time 2026-04-01 \
  --end-time 2026-04-08 \
  --output json > azure_activity.json

# Entra ID sign-in logs
az ad auditlogs signin list \
  --filter "createdDateTime ge 2026-04-01" > signin_logs.json

For Entra ID-specific attacks and investigation, see Entra ID Attacks: Device Code, PRT, and Conditional Access Bypass.

What You Can Do Today

If you have no IR capability yet:

1. Write a one-page contact list — who do you call at 2 AM? IT, management, legal, IR firm
2. Stand up centralized logging — even a basic Wazuh installation gives you Windows event log collection
3. Deploy EDR on endpoints — without endpoint visibility, you’re investigating blind
4. Test your backup restore process — most organizations discover backups don’t work during an incident
5. Get an IR retainer — faster response than cold-calling a forensics firm mid-breach

If you have basic IR capability:

1. Write playbooks for your top 3 incident types (ransomware, account compromise, data exfiltration)
2. Pre-stage memory acquisition tools (winpmem, DumpIt) on critical servers
3. Enable Process Creation auditing (Event ID 4688) + PowerShell ScriptBlock logging
4. Test your logging: run a known bad tool (mimikatz in a lab) and verify your SIEM catches it
5. Practice: run tabletop exercises quarterly, live fire exercises annually

If you’re a DFIR practitioner:

• Add Chainsaw/Hayabusa to your triage workflow for faster Event Log analysis
• Build a Velociraptor infrastructure for remote collection at scale
• Automate evidence hashing and chain-of-custody documentation
• Write detection rules (Sigma) from every incident you work

Related Posts

• Windows Event Log Security Analysis — deep dive into specific Event IDs for detection and investigation
• Wazuh for Threat Hunting — open-source SIEM/XDR for DFIR evidence aggregation
• Ransomware Backup Strategy 2026 — IR-specific considerations for ransomware recovery
• LSASS Dumping Techniques — what attackers do to steal credentials, and the forensic artifacts they leave
• Canary Tokens for Deception and Blue Team Operations — early warning systems that give responders earlier detection
• Entra ID Attacks: Device Code, PRT, and Conditional Access Bypass — cloud IR and Entra ID investigation

Sources

• NIST SP 800-61r2: Computer Security Incident Handling Guide
• SANS DFIR Summit 2026
• Velociraptor DFIR Platform Documentation
• Windows Forensic Analysis: Practitioner’s Workflow 2026
• IBM Cost of a Data Breach Report 2025
• Rapid7 Velociraptor
• Computer Forensic Tools Comparison 2026 — Cyber Triage
• Forensic Focus: Digital Forensics Round-Up March 2026