CF-L3 / CCFT common mistakes
CF-L3 / CCFT · Understand the traps and how to avoid them.
Answering a question about whether an acquisition was 'forensically sound' by naming the tool used ('we used a hardware imager, so it's sound') rather than describing the validated process - write-blocking, hash verification, documented procedure, and known error rate.
Candidates learn tool names as shorthand for credibility and are trained on product marketing rather than on the underlying principles of repeatability and integrity.
What to do instead
Answer in process terms every time: state the write-block method, the hash algorithm and both hash values, the tool version and its validation/testing basis, and the documentation trail. Reserve tool names for describing implementation, never as the justification itself.
Applying the wrong admissibility framework or authority to a scenario - invoking Daubert in a jurisdiction that still uses Frye, or importing criminal-procedure warrant requirements into a civil or internal-investigation context (or vice versa) without discussing consent, subpoena, or policy authority.
Study material is often US-federal-centric, so candidates pattern-match 'expert evidence = Daubert' and 'search = warrant' and stop analysing the facts the scenario actually gives.
What to do instead
Before answering, identify three things explicitly: the forum (criminal/civil/regulatory/internal), the jurisdiction, and the legal basis for access (warrant, consent, subpoena, employment policy). Then argue from that basis. If the scenario is silent, say what turns on it.
Scoping the examination to only the device or account named in the request, and never asking where else the same data lives - cloud sync folders, phone, tablet, backups, email server, or a second account.
The intake request is treated as a complete description of the evidence landscape, and candidates want to start 'doing forensics' rather than doing source mapping.
What to do instead
Produce an explicit source map before acquisition: for each user/account/device, list every location the target data could plausibly exist, mark which are in scope, and document why out-of-scope sources were excluded or should be requested.
Getting the order of volatility wrong in a live-scenario question - shutting the machine down (or pulling the plug) before capturing RAM, or conversely capturing RAM after the system has been powered off, then still claiming volatile data was collected.
Candidates default to 'power it off, image the disk' from older training, or freeze when the scenario presents a running encrypted or networked host.
What to do instead
Apply a fixed volatility ladder (registers/cache → RAM → network state/connections → running processes → temp/log data → disk) and state the trade-off either way: RAM capture before shutdown for a running host; explicit note of what was lost if shutdown was required for encryption or safety reasons.
Confusing hash provenance - reporting the hash of the image container file as if it were the hash of the acquired data stream, comparing an acquisition hash to a verification hash computed over a different range, or hashing after the write blocker was removed.
Two hashes are produced during imaging and they look interchangeable in tool output; candidates copy the first value they see into the report without asking which artifact it covers.
What to do instead
For every hash value recorded, label it with three attributes: what data it covers (source device vs. image file vs. logical files), which algorithm, and at which step (acquisition vs. post-acquisition verification). Report matched pairs, not single numbers.
Reading file system timestamps at face value - treating all four MAC(B) timestamps as equally reliable, ignoring the offset between UTC-stored timestamps and the local/USB-carried time zone, or ignoring DST transitions and clock skew when building a timeline.
Timestamp semantics differ by file system and by OS version, and the exam scenario usually supplies a single 'modified' time that invites a single-cause explanation.
What to do instead
State the normalisation method explicitly (source time zone, conversion to UTC, DST handling), report which specific timestamp field is being relied on and what writes to it, and corroborate against a second independent source (event logs, USN journal, network logs) before asserting an event time.
Treating one artifact as proof of an action - 'prefetch exists, therefore the program was executed by the user', 'a .lnk file exists, therefore the user opened the file', 'the file is absent from the directory, therefore it never existed'.
Artifacts are taught one at a time with their headline meaning, and candidates memorise the headline without the creation conditions and caveats.
What to do instead
For any artifact-based claim, write down what the artifact records, what could create or alter it, and at least one corroborating or contradicting artifact you checked (e.g., prefetch + Amcache/ShimCache + event log + memory). Phrase findings at the level the corroboration supports, not the headline.
Analysing network logs without establishing time source and coverage - assuming log timestamps are local time, ignoring clock skew between devices, and treating the absence of a log entry as proof the activity did not occur, without checking retention windows, logging levels, and gaps.
Logs look authoritative and machine-generated, so the normalisation and completeness work feels optional compared with 'finding the evil IP'.
What to do instead
Before drawing conclusions, document each log source's time zone/NTP configuration, its retention period, its logging verbosity, and any identified gaps. Convert to a single timeline in UTC and state the confidence limits imposed by each source's coverage.
Describing a logical extraction, backup, or cloud-sync pull as if it were a full physical image of the device - asserting the absence of deleted data, other apps, or other accounts that a logical method cannot reach.
Mobile and cloud tooling presents an acquisition as 'complete' in its UI, and candidates transfer the assumptions of physical disk imaging onto methods that never had that scope.
What to do instead
Name the acquisition method and level (manual, logical, file-system, full file-system, physical; provider export vs. API vs. sync cache) and attach its known limitations to every finding. Never assert non-existence of data outside the method's reach.
Writing conclusions that cannot be traced back to an exhibit - stating 'the user exfiltrated the data' with no footnote to the specific artefact, file offset, or log line, and offering opinions beyond the demonstrated foundation.
The analytical work is done in the tool, and the report is written afterwards from memory; the reasoning chain is never reconstructed in writing.
What to do instead
Draft findings as claim → evidence reference → method used → limitation. Every sentence of opinion must carry an exhibit or appendix reference, and any opinion that goes beyond what the artefact supports gets cut or reworded as a factual observation.