CTDC common mistakes
CTDC · Understand the traps and how to avoid them.
When asked to triage an alert, candidates jump straight to a single suspicious log line and declare a verdict, skipping the sequence of authentication, process, and network events that establishes whether activity is malicious or benign.
Alert queues train people to answer fast, and a lone high-signal indicator (a rare parent process, a single 4625 burst) feels conclusive. Candidates under-utilize the surrounding timeline and never reconstruct the full chain, so they miss the benign explanation or the confirming second stage.
What to do instead
Before committing to a verdict, build a minimal timeline: initial access vector, execution, persistence, and any outbound connection, in order with timestamps. State explicitly which events support the malicious hypothesis and which support the benign one. If the two hypotheses are not separable with available data, say what additional log source would separate them rather than guessing.
Candidates treat a single failed-logon or a single blocked connection as proof of compromise, or conversely dismiss a genuine intrusion because the alert count was low or the source was internal.
Threshold intuition is usually calibrated on noisy internet-facing systems. On quieter internal segments one event can be meaningful, and candidates apply the wrong baseline. The reverse error happens when they assume internal sources are trusted.
What to do instead
Anchor judgements to a stated baseline: expected volume per host per hour, known service accounts, and approved scanning ranges. Judge events against that baseline and against asset criticality, not against a raw count. Explicitly note when the baseline is unknown and how you would establish it.
Candidates answer EDR questions with generic antivirus thinking, describing file-hash blocking and quarantine while ignoring process lineage, command-line arguments, memory-region anomalies, and remote thread behaviour.
Most candidates come from perimeter or SOC-alert backgrounds where file reputation dominates. EDR telemetry is process- and behavior-centric, and the exam expects reasoning about parent-child relationships and injection artifacts.
What to do instead
For every EDR scenario, reason in terms of the process tree first: who spawned whom, with what arguments, under which user, and what network or file activity followed. Mention memory and thread anomalies (unbacked executable regions, cross-process writes) as the layer above static file indicators.
Candidates propose containment (isolate host, disable account, block IP) as the first action in every scenario, without first preserving volatile evidence or confirming scope.
Containment feels decisive and is easy to describe. Candidates conflate 'stop the bleeding' with 'respond correctly' and forget that isolation destroys memory state and can tip off an adversary before scope is known.
What to do instead
Sequence the response explicitly: acquire volatile data and key logs, determine scope and blast radius, then contain, then eradicate, then recover. Justify any deviation (for example, immediate isolation when ransomware encryption is actively spreading) with the specific risk trade-off.
Candidates write SIEM correlation rules as single-event matches or as unbounded 'any user, any host, any time' logic, then cannot explain why the rule would or would not fire on a described dataset.
Rule-writing is often learned by copying examples. Candidates skip the join key, time window, and state requirements that make multi-stage detections work, and they never mentally execute the rule against sample events.
What to do instead
For each rule, name the join key (user, host, session), the time window, the required event sequence or threshold, and the suppression logic. Then dry-run it against the events in the scenario, stating which events match and which fail each condition.
Candidates treat threat-intelligence indicators as blocklist fodder and ignore indicator lifetime, confidence, and context, applying a six-month-old IP to a current investigation as if it were authoritative.
Indicator feeds are consumed as flat lists in many workflows. Candidates do not distinguish atomic indicators from behavioral TTPs and do not consider that infrastructure is rotated quickly.
What to do instead
For each indicator, state type, age, confidence, and the campaign it belongs to, and say how it changes your hypothesis. Prefer TTP-level detection over atomic matching, and note that a match on shared infrastructure (CDN, cloud region, NAT) is weak evidence on its own.
Candidates map observed activity to MITRE ATT&CK at the tactic level only ('this is lateral movement') instead of naming the specific technique and sub-technique and the evidence that supports it.
Tactic names are memorable and appear in every summary report. Technique IDs require knowing the matrix structure, and candidates avoid committing to a specific ID for fear of being wrong.
What to do instead
Practice naming technique and sub-technique with the supporting artifact: for example, remote service creation on a target host maps to Windows Remote Services, while SMB admin-share writes map to a different technique. State the evidence first, then the technique, and note when two techniques are plausible.
Candidates describe hardening as a checklist ('disable SMBv1, enable MFA') without tying each control to the specific technique it disrupts or explaining the operational cost and residual risk.
Checklists are easy to memorize and hard to reason about. The exam rewards understanding why a control works and what it does not cover, and candidates skip that reasoning.
What to do instead
For each recommended control, name the ATT&CK technique it degrades, the detection it enables, its likely operational impact, and what an adversary would do instead. Rank controls by risk reduction per unit of effort rather than listing them all equally.
Candidates respond to false-positive complaints by loosening or deleting the detection, rather than diagnosing whether the rule logic, data quality, or environment baseline is at fault.
Tuning is often driven by ticket volume, so the fastest fix is suppression. Candidates do not separate true false positives (benign activity matching the logic) from data problems (missing fields, parsing errors) or from real activity that is simply authorized.
What to do instead
Classify each false positive: logic too broad, missing enrichment or context, parsing or field-mapping error, or legitimately authorized activity. Fix the root cause, add narrow exclusions with an expiry and owner, and re-measure precision after the change rather than suppressing broadly.
Candidates escalate every scenario to the same level or never escalate, without articulating severity criteria, notification paths, and handoff content.
Escalation is treated as a formality rather than a decision with criteria. Candidates do not know what distinguishes a P1 from a P3, so they either over-escalate or sit on a real incident.
What to do instead
State severity using explicit factors: confirmed vs suspected compromise, asset criticality, data sensitivity, active spread, and business impact. Then name the escalation path, the timeframe, and the handoff package (timeline, scope, evidence, actions taken, open questions).