Forensic Imaging And Analysis

Forensic imaging is the process of creating a bit-for-bit copy of storage media in a way that preserves the original, produces a verifiable duplicate, and supports later analysis against the copy rather than against the original. Forensic analysis is what happens on the copy: file-system reconstruction, deleted-file recovery, memory-process review, registry analysis, timeline construction, and indicator-of-compromise extraction.

The goal of the whole exercise is to answer questions about what happened on a specific piece of hardware at a specific point in time, and to answer them in a way that a skeptical party reviewing our work could reproduce from the same evidence. Good imaging is the foundation. Good analysis is the value add. We do both in a single integrated workflow so the handoff between acquisition and analysis does not introduce errors or gaps.

This page gives you the practical detail behind our imaging-and-analysis service. It covers the preservation order we follow, the open-source toolkit we use, the hash verification practice, how we handle chain of custody, and where to escalate when a case calls for tools or licensure outside our scope. It is written for IT leaders, compliance officers, and counsel who want to understand what they are paying for when they engage us.

Write-Blocking Hardware

Before any source drive is connected to the acquisition workstation, it goes through a hardware write-blocker. Tableau and WiebeTech are our field workhorses. The write-blocker physically prevents any command from the acquisition workstation from modifying the source drive, which means the evidence cannot be altered during acquisition even by accident. This is a foundational control. Without write-blocking, a Windows host auto-mounting a suspect drive and dropping System Volume Information directories on it is enough to compromise the evidence.

Raw Imaging With dd And dc3dd

For format-neutral raw images we use dd or its forensic-focused sibling dc3dd. A typical invocation looks like this:

sudo dc3dd if=/dev/sdX of=/evidence/case-123/suspect-disk.img \
  hash=md5 hash=sha256 log=/evidence/case-123/acquisition.log

The command images the entire source device sector by sector into a raw image file while computing MD5 and SHA-256 hashes on the fly and writing a log of every action taken. The resulting .img file is format-neutral and readable by almost any forensic tool.

Expert Witness Format With libewf

For compressible evidence or cases where embedded metadata matters, we use ewfacquire from the libewf project to produce Expert Witness (E01) format images. The E01 format embeds acquisition metadata, hash values, and case information directly in the file, which makes later chain-of-custody documentation cleaner. Invocation:

sudo ewfacquire -t /evidence/case-123/suspect-disk \
  -c bzip2 -l /evidence/case-123/acquisition.log \
  -C case-123 -D "Workstation imaged for BEC investigation" \
  -E "case-123-e001" -e "Lead Examiner" -N "Case 123 disk acquisition" \
  /dev/sdX

The tool walks an interactive prompt for case metadata and produces one or more .E01 files plus a log, all hashed and ready for transport.

Volatile Memory Capture

Where the host is still running and memory matters (almost always), we capture volatile memory before anything else touches the system. For Windows we run winpmem to disk or across the network, for Linux we load the lime kernel module, for macOS we run OSXPmem while being realistic that Apple Silicon SIP constraints limit what user-space memory acquisition can capture. Memory images are compressed, hashed, and treated with the same chain-of-custody discipline as disk images.

Digital evidence has a lifespan. Some of it disappears in seconds, some in minutes, some lasts for years. The order of volatility concept comes from RFC 3227 and has been the standard preservation ordering in the forensics community for over two decades. Our acquisition workflow follows it.

1. CPU registers, cache, and pipeline state. Seconds of lifespan. Captured only if a running system can be probed with live-response tooling before it shuts down.
2. Routing tables, ARP cache, process tables, kernel statistics. Minutes of lifespan. Captured through live-response scripts that run authorized commands on the live host.
3. Physical memory. Minutes to hours of lifespan depending on how the machine is handled. Captured with winpmem, lime, or OSXPmem before any shutdown or reboot.
4. Temporary filesystems and swap. Lifespan of reboot cycles. Captured through live-response or through disk imaging once the host is isolated.
5. Persistent disk storage. Stable on the timescale of hours to days. Imaged with write-blocking and hash verification after volatile capture completes.
6. Remote logging and cloud telemetry. Stable on the timescale of the retention policy. Preserved through vendor-native export.
7. Physical configuration. Stable on the timescale of physical changes to the environment. Documented from asset management, switch and firewall configurations, and photographs of the physical setup.
8. Archival media. Stable on the timescale of months to years. Acquired as needed once the urgent collection is complete.

The order matters because skipping a high-volatility source to grab a lower-volatility one first is how evidence gets lost. A careful examiner always thinks through the list and documents which items were in scope, which were out of scope, and why.

Every forensic image we produce is hashed twice. MD5 is computed alongside SHA-256 for every evidence file. The hashes are recorded at three points: at the source before imaging completes, on the destination image file after imaging completes, and again on the image file before analysis begins.

Why Two Algorithms

MD5 has known collision vulnerabilities and is no longer considered cryptographically secure, but it is still the de-facto standard in many forensic workflows, legal tools, and evidence-management systems. Abandoning MD5 would break interoperability with systems our clients' counsel already use. SHA-256 is the modern standard, collision-resistant, and the one we rely on for actual integrity verification. Including both in every record lets us satisfy both audiences without forcing anyone to choose.

