Digital Forensics (DFIR) Guide

Most incident investigations fail on evidence, not analysis: the memory was never captured, the host was reimaged on day one, the cloud logs had already aged out, or nobody can show the image they analysed matches the disk they seized. Digital forensics is the part of digital forensics and incident response (DFIR) that turns a suspected compromise into a defensible account of what happened, when, through which account and with what data exposed. This guide covers evidence handling and chain of custody, the order of volatility, memory and disk acquisition, triage collection, the Windows artefacts that answer most questions, timeline building, network, email and cloud evidence, and tool validation. It is written for incident responders, SOC analysts and the engineers who make systems forensically ready. Running the response itself (roles, playbooks, retainers) is a separate discipline.

Key takeaways

• Collect first, analyse later. RFC 3227 puts it plainly: when you must choose, do collection first; work from the most volatile source (memory, network state) to the least volatile (disk, archives) and do not shut a host down until collection is complete.
• Integrity is a process, not a tool. Hash every acquisition at collection time (SHA-256), work only on verified copies, and record who held each item, when and how it was stored or transferred.
• Triage collection beats full images at scale. Targeted collection of the $MFT, USN journal, registry hives, event logs, Prefetch and Amcache answers most questions in minutes per host; reserve bit-stream images for the systems that matter most or may go to court.
• Logs you did not retain cannot be collected. Cloud and SaaS investigations are bounded by audit retention (180 days by default for Microsoft Purview Audit Standard), so forensic readiness starts with logging, retention and clock synchronisation.
• Expect anti-forensics. Timestomping (T1070.006), file deletion (T1070.004) and tampering with Windows event logging (T1685.001) are routine; corroborate every key timestamp from at least two independent artefacts.

What digital forensics adds to incident response

NIST SP 800-86 describes forensics "from an IT view, not a law enforcement view" and breaks it into four phases: collection (identifying, labelling, recording and acquiring data), examination (processing the data with automated and manual methods), analysis (drawing conclusions using legally justifiable methods) and reporting. ISO/IEC 27037:2012 covers the front end of that chain: identification, collection, acquisition and preservation of potential digital evidence across storage media, mobile devices, CCTV and networked systems.

The forensic workstream answers what containment and recovery depend on: how the attacker got in, which identities and hosts they used, what persistence they left, what data they touched, and whether they are still present. NIST SP 800-61 Rev. 3 frames this as CSF 2.0 outcomes RS.AN-03 (root cause), RS.AN-07 (incident data collected with integrity and provenance preserved) and RS.AN-08 (magnitude estimated and validated). Rev. 3 also notes that formal chain of custody "might not be performed for every incident", but collected data should still be treated as evidence.

• Internal investigation grade: hashes, notes and controlled storage; enough to support HR action, insurer claims and regulator questions.
• Litigation or prosecution grade: documented chain of custody for every item, validated tools, write-blocked acquisition and an examiner prepared, as RFC 3227 says, "to testify (perhaps years later)". Decide which grade applies at declaration; upgrading later is rarely possible.

Evidence handling and chain of custody

The same controls apply to a laptop disk, a memory image or a cloud audit log export.

• Record the clock: note the difference between the system clock and UTC before collecting (RFC 3227), and record every time in UTC with the offset.
• Hash at acquisition: compute a digest of the source (where readable) and of the image, then verify the copy against it. SP 800-86 (2006) names MD5 and SHA-1; both are now weak, so use SHA-256 as the primary hash.
• Block writes: attach physical media through a hardware write blocker, or a tested software blocker.
• Use forensically clean media: wipe and verify destination drives before use, and record the wipe.
• Document custody: RFC 3227 section 4.1 lists what to capture: where, when and by whom evidence was discovered and collected; handled or examined; who had custody and for what period; how it was stored; and when and how custody changed, including shipping numbers.
• Restrict and monitor storage: limit access to named examiners, log every access and make unauthorised access detectable (RFC 3227 section 4.2).
• Retain deliberately: SP 800-61 Rev. 3 (RS.AN-07) asks you to weigh possible prosecution against the cost of keeping data and the tools needed to read it later.

Order of volatility and live response

RFC 3227 gives the classic order of volatility; the right-hand columns add current collection practice.

RFC 3227's "things to avoid" still apply: do not shut down before collection is complete, do not trust binaries on the suspect system (run tools from trusted media or a signed agent), and avoid commands that update access times across the file system. It also warns that disconnecting a host can trigger "deadman switches" that destroy evidence. Network isolation through an EDR agent that keeps its own management channel (Microsoft Defender for Endpoint's Isolate device works this way) lets you contain a host and still collect memory and files from it.

