Forensic Disk Imaging and Chain of Custody for Incident Response

Three tools cover 95% of physical disk imaging. FTK Imager is the GUI-driven choice, free from Exterro, runs on Windows, and produces E01 or raw images with built-in hashing. It's the right tool for one-off acquisitions, on-site work where the responder may not be deeply technical, and any case where a clear visual workflow matters. The downside is Windows-only and limited scripting. dc3dd is the DoD-modified dd, available on most Linux distributions, and the right tool for scripted acquisitions, large-volume imaging, and when you need raw dd format. It computes hashes inline (MD5, SHA1, SHA256, SHA512) and writes a log file with progress and verification. Use dc3dd when you're imaging from a Linux examiner workstation with a hardware write blocker. ewfacquire from the libewf project produces E01 (EnCase) format from any source, runs on Linux and macOS, supports compression, and is the preferred tool when you need E01 interoperability with EnCase or X-Ways for downstream analysis. For unusual sources (network shares, RAID arrays), Guymager is worth knowing about; it's a Linux GUI tool that handles segmented images and parallel hashing well. Avoid plain dd for evidentiary work; its lack of integrated hashing and error handling makes it a poor evidence-grade tool.

Hardware write blockers are the courtroom standard. Tableau (Guidance/OpenText) and WiebeTech (CRU) make the most widely accepted units, with SATA, SAS, USB, and PCIe variants. A T356789iu or T35u from Tableau handles SATA and IDE; the Forensic UltraDock handles multiple interfaces. Hardware blockers physically prevent write commands from reaching the source disk; they cannot be circumvented by examiner error or OS misconfiguration. Use hardware whenever the case might reach litigation or law enforcement involvement. Software write blockers (Windows registry tweaks, Linux mount with ro and blockdev --setro) are acceptable for internal investigations where evidentiary chain is not the priority. The risk with software blockers is that an OS update or examiner mistake can re-enable writes; always verify the blocker is active by attempting a write and confirming failure before connecting the evidence drive. For NVMe and SSD evidence, the wear-leveling and TRIM behavior complicates the blocker story; some Tableau models handle NVMe natively, while older blockers don't. Verify your blocker supports the interface you need before the case starts; don't discover incompatibility at the scene.

Three formats dominate. Raw dd (.dd, .img, .raw) is a bit-for-bit copy with no metadata. Pros: maximum tool compatibility, can be analyzed by anything that reads block devices, no proprietary parsing needed. Cons: no built-in compression (full size of source disk required), no integrated case metadata, no integrated hash storage. Use raw dd when you need maximum compatibility or you're going to feed the image into a tool that doesn't read containerized formats. EnCase E01 format (.e01, .e02 for segments) is the legal industry standard. Includes case metadata, examiner name, evidence number, embedded hash, and compression. Most commercial forensic tools (EnCase, X-Ways, FTK, Autopsy, Magnet AXIOM) read E01 natively. Use E01 when you're handing off to a third party or expecting the case to involve commercial forensic analysis. AFF4 is the modern open-source alternative, supports very large images, deduplication, and is the format of choice for advanced research workflows. Tool support is more limited; Autopsy and pyaff4 read it well, but commercial tools are inconsistent. Use AFF4 when storage cost matters and you control the analysis toolchain. For most engagements, default to E01 unless you have a specific reason otherwise.

Roughly half of modern IR engagements involve cloud or virtualized assets. The methodology differs significantly from physical acquisition. For AWS EC2, the standard procedure is: identify the instance, take an EBS snapshot of every attached volume, copy the snapshot to a forensic AWS account (cross-account share), then create a new EBS volume from the snapshot and attach it to a forensic analysis instance as read-only. The snapshot itself is the evidence; document the snapshot ID, source volume ID, instance ID, region, and account at the time of acquisition. For Azure, use managed disk snapshots and the same cross-subscription pattern. For VMware, take a snapshot through vCenter (this includes memory if VM is running, which you usually want), then copy the VMDK files to the forensic workstation. Cellebrite, Magnet AXIOM, and Velociraptor all have cloud acquisition modules; the manual procedure works just as well and gives you complete control. Memory acquisition for VMs is via the VMware vmss file or the Azure capture-memory feature; for AWS EC2, memory acquisition requires running an agent in the instance prior to compromise (LiME, AVML) since there's no out-of-band memory access. Document the cloud provider's audit log entries showing the snapshot creation; those entries are part of your chain of custody.

Hashing is the mechanism that proves the image is unchanged from acquisition through analysis. The discipline is: hash at acquisition, verify after every transfer, hash again at analysis start. Use SHA256 as the primary hash and MD5 as a secondary. MD5 is cryptographically broken for adversarial collision resistance, but it remains useful for integrity verification and is still expected by some legal workflows. Both hashes go in the chain of custody document. At acquisition, FTK Imager and dc3dd compute hashes inline; capture them in the tool's log and transcribe to your case notes. After acquisition, before the source disk is disconnected, perform a verification pass: re-read the image and compute the hash again, comparing to the original. If they don't match, the image is suspect; investigate before disconnecting the source. When transferring the image between storage (lab workstation to evidence vault, evidence vault to analyst workstation), compute the hash after each transfer and document the match. Use sha256sum or certutil -hashfile depending on platform. Build a hash log per case: filename, SHA256, MD5, date, examiner, transfer event. When the case closes, the log goes in the evidence package.

Chain of custody is the documented history of who handled the evidence, when, why, and what they did to it. It's the difference between admissible evidence and a story. The minimum required fields per entry: date and time (with timezone), name of person handling the evidence, what they did (acquired, transferred, analyzed, sealed, returned), the resulting hash if any transformation occurred, the storage location after the action, and a signature. Use a standardized form; templates from NIST SP 800-86 Appendix or SANS DFIR cheat sheets work. Maintain physical chain of custody for any physical evidence: sealed evidence bags with tamper-evident seals, locked evidence storage with logged access, signed transfer slips between examiners. For digital-only acquisitions (cloud, VM), the chain is logical: who exported the snapshot, what hash was produced, where it was stored, who accessed it for analysis. Tools that automate this exist (Magnet AXIOM Process, X-Ways' case management) but a well-maintained spreadsheet plus signed PDFs works for smaller engagements. The key test: if you handed the case to an outside attorney or law enforcement two years from now, could they reconstruct exactly what happened to the evidence from your records? If not, the chain is broken.

Not every system can be taken offline for imaging. Production servers, encrypted systems where the decryption key is in memory, and cloud workloads where snapshotting is operationally disruptive all require live triage instead of full acquisition. KAPE (Kroll Artifact Parser and Extractor) and Velociraptor are the two dominant tools. KAPE runs as a Windows tool, collects targeted artifacts (registry, event logs, browser history, NTUSER.dat, prefetch, AmCache, ShimCache) in minutes, and produces a structured output for analysis. Run KAPE from a USB drive or network share; it does not install. Velociraptor is the longer-term answer: an agent-based platform that runs persistent on endpoints and supports remote hunt queries. For an IR engagement, deploy Velociraptor to the suspect system, run targeted VQL queries to collect the artifacts you need, and export the results. Both tools change the running state of the system (touched files, created processes); document this in the chain of custody. Live triage is not a substitute for full imaging when full imaging is possible; it's the right answer when full imaging is not. Memory acquisition during live triage is critical: use WinPMEM, AVML, or LiME to capture RAM before any other action that might overwrite memory contents.