Hash Timing

A hash taken only at the end of imaging does not prove the source was unchanged by the imaging process. That is why dc3dd and ewfacquire compute hashes during the imaging operation, reading the source one time and producing both the image file and the hash in parallel. If the source changes mid-image, the computed hash will not match a subsequent read and the discrepancy surfaces immediately.

Hash Verification In Practice

When we mount an image for analysis, the first step is to regenerate its SHA-256 and compare against the acquisition-time value. A match means the image is bit-for-bit identical to what was acquired. A mismatch halts analysis and triggers a root-cause investigation. In eight years of running this workflow, mismatches have been vanishingly rare and always attributable to storage media failure rather than evidence tampering, but the discipline is what makes that confidence possible.

Example Hash Record

Evidence ID:  CASE-123-DISK-001
Source:       /dev/sdX (1 TB Samsung SSD, serial S123ABC)
Acquired:     2026-04-18 14:32:17 EDT
Examiner:     Lead Forensic Analyst
Method:       dc3dd, write-blocked via Tableau T35u
Image Path:   /evidence/case-123/suspect-disk.img
MD5:          b1946ac92492d2347c6235b4d2611184
SHA-256:      7f83b1657ff1fc53b92dc18148a1d65dfc2d4b1fa3d677284addd200126d9069
Verified:     2026-04-18 14:58:04 EDT (post-acquisition re-hash matches)

Chain of custody is a written record, kept in parallel with physical evidence handling, that lets any reader reconstruct where a piece of evidence was, who had access, and what was done to it, from the moment it entered our control until the moment it left. We keep chain-of-custody records on paper and in an encrypted digital case-management system in parallel, with paper as the authoritative version.

Every evidence item gets its own form. The form starts at acquisition with the evidence identifier, source description, acquisition method and tool, cryptographic hashes, acquiring examiner, and date and time. Every subsequent movement (transport, storage location change, hand-off to another examiner, access for analysis, return to client, destruction) is recorded on the form with date, time, and the name of the handling person. Handoffs to third parties (counsel for inspection, law enforcement for seizure, a second examiner for peer review) are captured with a signed receipt from the receiving party.

Forms are reviewed at case close and bound with the final report. The complete chain of custody for every piece of evidence referenced in the report is preserved for the duration of the engagement letter's retention period and provided to counsel on request. The discipline is boring on purpose. An opposing expert who reads our chain-of-custody record should find nothing novel and no unexplained gaps.

Once a verified working copy of the evidence is loaded into our analysis environment, the real investigation begins. The specific analytical path depends on the case. A BEC investigation leans on mailbox artifacts, registered OAuth grants, and audit-log correlation. A ransomware case leans on process execution history, persistence mechanism enumeration, and malware family identification. A crypto-theft case leans on browser history, messaging-app exports, and on-chain transaction tracing. The techniques below are the common core that shows up in some form in almost every engagement.

Timeline Reconstruction

A forensic timeline stitches together filesystem metadata, application artifacts, log entries, and system events into a single chronological view of what happened on the host. The Sleuth Kit produces filesystem timelines (MFT records on NTFS, inode metadata on ext4). Autopsy overlays Windows event logs, browser history, and application-specific artifacts. Registry extraction pulls USB insertion history, program execution records (AmCache, ShimCache, Prefetch), and user activity indicators. Everything gets normalized into a unified timeline with minute-level precision where the source supports it.

Deleted File Recovery

Files that were deleted but not overwritten can often be recovered from unallocated space. The Sleuth Kit's fls and icat recover filesystem-aware deleted files. PhotoRec does signature-based recovery for files that have been unlinked from the filesystem entirely. Where TRIM has run on an SSD, recovery is often not possible, and we document the SSD-aware constraint in the methodology section rather than pretending a full recovery is available.

Memory Analysis

Volatility 3 against a memory image gives us running process lists, DLL loads, code injection indicators, hidden processes, network connections at the moment of capture, credential material, and registry hive content from the page cache. Memory analysis is often where active intrusions reveal themselves most clearly because many malware families never touch disk.

Indicator Hunting With Yara

Yara rules let us sweep an entire disk image, memory image, or file collection for matches against known malware signatures, command-and-control indicators, and case-specific patterns. Public Yara repositories cover most common malware families. For targeted investigation we often author case-specific rules that target a specific threat actor's unique artifacts.

Registry And Event Log Analysis

Windows registry and event logs together tell most of the story of what happened on a Windows host. User logons, privilege escalations, service installations, scheduled task creation, RDP sessions, PowerShell execution, and many attacker persistence mechanisms land somewhere in these sources. We extract, normalize, and correlate registry and event log data across the relevant hosts to reconstruct attacker activity.

Browser And Application Artifacts

Chrome, Edge, Firefox, and Safari all leave rich artifact trails: browsing history, download history, autofill data, session cookies, and credential storage. Email clients (Outlook, Apple Mail, Thunderbird) leave message databases, calendar records, and contact lists. Cloud-synced applications (OneDrive, Dropbox, Google Drive) leave sync logs and local cache that shows what files were accessed. All of these are part of the analyst's toolkit for reconstructing user and attacker behavior.