Acquisition options compared

Small organisations without a forensic team should standardise on one triage collection (for example the KapeFiles _KapeTriage or _BasicCollection target set, or an EDR investigation package) and a memory tool, rehearse running them, and hand the output to their retained provider. Large organisations should pre-deploy a collection agent such as Velociraptor across the estate, keep a full-imaging kit for the few cases that need it, and write cloud acquisition into automation. Velociraptor's documentation warns that a basic triage set can run to several GB per host, so hunt fleets with targeted queries.

Memory forensics

Memory is the only place to see code that never touched disk, live sockets and injected regions. Capture it before rebooting, patching or running remediation tools.

• Windows acquisition: WinPmem (Apache-2.0) writes raw images through a signed driver.
• Linux acquisition: Microsoft's AVML is a static userland binary that reads /dev/crash, /proc/kcore or /dev/mem and writes LiME format; it cannot acquire memory when kernel lockdown is enabled, so test this on your distributions before you need it.
• Analysis: Volatility 3 needs symbol tables matched to the exact kernel. Core Windows plugins include windows.pslist and windows.pstree (process listing), windows.cmdline, windows.dlllist, windows.handles, windows.filescan and windows.dumpfiles; the malware set includes malfind, hollowprocesses, ldrmodules and psxview for injected or hidden code; registry plugins include hivelist, printkey and userassist.
• Pagefile and hibernation file: collect pagefile.sys and hiberfil.sys with the disk triage; they can hold memory content from before the incident was noticed.

Windows artefacts that answer most questions

