C|CT common mistakes
C|CT · Understand the traps and how to avoid them.
Reading a firewall or IDS log excerpt and answering from the most alarming-looking line instead of reconstructing the packet flow in time order, so a blocked scan is reported as a successful compromise.
Log excerpts are dense and candidates skim for keywords like DENY, ALERT, or 445, then anchor on the first hit without checking direction, interface, or whether a session was actually established.
What to do instead
Before answering, rewrite the excerpt as a short timeline: timestamp, source, destination, port, action, and session state. Only claim compromise when an outbound or follow-on connection from the target appears after the alert. Practise with tcpdump and firewall exports until the timeline habit is automatic.
Treating network segmentation and ACL questions as binary allow/deny, ignoring direction, statefulness, and where NAT or a proxy rewrites the source address.
Candidates memorise rule syntax but never build the mental model of a stateful device tracking return traffic, so they misjudge which side initiates and which address the destination actually sees.
What to do instead
For every scenario, draw the path and label each hop with the address and port visible at that point. State explicitly whether the device is stateful and which zone initiates. Rehearse with a lab of two subnets and a stateful firewall until return-path behaviour is intuitive.
Confusing scanning and enumeration activity with exploitation when classifying attacker behaviour in a scenario, then choosing the wrong defensive control.
The phases overlap in tooling output, and candidates pattern-match on tool names rather than on what the observed traffic accomplishes, so a SYN sweep gets described as an intrusion attempt that succeeded.
What to do instead
Classify each observed action by its effect: does it discover hosts, discover services, validate credentials, or execute code? Map the effect to the phase, then choose a control that interrupts that effect. Keep a one-page phase-to-evidence table and test yourself on raw packet captures.
Answering web exploitation questions by naming a payload without tracing how the input reaches the sink, so the stated root cause and remediation do not match the vulnerability class.
Candidates memorise payload strings for injection and cross-site scripting but skip the data-flow reasoning, and exam scenarios deliberately place the same input in a context where it is safely encoded.
What to do instead
For each scenario, identify source, transformation, and sink in one sentence before selecting an answer. If the sink is a SQL query, the fix is parameterisation; if it is HTML output, it is contextual encoding. Rehearse by reading vulnerable code snippets and stating the flow aloud.
Building an incident timeline from file system timestamps without accounting for time zone, clock skew, and which timestamp field (modified, accessed, changed, created) is being read.
Tooling displays local time by default and different file systems update metadata fields differently, so candidates compare values that are not the same quantity and draw false ordering conclusions.
What to do instead
Normalise every timestamp to UTC and record the source field name alongside each value. Note the host clock offset from a reliable reference before ordering events. Practise on a small disk image, exporting a timeline and reconciling it against application logs.
Altering or booting evidence before acquisition, or capturing only allocated files, so the answer describes an incomplete or contaminated image.
Candidates focus on tool operation and forget order of volatility and write-blocking, and they assume a logical copy of visible files is equivalent to a forensic image.
What to do instead
State the sequence explicitly: isolate, document, hash, write-block, image, verify hash. Distinguish physical, logical, and sparse acquisition and when each is acceptable. Practise imaging a test drive and verifying the hash matches before and after analysis.
Jumping to containment before scoping an incident, so the chosen response isolates one host while the actual persistence mechanism or lateral movement remains active.
Scenarios are written to feel urgent, and candidates equate fast action with correct action, skipping the identification of affected accounts, scheduled tasks, and trust relationships.
What to do instead
Apply a fixed order: detect, scope, contain, eradicate, recover, review, and justify any deviation. Before selecting a containment step, list what evidence it destroys and what it leaves running. Practise tabletop scenarios where the first obvious host is a decoy.
Misreading a SIEM or alert-tuning question by suppressing the rule instead of addressing the detection logic, producing an answer that hides real activity along with the noise.
Alert fatigue makes disabling or broadly excluding look attractive, and candidates do not separate the noise source from the malicious behaviour the rule is meant to catch.
What to do instead
Identify the exact condition generating false positives, then narrow it with additional context such as asset role, user baseline, or correlated event, rather than excluding the whole rule. Always state what true positive the tuned rule must still catch.
Selecting a control by its category label (preventive, detective, corrective) without checking whether it actually operates at the layer and moment the scenario requires.
Candidates memorise the taxonomy in isolation and never test it against realistic placement questions, such as whether a control on the endpoint can see encrypted traffic.
What to do instead
For each candidate control, state where it sits, what data it sees, and when it acts relative to the threat. Eliminate any control that cannot observe the relevant layer. Drill with mixed lists of controls and placement constraints until the reasoning is quick.
Leaving scenario questions about evidence handling and chain of custody without stating who, when, and how integrity was verified, so the answer is technically plausible but procedurally invalid.
Candidates treat custody documentation as paperwork and assume the technical steps imply admissibility, and they underestimate how often the exam tests process rather than tooling.
What to do instead
Include the custody elements in every evidence answer: collector identity, time in UTC, location, hash algorithm and value, transfer signatures, and storage conditions. Build a checklist and apply it to every practice scenario until it is reflexive.