CCFR common mistakes
CCFR · Understand the traps and how to avoid them.
Ordering volatile evidence collection from the least volatile (disk, then logs, then memory) instead of capturing RAM and running processes first, then treating the acquisition as complete once the disk image is taken.
Candidates study file-system artifacts in depth and treat memory as an optional extra, so they default to the familiar order and never rehearse a full volatility ladder under time pressure.
What to do instead
Memorize and write out the volatility ladder (CPU registers and cache, RAM and running processes, network connections, temporary files, disk, remote logs, archival media) and practice justifying each step by asking 'what is lost if power is pulled now'. On scenario items, state explicitly what you capture first and why before naming disk tools.
Using write-blockers only for the suspect drive and imaging over a live network share or mounting the image read-write to browse it, then later being unable to defend integrity in a report.
The candidate focuses on the tool mechanics (dd, FTK Imager, Guymager) and treats hashing as a formality, forgetting that a read-write mount alters atime and journal state and breaks the chain of custody story.
What to do instead
Adopt a fixed procedure: hardware or software write-block, image to a forensically wiped destination, hash at acquisition and re-hash at analysis, record both values plus tool version and operator. When answering, name the hash algorithm and the two verification points rather than saying 'we hashed it'.
Confusing host-based and network-based evidence sources, e.g. answering a lateral-movement question with only Windows Event ID 4624 detail while ignoring firewall, proxy, NetFlow, and DNS logs that would show the same activity from the network side.
Most study material is organized by artifact type rather than by investigative question, so candidates learn 4624/4625/4688 in isolation and never build the habit of asking which telemetry sources corroborate a finding.
What to do instead
For each common scenario (credential theft, lateral movement, exfiltration, persistence), build a small matrix of host and network sources and what each would show. In answers, cite at least one corroborating source outside the host when the question involves movement or exfiltration.
Treating timestamps as ground truth: reporting file MACB times as the incident timeline without checking timezone offsets, clock skew, or that NTFS $STANDARD_INFORMATION and $FILE_NAME timestamps can be timestomped.
Timeline tools present a single normalized column, and candidates trust the output; they also forget that UTC versus local time in log exports can shift an event by hours and reorder the narrative.
What to do instead
State the timezone normalization step in every timeline answer, describe comparing $STANDARD_INFORMATION against $FILE_NAME timestamps (and USN journal or log entries) to detect timestomping, and prefer corroborated event times over a single file timestamp when placing an event.
Answering containment questions by immediately wiping and rebuilding the affected host or by pulling the network cable on a production server, without preserving evidence or considering scope.
Candidates conflate 'stop the bleeding' with 'clean up', and under exam time pressure they pick the most decisive-sounding action rather than the sequenced one.
What to do instead
Use a fixed order: detect and validate, scope, preserve volatile evidence, contain (network isolation or account disable rather than destruction), eradicate, recover, lessons learned. When a question offers 'rebuild the server now', check whether the scenario still needs evidence or whether other hosts are compromised first.
Escalating to full incident declaration and executive notification for every suspicious alert, or conversely handling a confirmed domain-wide compromise as a single-host ticket.
Candidates lack a severity model and answer from gut feel; they also do not distinguish an event, an alert, and an incident, so classification items become coin flips.
What to do instead
Learn a concrete severity rubric (data sensitivity, number of hosts, privileged accounts involved, business impact, regulatory exposure) and apply it explicitly in the answer. Practice stating the classification decision and the one or two criteria that drove it.
Writing incident response steps that omit the communication and documentation track: no named incident commander, no stakeholder update cadence, no decision log, and no regulatory or legal notification check.
Technical candidates treat IR as a sequence of forensic actions and underestimate that exam scenarios often test coordination, authority, and notification obligations rather than tooling.
What to do instead
For every IR answer, include roles (incident commander, comms lead, forensics lead, legal), a status update cadence, and a documented decision log. If personal data may be involved, mention assessing breach-notification obligations with legal rather than asserting a deadline from memory.
Treating eradication as complete after deleting the malware binary or blocking one IP, without checking for persistence mechanisms (scheduled tasks, services, WMI subscriptions, run keys, rogue accounts) or re-entry paths.
The visible artifact is the one that was reported, so candidates answer the specific alert rather than the adversary's foothold, and persistence artifacts are easy to forget under time pressure.
What to do instead
Maintain a persistence checklist and apply it in answers: autoruns, scheduled tasks, services and drivers, WMI event subscriptions, account creation and group changes, SSH authorized_keys, web shells. Pair eradication with credential resets and a verification step before returning to production.
Skipping evidence handling during live response: running untrusted tools from the compromised host, collecting memory with a binary copied onto the suspect system, or storing collected artifacts on the same host or share being investigated.
Candidates separate 'forensics' from 'response' in their heads and assume live response has looser rules, so they choose the fastest collection method without considering tool trust and contamination.
What to do instead
Apply evidence-integrity rules to live response too: use trusted, version-pinned tooling from removable or network media, record commands and hashes, and store output off-host. In answers, name where the artifact is written and how its integrity is preserved.
Overstating conclusions from a single artifact: declaring attribution, intent, or the full scope of a breach from one log entry, one malware hash, or one IP address, and presenting it as fact rather than as a finding with confidence level.
Exam items reward a definite-sounding answer and candidates fear appearing indecisive, so they convert an indicator into a conclusion instead of stating what the evidence supports and what would confirm it.
What to do instead
Phrase conclusions as supported findings plus the corroboration needed: state what the artifact shows, what it does not show, and the next source that would confirm scope or actor. Treat hashes and IPs as indicators requiring context, and note that shared infrastructure and tooling reuse limit attribution.