Registry hives (SAM, SYSTEM, SOFTWARE, SECURITY and each user's NTUSER.DAT) provide services, autoruns, USB history, user accounts and network profiles. Treat every artefact as one witness: Amcache shows a binary existed, Prefetch shows it ran, a 4688 event shows who ran it with which command line, and SRUM shows how much it sent.

Timelines and super timelines

A timeline puts every timestamped artefact on one axis so that gaps, sequences and anomalies become visible. Plaso, the engine behind log2timeline, creates "super timelines" by default from disk images, file systems, registry files, SQLite databases and text logs. The quickest route is psteal.py --source image.raw -o dynamic -w timeline.csv; the two-step route is log2timeline.py --storage-file timeline.plaso image.raw followed by psort.py -o dynamic -w timeline.csv timeline.plaso, which lets you re-filter without re-parsing.

1. Normalise time: convert everything to UTC and record source time zones and known clock drift before merging host, network and cloud data.
2. Filter the known: use the NIST National Software Reference Library (NSRL) Reference Data Set, a collection of digital signatures of known software, to set aside known operating system and application files.
3. Pivot from anchors: start from a confirmed event (an alert, a malicious file hash, a suspicious logon) and work outwards in both directions, rather than reading the timeline end to end.
4. Test timestamps: MITRE ATT&CK T1070.006 notes that $SI timestamps can be changed with user-mode APIs while $FN is kernel-managed, and that attackers may "double timestomp". Corroborate with the USN journal, Prefetch and event logs.
5. Write as you go: keep a running narrative with artefact references.

Network, email and cloud evidence

• Network forensics: full packet capture (pcap or pcapng) is short-lived and expensive, so most investigations rely on flow records, firewall, proxy and DNS logs. ISP-held logs typically need a court order (SP 800-86). Network forensic analysis tools (NFAT) reconstruct sessions from captured traffic; capture at egress points and in front of crown-jewel systems.
• Email forensics: preserve messages in original format with full headers and the Message-ID. For Microsoft 365 mailbox compromise, the MailItemsAccessed audit action records access by every protocol: Sync events mean a whole folder should be treated as exposed, Bind events identify individual messages by InternetMessageId. Query with Search-UnifiedAuditLog -Operations MailItemsAccessed and match ClientIPAddress and SessionId to attacker activity.
• Audit retention: Microsoft Purview Audit (Standard) retains records for 180 days by default; Audit (Premium) keeps Exchange, SharePoint, OneDrive and Entra records for one year for E5 users, and up to ten years with an add-on. Export what you need on day one.
• IaaS forensics: AWS prescriptive guidance shows an automated pattern: tag the instance, capture memory (LiME) and disk, then contain it with a security group that allows no inbound or outbound traffic and an IAM role that denies all actions, storing artefacts in a separate forensics account with an analysis network that has no internet access. AWS states that the pattern is not intended to produce evidence "submissible in court", so add hashing and custody records if you need that.
• SaaS forensics: you cannot image a SaaS platform; evidence is the provider's audit and API logs, bounded by licence tier and retention.

Where identity fits

Most modern intrusions are investigated through identity evidence: which account authenticated, from where, with which token, and what it then did. Forensic scoping should list every human and non-human identity the attacker used or could have read, including service accounts, API keys, OAuth grants and cloud access keys found in memory, scripts, browser stores or CI logs. Cloud audit events record the access key or application ID used, which lets you trace a stolen credential across services. See the Leaked Credential Response Playbook and the ITDR Guide.

Tooling and tool validation

NIST's Computer Forensics Tool Testing (CFTT) programme publishes test methods and results for disk imaging, hardware and software write blocking, deleted file recovery, file carving, mobile devices, cloud data extraction, Windows Registry tools and SQLite. Before relying on a tool for evidence, check its CFTT results where they exist, validate new versions against reference images such as NIST's Computer Forensic Reference Data Sets (CFReDS), and record tool names and versions in your notes.

Forensic readiness and measurement

Rolling out readiness

1. Set logging and time first: enable process creation auditing with command lines, forward logs off-host, synchronise all clocks to a common source, and set cloud and SaaS audit retention to at least the time you take to detect an intrusion.
2. Write the evidence procedure: collection order, hashing standard, custody form, evidence storage, and who decides between internal and litigation grade.
3. Pre-position tools: deploy the collection agent or confirm EDR live response rights; stage memory tools and clean media; build a cloud forensics account and pre-approved isolation roles.
4. Pilot on a small ring: run triage and memory collection on a test group, measure time and size per host, and confirm no performance or stability impact. Roll back by removing the agent or collection policy if it misbehaves.
5. Validate: process a reference image end to end, compare results with expected answers, and document tool versions.
6. Exercise: run a collection drill on a live-like host at least twice a year, including a cloud workload and a mailbox.

Detection and metrics

Monitor for activity that destroys evidence: Security event 1102 (log cleared), changes to audit policy or the EventLog service (ATT&CK T1685.001 Disable or Modify Windows Event Log), $SI and $FN mismatches (T1070.006), mass deletion of tools after use (T1070.004), and deletion of volume shadow copies.

• Collection coverage: percentage of servers and endpoints from which triage and memory can be collected remotely.
• Time to first evidence: median minutes from declaration to a verified triage package from the first affected host.
• Retention headroom: log retention in days for each critical source, compared with your median dwell time.
• Integrity record: percentage of evidence items with a recorded hash, verification and complete custody entry.
• Clock health: percentage of hosts within one second of the reference time source.

Common failure patterns

• Reimaging before collecting: the fastest way to lose the root cause. CISA's federal incident response playbook says to capture a memory and disk image when an endpoint needs forensic analysis, and to collect all evidence before eradication.
• Logs that were never there: in the Microsoft Storm-0558 Key Breach, a US government customer spotted the intrusion through mail access audit events that, at the time, came with premium logging; organisations without them had little to investigate with.
• Analysing originals: mounting a suspect disk read-write or opening evidence files in place changes timestamps and breaks integrity.
• Trusting a single timestamp: building the attack timeline from $SI times or one log source without corroboration.
• Forgetting non-human credentials: scoping only user accounts and missing keys and tokens the attacker harvested, which keeps the door open after recovery.
• Evidence stored in the blast radius: collections written to a share or cloud bucket the compromised admin accounts can reach.

Framework mapping

Practitioner checklist

• Publish an evidence procedure covering order of volatility, SHA-256 hashing, custody records and evidence storage.
• Confirm you can capture memory remotely from Windows and Linux hosts, including those with kernel lockdown.
• Standardise one triage collection set and measure its time and size per host.
• Set cloud and SaaS audit retention to exceed your detection time, and export logs on day one of an incident.
• Synchronise clocks and record UTC offsets in every collection.
• Validate tools against reference data and record versions in case notes.
• Include API keys, tokens and service accounts in forensic scoping.
• Alert on log clearing, audit policy changes and shadow copy deletion.

Standards and references

• NIST: SP 800-86, Guide to Integrating Forensic Techniques into Incident Response
• IETF: RFC 3227, Guidelines for Evidence Collection and Archiving
• ISO: ISO/IEC 27037, Guidelines for identification, collection, acquisition and preservation of digital evidence
• NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• NIST: Computer Forensics Tool Testing Program (CFTT)
• NIST: National Software Reference Library (NSRL)
• MITRE ATT&CK: T1070.006 Indicator Removal: Timestomp
• Microsoft Learn: Use MailItemsAccessed to investigate compromised accounts

Related NHI Mgmt Group resources: Windows Event Log Guide · ITDR Guide · Leaked Credential Response Playbook · EDR Evasion and Defence Guide · Ransomware Prevention Guide