OffSec Threat Hunter common mistakes
OffSec Threat Hunter · Understand the traps and how to avoid them.
Treating Suricata as a signature-only black box: writing or tuning rules without confirming which direction (request vs response) and which flow state the rule fires in, and never checking whether the rule actually alerts against a PCAP before declaring the hunt done.
Candidates memorize rule syntax but skip Suricata's flow/stream semantics and the difference between alert and drop in IPS mode, so rules look correct in the editor yet miss the traffic or fire on the wrong leg of the session.
What to do instead
For every rule you write, replay it with suricata -r capture.pcap -S local.rules -l outdir and inspect fast.log/eve.json to confirm the alert fires on the intended direction and stream. Explicitly state the flow keyword (flow:established,to_server vs to_client) and verify IPS mode actions with suricata --build-info and a test drop.
Hunting network IoCs by literal IP and domain match only, ignoring that adversaries rotate C2 infrastructure, use domain fronting, or beacon over legitimate services, and failing to pivot on behavioral features like JA3/JA3S, beacon jitter, or payload size regularity.
Public IoC feeds encourage a blocklist mentality; candidates equate threat hunting with IOC matching instead of hypothesis-driven detection, so they miss the intrusion once the listed indicators age out.
What to do instead
For each network hunt, write the hypothesis explicitly, then build at least one behavioral detection (e.g., periodic beacon interval variance, rare JA3 fingerprint, unusual TLS SNI-to-certificate mismatch) alongside the atomic IoC. Document the pivot logic from atomic -> behavioral -> host evidence.
Confusing endpoint IoCs with endpoint telemetry: searching for a hash or filename once in CrowdStrike Falcon and concluding 'no compromise' when the query window, sensor coverage, or field mapping was wrong.
Candidates under-specify Falcon queries (wrong event type, too narrow time range, wrong host group scope) and do not validate that the data source actually covers the target hosts, producing false negatives they trust.
What to do instead
Before concluding, verify sensor coverage and event retention for the host group, widen the time window to cover the suspected dwell time, and run the query against a known-benign control host to confirm the query returns expected baseline events. Record query scope and coverage in your notes.
Analyzing ransomware incidents without distinguishing initial access, exfiltration, and encryption phases, and without mapping observed behavior to the specific group's known TTPs (e.g., LockBit affiliate double extortion, CLOP's GoAnywhere/MOVEit mass exfiltration, ALPHV/BlackCat's Rust-based encryptor and access-broker ecosystem).
Candidates memorize group names and a few CVE numbers but not the operational sequence, so they misattribute activity and hunt for the wrong artifacts at the wrong stage.
What to do instead
For each major family, build a phase table (initial access vector, tooling, lateral movement, exfil channel, leak-site behavior) and derive at least one hunt query per phase. Practice attributing a synthetic intrusion by matching observed artifacts to that table rather than to a single IoC.
Treating exploited-vulnerability knowledge as a list of CVE numbers to recite, without connecting a CVE to its observable exploitation artifacts (e.g., MOVEit Transfer SQLi webshell drops in `C:\MOVEitTransfer\wwwroot`, GoAnywhere exploitation paths, or vulnerable VPN appliance logs).
Exam prep rewards memorizing CVE IDs and CVSS scores, but hunting requires knowing what the exploit leaves behind on disk, in logs, and on the wire; candidates cannot translate a CVE into a detection.
What to do instead
For each high-profile exploited vulnerability you study, write down the observable artifacts: file paths, process lineage, HTTP request patterns, and log entries. Convert each into a concrete hunt query or Suricata rule and test it against a lab reproduction.
Jumping straight to tool queries in a hands-on lab without first forming a written hypothesis and scoping the environment (which hosts, which data sources, what time range), then flailing between queries when the first one returns nothing.
Lab time pressure and tool familiarity bias push candidates to 'click around' in Falcon or grep logs randomly instead of following a structured hunting loop, so they burn time and miss the planted evidence.
What to do instead
Adopt an explicit loop: hypothesis -> data source check -> query -> triage -> pivot -> document. Write the hypothesis and scope in one sentence before touching a tool, and keep a running evidence log with timestamps and query strings so you can resume and justify findings.
Correlating data across sources by eyeballing timestamps without normalizing time zones and clock skew, causing process, network, and authentication events to be misordered or missed entirely.
Falcon, Suricata, and system logs may record in UTC, local time, or with different precision; candidates assume alignment and build a false timeline, especially in the Challenge Lab where multi-source correlation is required.
What to do instead
Normalize every source to UTC before correlating, record the offset and precision for each source, and build the timeline in a table with a 'source' and 'raw timestamp' column. Sanity-check ordering against a known anchor event.
Over-relying on alert-driven triage: answering lab questions by reading pre-generated detections instead of independently hunting for activity that produced no alert, and never validating whether a detection's logic would actually catch the adversary technique.
Candidates are used to SOC alert queues and assume the tooling already caught everything; proactive hunting requires generating hypotheses about gaps, which is a different skill and is easy to skip under time pressure.
What to do instead
For each scenario, ask 'what would this technique look like if no rule existed?' and build a raw-telemetry query independent of existing detections. Then test the existing detection against that behavior and note the coverage gap.
Documenting findings as a list of IoCs without an assessment of confidence, impact, and recommended containment, and without distinguishing confirmed malicious activity from benign-but-suspicious artifacts.
Candidates treat the deliverable as 'find the bad thing' rather than an intelligence product; they omit the reasoning and confidence that let a defender act, and conflate false positives with true findings.
What to do instead
Structure every finding as: observation, evidence (queries/logs), assessment with confidence level, and recommended action. Explicitly list ruled-out benign explanations and why they were excluded, mirroring enterprise threat-hunting report practice.
Misunderstanding IDS vs IPS deployment implications: assuming an IPS will block an attack because a rule exists, without checking that the rule is enabled in drop mode, the traffic is inline, and evasion techniques (fragmentation, encoding, TLS) are handled.
Candidates conflate 'a signature exists' with 'the attack is prevented' and ignore inline placement, rule action, and evasion surface, leading to false assurance in prevention-focused questions.
What to do instead
For any prevention claim, verify three things: the sensor is inline, the rule action is drop/reject, and the rule handles the relevant evasion (stream reassembly, normalization, TLS inspection limits). State these preconditions explicitly when answering IPS questions.