ATT&CK Threat Hunting common mistakes
ATT&CK Threat Hunting · Understand the traps and how to avoid them.
Treating ATT&CK tactics as a sequential kill-chain the adversary must walk in order, so a hunt hypothesis assumes persistence must precede credential access and dismisses out-of-order evidence.
Kill-chain mental models and older intrusion frameworks are deeply familiar, and the tactic ordering in the matrix visually implies progression. Candidates also see ATT&CK Enterprise tactics listed in a rough logical order and mistake presentation order for causal order.
What to do instead
Internalize that tactics are categories of behavior, not phases; adversaries can begin at any tactic and loop back. When mapping a hunt, ask 'which tactic does this behavior accomplish' independently for each observable, and explicitly allow hypotheses that start at Credential Access, Collection, or Exfiltration without prior steps being observed.
Confusing techniques with sub-techniques and procedures, e.g., mapping a specific command line to T1059 (Command and Scripting Interpreter) instead of the relevant sub-technique such as T1059.001, or treating a single tool's invocation as the technique itself.
The parent technique name is the most memorable label, and candidates worry that a sub-technique guess will be marked wrong, so they default to the broader ID. They also conflate the procedure (what was observed) with the technique (the category of behavior).
What to do instead
Map to the most specific sub-technique the evidence supports and state the procedure separately in the mapping rationale. Practice the parent/child structure for high-frequency families (T1059, T1003, T1547, T1053, T1569) so the sub-technique IDs are recallable rather than guessed.
Mapping every observable in an incident to a technique, producing a bloated mapping where routine administrative activity, benign tooling, and defense evasion by the defender are all assigned ATT&CK IDs.
Candidates believe more coverage looks thorough and fear omitting something. Without a relevance test, any behavior that superficially resembles a technique gets mapped, and the analyst has no stated criterion for exclusion.
What to do instead
Apply an explicit inclusion test: the behavior must be adversary-attributable, observed (or assessed with stated confidence), and meaningful to the intrusion's objective. Record benign or inconclusive observables in a separate 'not mapped' list with a reason, and keep the technique count tied to the hypothesis being tested.
Producing a threat-intel mapping with no confidence level, no source citation, and no distinction between what was reported by a third party and what was observed in own telemetry.
Mapping exercises are often graded on the ID alone, so candidates skip provenance. Copying from a report feels like it transfers the report's authority, and confidence language seems like hedging.
What to do instead
For each mapped technique, record source (report, telemetry, analyst assessment), confidence (high/medium/low with a one-line justification), and whether it was directly observed. Treat third-party mappings as hypotheses to validate against local data, not as findings.
Writing a hunt hypothesis as a tool name or a data query ('hunt for Mimikatz', 'search for powershell.exe -enc') rather than a falsifiable statement about adversary behavior.
Tool-centric thinking is reinforced by signature-based detection habits, and a query feels concrete and actionable. Candidates skip the step of articulating what behavior would be true if the hypothesis held, so there is no clear pass/fail criterion.
What to do instead
Phrase hypotheses as 'Adversary [behavior] will produce [observable] in [data source] because [rationale]', then define expected evidence and disconfirming evidence before writing any query. Derive the query from the hypothesis, not the reverse, and record the outcome as supported, refuted, or inconclusive.
Designing hunts that can only succeed if a specific tool is present, or that assume one data source (often only process creation) will reveal the behavior, without checking whether that telemetry exists or is retained.
Candidates anchor on the tool named in a threat report and on the telemetry they are most comfortable querying. Data-availability checks feel like an administrative step rather than part of hunt design.
What to do instead
Before finalizing a hypothesis, list the required data sources and confirm collection, retention window, and field fidelity for each. Build a fallback observable (e.g., network, authentication, or file telemetry) so the hunt is not single-source, and document gaps as findings rather than silently narrowing scope.
Assuming Windows process creation telemetry includes full command lines and parent process context by default, and treating Event ID 4688 as equivalent to Sysmon Event ID 1.
The event IDs are widely quoted in hunt writeups, and candidates do not distinguish default audit policy from enhanced auditing. Command-line inclusion in 4688 depends on audit policy configuration, and parent process fields differ across sources.
What to do instead
Verify the specific configuration: whether 'Include command line in process creation events' is enabled, whether Sysmon is deployed with the relevant config, and which fields each source actually populates. Write queries against confirmed fields and record the configuration assumption alongside the analytic.
Treating Linux auditd, macOS unified logging, and cloud audit logs as if they had Windows-like process ancestry, then writing queries that reference nonexistent parent-process or image-path fields.
Most hunt practice material is Windows-centric, so candidates transfer field names and relationships across platforms without checking schemas. macOS and cloud logs also have different retention and naming conventions that are easy to overlook.
What to do instead
For each platform, learn the actual event schema before querying: auditd execve records and their field layout, macOS Endpoint Security or unified log fields, and cloud provider audit log structures (e.g., control-plane event names and principal fields). Validate a query against a known-good sample event before running it at scale.
Reporting a hunt as 'no findings' when the query returned nothing, without distinguishing a true negative from a broken or under-scoped query.
Zero results feel like a clean outcome, and candidates do not have a habit of positive-control testing. A typo in a field name, an empty index, or a time-range error produces the same empty result as genuine absence of activity.
What to do instead
Run a positive control: confirm the query returns a known-benign or synthetic event that matches the logic. Check data freshness and volume for the index and time range, then record the result as 'no evidence found, with validated coverage' versus 'inconclusive due to data gap'.
Handing a validated hunt to detection engineering as a narrative or a one-off query, with no specification of logic, required fields, false-positive profile, severity, or test cases.
Hunters optimize for the investigation rather than the handoff, and the query that worked in an ad hoc notebook is assumed to be reusable. Coverage discussions then default to counting techniques mapped rather than detections actually validated.
What to do instead
Produce a detection specification: data sources and required fields, the analytic logic in pseudocode, known benign triggers, tuning parameters, severity and response guidance, and at least one true-positive and one false-positive test case. Assess coverage by whether a technique has a tested, deployed detection with confirmed telemetry, not by whether it appears in a mapping spreadsheet.