CFCE common mistakes
CFCE · Understand the traps and how to avoid them.
Imaging a drive without first taking a verified write-blocked path, then discovering the acquisition workstation mounted the source volume read-write and altered timestamps before hashing.
Candidates chase the acquisition step first because it feels like 'the real forensic work' and skip the readiness step of confirming hardware or software write-blocking, disabling automount, and documenting the block. On Windows and macOS the OS auto-mounts new volumes by default, so a single unblocked connection can write journal, access, and mount-count changes.
What to do instead
Before any acquisition, verify and record the write-blocker (model, serial, firmware, validation hash) or the software-block setting, disable automount on the acquisition host, and test the block with a known non-evidentiary device. Document the block in the case notes and reference it in the acquisition report; if a block was missed, disclose the deviation and its likely effect rather than omitting it.
Computing only a single hash algorithm (or none) and failing to re-hash after transfer, so the report cannot demonstrate that the working copy matches the source.
Candidates treat hashing as a one-time checkbox at acquisition and forget the verification half of the workflow. They also confuse a hash of the image file with a hash of the source device, or omit the hash of the working copy after each copy or restore operation.
What to do instead
Record at least two independent algorithms (for example SHA-256 and SHA-1 or MD5) for the source and the image, state the tool and version used, and re-hash the working copy at every transfer and before analysis. Present a hash table in the report linking source, image, and working copy, and explain any mismatch before drawing conclusions.
Rebuilding a timeline or carving deleted files from the live original evidence instead of a verified working copy, and writing tool output back onto the evidence drive.
It is faster to point a tool at the original drive, and candidates underestimate how much a tool writes (indexes, logs, thumbnails, prefetch, registry). They also assume 'read-only mount' is safe when the mount itself can update access times or journal state.
What to do instead
Work only from a hash-verified image or a write-blocked copy, keep the original sealed, and direct all tool output, case databases, and temp files to a separate analysis volume. Note the working-copy hash in the report and describe how the original was stored.
Documenting chain of custody as a single signature line rather than a continuous record of every transfer, with dates, times, locations, and purposes.
Candidates recall that chain of custody matters but not that it is a chronological log with an unbroken sequence. They also backfill entries later, use vague descriptions ('drive in evidence room'), or leave gaps that opposing counsel can exploit.
What to do instead
Maintain a custody form with one row per transfer: date/time, from, to, purpose, storage location, seal number, and signatures. Record the moment of seizure, every handoff, every analysis session, and every return. If a gap exists, document it honestly with an explanation rather than reconstructing it.
Treating deleted-file recovery as a single 'undelete' action and reporting recovered files without checking whether the data clusters were reused, or ignoring that the file system overwrites metadata before content.
Candidates learn one recovery tool and assume a successful recovery means the original content. On NTFS the MFT entry may be reallocated, on FAT the directory entry may be cleared, and on ext4 the inode may be zeroed; carving may return a file whose content belongs to a different allocation.
What to do instead
State the file system and its deletion behaviour, check metadata (MFT record status, inode link count, FAT directory entry) before claiming recovery, and distinguish metadata-based recovery from signature-based carving. Verify carved output against file headers, footers, and internal structure, and report recovered files as 'candidate' with confidence and limitations.
Misinterpreting Windows artifacts by reading a single registry key or prefetch file in isolation, without accounting for time zone, user context, or artifact version differences across Windows releases.
Candidates memorize artifact locations but not their semantics: FILETIME is UTC, prefetch format changed between Windows versions, Amcache and ShimCache record different things, and a key under one user's hive does not prove that user performed the action.
What to do instead
For each artifact, state the source hive or file, the Windows version, the time basis (UTC vs local), and what the artifact does and does not prove. Corroborate with at least one independent artifact (event log, LNK, jumplist, browser history) before attributing an action to a user, and normalize all times to a single zone in the timeline.
Presenting carved or recovered email and browser evidence without validating that the message headers, attachments, or cache entries are complete and unaltered, and without a defensible time correlation.
Webmail and browser caches store fragments, and email headers can be forged or truncated. Candidates extract a 'From' line or a cached page and treat it as authoritative, ignoring SMTP header analysis, message-ID, and time zone offsets in Date headers.
What to do instead
Analyze full headers (Received chain, Message-ID, Date with offset), verify attachments by hash, and distinguish server-side from client-side copies. For browser evidence, record the profile, database version, and record offsets, and explain cache eviction and sync effects. Correlate with independent logs and state time zone conversions explicitly.
Acquiring a mobile device by powering it on or connecting it normally, triggering sync, remote wipe, or backup overwrite, instead of preserving the device state first.
Candidates apply desktop habits to phones, where network connectivity and normal boot can alter or erase evidence. They also assume a logical extraction is equivalent to a physical one and do not document the isolation method.
What to do instead
Isolate the device (Faraday bag or airplane mode with documented steps), record the state and battery, and choose the least invasive extraction that answers the question. Document the tool, method (logical, file system, physical), and any changes made, and state the limitations of the extraction level in the report.
Writing a report that lists tools and findings without an opinion, methodology, limitations, or a clear statement of what the evidence does and does not support.
Candidates conflate a technical dump with a forensic report and omit the reasoning chain. They also fail to distinguish observation from inference and do not record tool versions, validation status, or known error rates.
What to do instead
Structure the report as scope, authority, methodology, findings with supporting exhibits, limitations, and conclusions. Tie each conclusion to specific evidence and state confidence. Include tool names, versions, validation references, and any deviations from standard procedure, and have a peer review the report before release.
Relying on a tool's default output as validated truth without checking its configuration, testing it against known data, or documenting its limitations and error rate.
Candidates trust familiar tools and skip validation because it feels like extra work. Defaults can change parsing behaviour (time zone, encoding, carving thresholds), and untested tools can silently miss or mislabel artifacts.
What to do instead
Record tool name, version, configuration, and any plugins. Validate against known test images or internally generated samples, keep a validation log, and cross-check critical findings with a second tool or manual inspection. In testimony, be able to explain how the tool works, its limits, and what you did to confirm its output.