eCDFP common mistakes
eCDFP · Understand the traps and how to avoid them.
Reading a packet capture only at the connection level (five-tuple, byte counts, port numbers) and never drilling into payload or protocol fields before answering what happened on the wire.
Candidates coming from firewall or NetFlow backgrounds are used to metadata-only triage and assume the question is asking which session was blocked rather than what the session actually carried; eCDFP network items typically hinge on a protocol-level detail such as a cleartext credential, an HTTP User-Agent, a TLS SNI mismatch, or a DNS query name.
What to do instead
Adopt a fixed drill-down order for every traffic question: identify the flow, then the application protocol, then the specific field that answers the stem. Practice writing one-sentence summaries of a flow at each layer (L3/L4/L7) so the habit of descending into payload becomes automatic.
Treating a single log line or alert as proof of compromise and selecting an answer that declares an incident, instead of correlating the event with surrounding context such as parent process, user, host, and time window.
Exam stems often present a scary-looking event (encoded PowerShell, a rare binary, a suspicious domain) that is benign in context; candidates anchor on the keyword and stop reading. Detection engineering culture also trains people to think in terms of single signatures.
What to do instead
For every detection question, explicitly ask three questions before choosing: what is the parent/preceding event, what is the identity and privilege involved, and does the timing fit normal administrative activity. Eliminate any option that asserts compromise without corroboration.
Confusing containment with eradication, or isolating a host before preserving volatile evidence, when answering incident response sequencing questions.
Real-world pressure and runbooks that begin with 'isolate the endpoint' create a reflex; candidates also conflate the phases because many tools perform isolation and cleanup in one click. Exam items frequently test the order of operations and the cost of destroying memory-resident evidence.
What to do instead
Memorize the phase boundaries and what artifact each phase touches: identification, containment, eradication, recovery, lessons learned. Before any destructive action, ask what evidence lives only in memory or in the live network connection, and choose the option that preserves it.
Answering host-based questions using only file-path and hash indicators while ignoring process ancestry, command-line arguments, and loaded modules.
Signature-centric habits from antivirus-era training lead candidates to look for a malicious filename; modern endpoint telemetry questions are built around behaviour such as a word processor spawning a scripting interpreter, or a signed binary loading an unsigned DLL.
What to do instead
Practice reconstructing a process tree from raw event fields (image path, parent image, command line, user, integrity level) and describing what is anomalous in the lineage rather than the file. When a stem gives you command-line text, treat it as the primary evidence.
Misreading log timestamps and time zones, comparing events from sources with different clock bases, or assuming all logs are in UTC when the stem shows local time.
Candidates skim the timestamp as decoration and focus on the message body; multi-source correlation questions deliberately place events minutes apart in different zones so that only correct normalization reveals the true sequence.
What to do instead
Before reasoning about order, convert every timestamp in the stem to a single reference zone and write the normalized times down. Check for offset indicators (Z, +00:00, named zones) and treat missing zone information as a flag to look for a hint elsewhere in the stem.
Choosing a network control that blocks at the wrong layer, such as proposing a DNS sinkhole or host firewall rule when the requirement is to detect exfiltration over an allowed protocol, or vice versa.
Candidates conflate prevention and detection objectives and pick the most familiar tool rather than the one matching the stated goal and the traffic's encapsulation; eCDFP items often specify whether the desired outcome is visibility, disruption, or alerting.
What to do instead
For each network defense question, state the objective in one word (detect, block, contain, attribute) and the layer where the behaviour is observable. Then pick the control that operates at that layer, and reject options that change the objective.
Over-trusting a single IOC or threat-intel feed hit and ignoring the base rate, age of the indicator, and whether the indicator is infrastructure shared by many benign tenants.
Candidates equate 'matches intel' with 'malicious', but shared hosting, CDN addresses, and expired indicators produce frequent false positives; exam items test whether you weigh indicator quality and context.
What to do instead
Evaluate every indicator on three axes: specificity (is it dedicated infrastructure), freshness (when was it observed), and corroboration (does host or network telemetry independently support malice). Prefer behavioural evidence over a lone IOC match in the answer choice.
Skipping the question stem's qualifiers such as 'most likely', 'first', 'least', or 'best supports' and answering a different question than the one asked.
Under time pressure candidates pattern-match the scenario to a memorized fact and select the first plausible option; stems are deliberately written so that several options are technically true but only one satisfies the qualifier.
What to do instead
Underline or mentally restate the qualifier before evaluating options, and after selecting an answer, re-read the stem to confirm the choice satisfies the exact constraint. If two options seem correct, the qualifier is what separates them.
Treating encryption as a visibility dead end and failing to use metadata side channels such as TLS handshake fields, certificate attributes, SNI, JA3-style fingerprints, packet-size and timing patterns, or DNS behaviour.
Candidates learn that TLS payload is opaque and stop analysis there, missing that most encrypted-traffic questions are answerable from handshake and flow characteristics without decryption.
What to do instead
Build a checklist of encrypted-traffic observables: SNI and certificate subject/issuer, TLS version and cipher, handshake fingerprint, connection duration and byte asymmetry, beaconing periodicity, and destination reputation. Apply the checklist whenever a stem mentions TLS or an unknown protocol on 443.
Describing a hunting methodology as 'run a SIEM query and review results' without stating a hypothesis, the data sources required, and the success or triage criteria.
Candidates memorize tool workflows instead of the hunt loop, so their answers lack the hypothesis-driven structure that distinguishes threat hunting from routine monitoring; exam items probe whether you can design a hunt, not just execute a search.
What to do instead
Frame every hunting answer as hypothesis, required telemetry and its retention, query logic in plain language, expected benign explanations, and escalation criteria. If an option omits the hypothesis or the data-source dependency, it is usually the weaker choice.