CCFH common mistakes
CCFH · Understand the traps and how to avoid them.
Treating file modification, access, and metadata-change timestamps as interchangeable, or asserting that a file was opened at the time recorded in the access timestamp without accounting for filesystem mount options and lazy-update behaviour.
Candidates memorise the NTFS timestamp names but never learn that access-time updates are suppressed or deferred by default on modern Windows and by noatime/relatime mounts on Linux, so they read a stale timestamp as proof of user interaction.
What to do instead
For every timestamp assertion, state the filesystem, the mount or registry setting governing that timestamp, and the granularity (NTFS 100 ns resolution versus FAT 2-second write time). Practise building a timeline from a small image and explicitly annotating which timestamps you distrust and why.
Computing a hash of the acquired image and comparing it to a hash of the original drive, then declaring verification successful, without documenting that the source hash was taken before imaging and that the acquisition tool wrote in a verifiable mode.
The exam phrase 'verify the image' tempts candidates to describe a single post-hoc hash comparison, but verification requires a known-good source value and a tool that reports read errors and bad sectors rather than silently substituting zeros.
What to do instead
Write out the full sequence: source hash, acquisition with error logging and write-blocking, image hash, comparison, and storage of the hash log in the case file. Be able to name what a mismatch implies and how to re-acquire.
Describing chain of custody as a single signed form at seizure and omitting every subsequent transfer, storage location, and access event, or failing to note that a hash was re-verified after each transfer.
Candidates conflate 'documented' with 'documented once', and the exam scenarios often describe evidence moving between a scene, a locker, and a lab without stating the intermediate steps.
What to do instead
For any scenario, narrate the custody chain as a sequence of custody events, each with who, what, when, where, and why, plus hash re-verification at receipt. Practise spotting the gap in a described chain and stating the specific record needed to close it.
Concluding that deleted data is unrecoverable because the file was overwritten or the partition was formatted, without distinguishing quick format, full format, TRIM, and secure-erase behaviour on the specific media type.
Candidates apply a single mental model of deletion across NTFS, ext4, APFS, and flash storage, ignoring that TRIM and garbage collection can destroy unallocated content within minutes on SSDs while a quick format leaves metadata largely intact.
What to do instead
Build a table mapping deletion and format operations to what survives on each filesystem and media type, and practise carving from unallocated space and from $MFT/$LogFile or journal remnants. State the media type and its wear-levelling implications in every recovery answer.
Presenting a tool's parsed output as the finding, for example quoting a browser history database row or a prefetch entry as proof of execution or intent, without validating the underlying record against a second source.
Candidates trust GUI output because it is convenient, and they do not know which artefacts are trivially forgeable or which parsers silently mis-handle time zones and version changes.
What to do instead
For each artefact you cite, name its on-disk source, its known limitations, and one corroborating artefact (for example, prefetch plus ShimCache plus event logs). Practise manual parsing of at least one binary artefact so you understand what the tool is doing.
Writing conclusions that assert a person performed an action, rather than describing what the artefact shows and the confidence level, or conversely hedging so heavily that no opinion is offered at all.
Candidates swing between overclaiming from technical data and refusing to interpret it, because they have not practised the distinction between artefact-level findings and attribution-level opinions.
What to do instead
Draft findings in two layers: observed fact with its source and hash, then interpretation with stated assumptions and alternatives considered. Practise answering cross-examination style questions about the limits of your own conclusion.
Ignoring time zone and clock-skew handling, mixing UTC and local timestamps in one timeline, or failing to account for a suspect machine's clock offset when correlating with server logs.
Tools normalise timestamps silently and candidates rarely check the display setting, so a timeline built in local time will misorder events relative to network evidence recorded in UTC.
What to do instead
Normalise every timeline to UTC, record the source time zone and any measured clock offset per device, and state the correction applied. Practise correlating a host artefact with a server log across a deliberate skew.
Handling a live mobile device or cloud account by immediately connecting it, powering it on, or logging into the account, without considering remote wipe, encryption state, or the effect on authentication logs.
Candidates apply desktop habits to phones and cloud services, where network connection can trigger wipe commands or sync that overwrites evidence, and where a login creates new artefacts that contaminate the account history.
What to do instead
State an isolation decision first (Faraday bag, airplane mode, network isolation), then the acquisition path (physical, file system, logical, or provider preservation request), and note what each preserves and destroys. For cloud, describe the legal process and the provider-side preservation before any access.
Confusing containment, eradication, and recovery during an incident, or recommending reimaging before volatile evidence such as memory and network connections has been captured.
Candidates learn the response phases as a list but not their ordering constraints, so they propose a clean rebuild that destroys the very artefacts needed to scope the intrusion.
What to do instead
For each scenario, state the evidence to capture before each action, then map actions to phases explicitly. Practise ordering a response to a ransomware or beaconing incident where memory capture and lateral-movement scoping must precede remediation.
Describing a legal standard loosely, for example saying evidence must be 'beyond reasonable doubt' in every context, or ignoring jurisdictional admissibility rules and the distinction between authentication and reliability.
Candidates mix criminal and civil burdens, and they do not separate the gatekeeping question of whether evidence is authentic from the weight a trier of fact gives it.
What to do instead
Learn the specific standard attached to each proceeding and the authentication requirement for digital records in the relevant jurisdiction, and practise stating which standard applies and why in a short scenario. Keep statutory citations to those you can state accurately.