CNFE common mistakes
CNFE · Understand the traps and how to avoid them.
Treating a packet capture as inherently complete evidence and never documenting the capture interface, filter expression, snaplen, or drop counters before analysis.
Candidates equate 'I have a pcap' with 'I have the traffic,' forgetting that a capture filter, short snaplen, or kernel drop count silently removes data, so later conclusions rest on an unrepresentative sample.
What to do instead
Record interface, capture filter vs. display filter, snaplen, buffer settings, timestamp source, and dropped-packet statistics at acquisition time; store them with the pcap hash and state in the report which traffic could not have been captured.
Describing chain-of-custody as a general principle without producing a concrete, time-stamped transfer log tied to hashes.
Candidates memorize the phrase 'maintain chain of custody' but never practice the artifact, so they cannot show who held the evidence, when, and whether integrity was verified at each handoff.
What to do instead
For every evidence item, list acquisition time, collector, tool and version, hash algorithm and value, storage location, and each transfer with signatures; re-hash on receipt and record the verification result.
Confusing capture filters (BPF, applied before the buffer) with display filters (applied after capture) and assuming a display filter preserved everything.
Both look like filter syntax in the same tool, and candidates rarely see the drop statistics that reveal a capture filter discarded the traffic they now want.
What to do instead
State explicitly which filter stage each expression belongs to; when scope may be disputed, capture broadly with a large buffer and narrow only at display time, and document the tradeoff in the report.
Reading a TCP stream as if every segment were in order and complete, ignoring retransmissions, out-of-order delivery, and gaps.
Wireshark's Follow TCP Stream reassembles and hides sequence anomalies, so candidates narrate a clean conversation that never occurred on the wire.
What to do instead
Check sequence/acknowledgment numbers, relative sequence, retransmission and zero-window expert info, and missing segments before drawing conclusions; describe reassembly artifacts and note where payload is inferred rather than observed.
Attributing encrypted or obfuscated traffic to a specific malware family from an IP address or port alone.
Threat-intel lookups return a family name for an indicator, and candidates treat that label as a finding rather than a hypothesis needing corroboration.
What to do instead
Tie attribution to multiple independent observables (JA3/JA3S or certificate fields, beacon interval and jitter, URI patterns, payload structure, host-side artifacts) and record indicator confidence, first/last seen, and source so a stale or shared indicator is not overstated.
Treating a single IDS alert as confirmed compromise and skipping the rule's signature logic and false-positive conditions.
Alerts arrive pre-labeled with severity, and candidates report the alert text instead of validating what the rule actually detects and whether the traffic matches that condition.
What to do instead
For each alert, quote the rule logic, identify the fields it matches, check for evasion or benign explanations, and correlate with flow records, logs, and host evidence before assigning a verdict.
Building an incident timeline from log timestamps without normalizing time zones, clock skew, or log-source offsets.
Different devices log in local time, UTC, or device-local clocks that drift, and candidates concatenate them directly, producing an impossible sequence of events.
What to do instead
Normalize all timestamps to UTC, record each source's known offset and skew, flag uncertain times, and validate ordering against independent anchors such as packet timestamps or authentication events.
Writing conclusions in the report that outrun the evidence, using absolute language such as 'the attacker exfiltrated the database' when the capture only shows a large outbound transfer.
Candidates want a decisive narrative and conflate observed packets with inferred intent, which collapses under cross-examination.
What to do instead
Separate observed facts, analytical inferences, and opinions; qualify each conclusion with its supporting artifact and confidence level, and state what evidence would change the finding.
Presenting tool output as the finding without explaining method, tool version, configuration, or validation.
Candidates treat a tool's verdict as self-authenticating and never practice describing how a result was produced or independently confirmed.
What to do instead
Document tool name and version, command line or GUI settings, input hash, and a manual or second-tool verification of key results; explain the method so a reviewer can reproduce it.
Answering legal questions from general intuition instead of citing the specific authority governing consent, warrants, or provider records.
Wiretap, stored-communications, and privacy rules differ by jurisdiction and by whether capture is real-time or stored, and candidates apply a remembered slogan rather than the applicable statute or policy.
What to do instead
Identify the jurisdiction and the legal basis for each collection step, distinguish real-time interception from stored-record access, and state the authorization, scope limits, and minimization applied; flag any point requiring counsel rather than guessing.