ATT&CK Threat Hunting cheat sheet

ATT&CK is organized as a matrix of Tactics (the adversary's goal, columns) crossed with Techniques (how the goal is achieved, rows); Sub-techniques add specificity below a parent technique (e.g., T1059 Command and Scripting Interpreter has .001 PowerShell, .003 Windows Command Shell).

The Enterprise matrix covers Windows, macOS, Linux, Cloud (AWS/Azure/GCP), Containers, Network Devices, and Office Suite; Mobile and ICS matrices are separate data sets with their own tactic columns and IDs.

Tactic ordering reflects the attack lifecycle progression (Reconnaissance, Resource Development, Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Command and Control, Exfiltration, Impact); tactic order is not a strict temporal sequence.

Technique IDs are immutable once published; deprecations are marked rather than reassigned, so STIX objects carry revoked/deprecated flags and a x_mitre_deprecated property that must be filtered in pipelines.

A Technique STIX object carries x_mitre_platforms (e.g., Windows, Linux, AWS), x_mitre_data_sources, x_mitre_detection, x_mitre_permissions_required, and x_mitre_effective_permissions - platform filtering is mandatory when mapping to a specific estate.

Software objects (Tools vs. Malware) and Intrusion-Set (Group) objects link to techniques via uses relationships; Group objects carry associated-campaign and software references, enabling actor-centric coverage queries.

Data Components (e.g., Process Creation, Command Execution) sit under Data Sources (e.g., Process) and are the join key between ATT&CK and telemetry; detections should map to Data Component, not just Technique.

Mitigations (M####) are defensive countermeasures linked to techniques; they describe classes of control, not product configurations, so they are unsuitable as detection-coverage evidence on their own.

Map at the lowest defensible level: a report naming 'PowerShell abuse' maps to T1059.001, not T1059, because sub-technique precision drives telemetry selection.

Use the confidence ladder: explicit technique ID cited in source > behavioral description matching technique definition > inferred from tool/software used > inferred from actor profile. Record the basis for each mapping.

Software and tool names are the strongest pivot: resolve a named tool to its ATT&CK Software object, then traverse uses relationships to enumerate all techniques the tool can perform - this is capability mapping, not observed behavior.

Distinguish observed (reported in the intrusion), inferred (implied by tooling), and anticipated (from actor TTP profile) mappings; only observed mappings should feed coverage-gap prioritization directly.

Intrusion Set vs. Campaign: Intrusion Set is the actor-level grouping; Campaign is a time-bounded activity. Map IOCs to Campaign and TTPs to Intrusion Set to avoid conflating transient infrastructure with durable behavior.

STIX 2.1 is the transport: indicators link to attack-patterns via indicates relationships; the ATT&CK Navigator layer JSON is the presentation format for heat maps and coverage scoring.

Deduplicate before scoring: multiple reports referencing the same technique for the same actor should collapse to one weighted entry, otherwise high-report-volume techniques dominate prioritization.

Deconflict overlapping techniques (e.g., T1055 Process Injection vs. T1620 Reflective Code Loading) by checking the technique description's stated scope before assigning; ambiguous cases should be flagged, not force-fit.

A hunt hypothesis is falsifiable and structured as: actor/behavior + target platform + expected telemetry + observable outcome (e.g., 'If an adversary uses rundll32 to proxy execution, then process-creation telemetry will show rundll32 with a DLL export argument and no matching signed parent').

Derive hunts from the intelligence-to-hypothesis chain: actor or technique → data component → telemetry source → query → expected result → validation criteria.

Prioritize hypotheses by (technique relevance to estate) × (expected detection gap) × (data availability); a hypothesis with no available telemetry is a data-acquisition task, not a hunt.

The hunt plan must predefine the benign baseline (what normal looks like for the population queried) so that deviations are measurable rather than impressionistic.

Scope the population explicitly: host subset, time window, and user cohort; unbounded hunts produce unreadable result sets and cannot be validated.

Map every hypothesis to at least one ATT&CK technique ID and one Data Component before querying; hypotheses that cannot be mapped are intelligence collection, not threat hunting.

Success criteria are defined before execution: true positive (behavior confirmed), false positive (benign explanation found), inconclusive (telemetry absent or insufficient) - inconclusive results feed data-source gap analysis.

Hunt cadence should follow intelligence refresh and environmental change (new SaaS adoption, OS upgrade), not a fixed calendar, because hypothesis relevance decays as the estate changes.

Windows process lineage requires both Security 4688 (with command-line auditing enabled) and Sysmon Event ID 1; 4688 without ProcessCommandLine policy enabled yields no arguments and cannot support command-line hypotheses.

Sysmon key IDs: 1 process create, 3 network connect, 7 image load, 8 CreateRemoteThread, 10 process access, 11 file create, 12/13/14 registry, 22 DNS query, 25 process tampering. Event 10 with GrantedAccess 0x1F0FFF/0x1010 indicates injection-relevant access.

Linux telemetry: auditd EXECVE/SYSCALL records, eBPF process exec events, and shell history are complementary; auditd execve gives argv but not full environment unless configured, and /proc-based collection is race-prone.

macOS: Unified Log (predicate-filterable), EndpointSecurity framework for process/exec events, and TCC database for permission grants; OpenBSM auditd-style records are deprecated for many event classes.

Cloud: AWS CloudTrail management events are on by default but data events (S3 object-level, Lambda invoke) are opt-in and cost-bearing; Azure Activity Log vs. Entra ID sign-in logs vs. diagnostic settings are distinct sources with different retention.

Network: Zeek conn/dns/http/ssl logs give flow-level and protocol-level visibility; full packet capture is retention-limited, so protocol logs are the durable hunting substrate; NetFlow lacks payload and user context.

Data quality checks: timestamp normalization to UTC with source skew measurement, field completeness rate per source, ingest-to-query latency, and duplicate suppression keys - each detection should declare the minimum acceptable completeness.

Retention must exceed the longest hypothesis window (commonly 90+ days for identity and cloud logs); a hunt over 180 days against 30-day retention is silently truncated and produces false negatives.

Prefer behavioral analytics over IOC matching: hash and domain indicators have short half-lives, whereas behavior (parent-child anomalies, argument patterns) survives tool recompilation.

Process-lineage analytics: compare (parent image, child image) pairs against a frequency baseline; rare pairs involving scripting hosts (wscript, mshta, rundll32, regsvr32) are high-signal.

Command-line analytics should tokenize arguments rather than regex raw strings, to reduce evasion via quoting, case, and whitespace variation; normalize before matching.

Sigma is a vendor-neutral rule format; conversion to backend query languages preserves logic but field mappings differ per SIEM, so converted rules require field-mapping validation before deployment.

KQL/Splunk SPL pattern: join rare-event detection with a baseline lookup (e.g., summarize count() by ParentImage, Image then filter by low count) rather than hardcoding allowlists that rot.

Sequence analytics (e.g., credential access followed by lateral movement within N minutes on the same host) require a stable entity key (host+user) and explicit window boundaries to avoid cross-entity false correlation.

Threshold design: set thresholds from measured population percentiles, not intuition; document the percentile and the date the baseline was computed, and re-baseline on environment change.

Cloud querying: CloudTrail userIdentity + eventName + sourceIPAddress triples detect anomalous API use; flag first-seen API calls per principal (behavioral rarity) rather than enumerating known-bad API names.

Execution order: validate query syntax on a small time slice, confirm expected event volume, then run the full window; a query returning zero events must be checked against source health before being called a negative.

Triage decision tree: is the event real (telemetry artifact?) → is the behavior explained by sanctioned admin/tooling? → does it match the hypothesis's observable? → escalate or close with rationale.

Enrichment at triage: asset criticality, user role, process signature status, parent process legitimacy, and first-seen/last-seen frequency for the binary or command line.

A confirmed true positive must be converted into a detection rule with the exact query, the ATT&CK mapping, and the tested false-positive profile - a hunt finding without a rule is a one-time observation.

Validation requires a controlled test: replay or synthesize the behavior (atomic test, purple-team emulation) and confirm the analytic fires; untested analytics are hypotheses about detection, not detections.

Record negative results: 'technique not observed in N days across M hosts' is coverage evidence and prevents repeated hunts over the same ground.

Chain of custody: preserve raw event IDs, query text, execution timestamp, and result counts for every hunt so findings are reproducible and auditable.

Escalation threshold: any confirmed adversary behavior on a production asset triggers incident response, not further hunting; hunting continues only on adjacent hypotheses that inform containment scope.

Handoff package: rule logic, required log sources and field mappings, ATT&CK technique/sub-technique and Data Component, known false positives, test evidence, severity/routing, and owner.

Coverage should be measured at the Data Component level, not the technique level: a technique is 'covered' only if the specific data component the detection consumes is collected, parsed, and retained.

ATT&CK Navigator scoring conventions: use a defined scale (e.g., 0 none, 1 partial/log-only, 2 detected, 3 blocked) and record the scoring rubric with the layer so scores are comparable across quarters.

Coverage ≠ detection: a mapped rule that has never fired in test and has no false-positive profile is 'claimed' coverage; distinguish claimed, tested, and production-validated tiers.

Detection-as-code: version control rules, peer review, CI validation (syntax + field existence against schema), and staged deployment (alert-only → tuned → blocking).

Track rule health metrics: true-positive rate, false-positive rate per rule, mean time to triage, and alert volume per analyst; rules with high FP and zero TP are candidates for retirement.

Gap analysis output is a prioritized backlog: technique relevance (intel priority) × current coverage tier × data availability; gaps with no telemetry become data-source acquisition requests.

Re-assess coverage on ATT&CK version updates and on telemetry changes (log source deprecation, parser change), because both silently invalidate previously claimed coverage.