HTB CDSA common mistakes
HTB CDSA · Understand the traps and how to avoid them.
Jumping straight to per-artifact deep dives (parsing a single log file or carving one process) before writing a short scoping hypothesis and a list of the questions the evidence must answer, then running out of time with no coherent incident narrative.
Lab-style training rewards tool fluency on isolated artifacts, so candidates treat the exam as a series of tool exercises. Under a timed scenario the absence of a scoping step causes duplicated effort and missed pivots.
What to do instead
Spend the first 5-10 minutes writing a one-paragraph hypothesis (what happened, which hosts/accounts, which time window), a checklist of evidence sources to consult, and a time budget. Revisit the checklist after each major finding and record the pivot that led to the next source.
Building SIEM queries that match a single literal indicator (one IP, one filename) and reporting the hits as the investigation, instead of starting from a behavior and iterating the query until it captures the full technique.
Candidates learn detection by copying IOC lists and are comfortable with exact-match searches; they under-practice the abstraction step from indicator to behavior and rarely test a rule against benign lookalikes.
What to do instead
For each lead, write the behavior in plain language first (e.g., 'process spawned by a service binary making an outbound connection'), translate it into the query, then run a false-positive check against normal activity in the same dataset. Document the rule logic and its known benign matches.
Treating packet capture review as 'find the suspicious IP' and never reconstructing the session: not following TCP streams, not extracting transferred files, not correlating timestamps with host logs, and not stating the protocol-level evidence for exfiltration or C2.
PCAP tooling is visually overwhelming and candidates default to display filters for known-bad addresses; they lack a repeatable workflow for stream reassembly, file extraction, and timeline correlation.
What to do instead
Adopt a fixed sequence: protocol hierarchy and conversations for volume anomalies, then per-session follow-stream, then object export for transferred files, then timestamp correlation with endpoint and proxy logs. State the evidence in protocol terms (bytes out, beacon interval, JA3/SNI mismatch) rather than just naming an IP.
Reading EDR process trees and command lines in isolation, without checking parent-child plausibility, user context, integrity level, and signing status, so a LOLBin launched by an Office process or a service binary running from a user-writable path is either missed or over-reported.
Candidates memorize suspicious command-line keywords and never build a baseline of what normal parent-child relationships and paths look like on the specific host, so both false negatives and false positives are common.
What to do instead
For every process of interest record five fields: image path, parent image, user/SID, integrity level, and signature. Compare against the host's own baseline and against known-good system paths. Flag anomalies in the combination, not in a single keyword.
Presenting forensic findings without establishing provenance: quoting file timestamps without noting the source filesystem, timezone, and whether the timestamp is $STANDARD_INFORMATION or $FILE_NAME, and mixing UTC and local times in one timeline.
Candidates rush to conclusions from the first timestamp they see and are unfamiliar with how NTFS, registry, and log sources disagree; timezone drift silently corrupts the narrative.
What to do instead
Normalize every artifact to UTC in a single working timeline, record the source and timestamp type for each entry, and explicitly note known timestamp caveats (timestomping, SI vs FN, log ingestion delay). State the conversion and the source in the report.
Analyzing malware by running it or by relying only on automated sandbox output, without a static pass: no strings, imports, hashes, or config extraction, and no description of persistence, C2 protocol, or capability derived from the sample itself.
Sandbox reports are convenient and candidates lack confidence in static tooling; they also fear breaking the environment and skip safe handling steps entirely.
What to do instead
Do a static pass first in an isolated environment: hashes, strings, imports, embedded config, and any packed/obfuscated indicators. Use sandbox output only to corroborate. Report capability with the specific evidence (string, import, config field) that supports each claim.
Ignoring Active Directory telemetry beyond 4624/4625: not reviewing 4768/4769/4771 for Kerberos abuse, 4662 and replication rights for DCSync, 4728/4732 for group changes, or service-principal and delegation changes, and not distinguishing logon type 3 from 10.
Candidates default to the two event IDs they know best and have not practiced reading Kerberos and directory-service events in context, so domain-wide attack paths go unseen.
What to do instead
Keep a reference sheet of the AD event IDs and the attack each maps to, and for every authentication finding record logon type, source workstation, and account. Pivot from a suspicious logon to directory changes in the same window before concluding.
Writing the report as a chronological dump of every command run and every log line viewed, with no executive summary, no severity rationale, and no separation of confirmed findings from open questions.
Candidates equate thoroughness with volume and have not practiced the compression step from investigation notes to a decision-ready report; they also fear omitting anything.
What to do instead
Use a fixed structure: executive summary (what happened, impact, current status), findings ranked by severity with the evidence and the reasoning that establishes severity, timeline, and open questions with next steps. Move tool output to an appendix and cite it by reference.
Failing to preserve or document evidence handling: modifying files on disk, not recording hashes at acquisition, not noting tool versions and commands, and not keeping an audit trail of what was collected when.
In a timed lab the priority feels like speed, and chain-of-custody practice is treated as paperwork rather than as a property of defensible analysis.
What to do instead
Before touching anything, hash and record the source, work on copies, log every command and tool version, and keep a collection log with timestamps. Include an evidence-handling section in the report stating what was acquired, how, and its integrity value.
Treating threat hunting as a one-shot query for a known IOC rather than a hypothesis-driven loop: no baseline of normal behavior, no test of the hypothesis against the environment, and no feedback of results into new detections or tuning.
Candidates conflate hunting with searching and skip the baseline step because it is slow; without a baseline, anomalies cannot be distinguished from environment-specific normal.
What to do instead
Write the hypothesis and the expected observable first, establish a baseline for that observable over a quiet period, then hunt for deviation. Close the loop by documenting whether the hypothesis was confirmed, and convert confirmed behavior into a detection rule with a stated false-positive profile.