re-hunting

Threat Hunting

When to use / when not to use

• Use: proactive hunting requests ("is there any X activity in the environment"), hypothesis-driven environment investigation, threat intelligence operationalization (turning intelligence leads into in-environment searches)
• Use: baseline-driven anomaly discovery (when there is no specific intelligence, build a baseline first, then find deviations)
• Use: post-incident expanded investigation (one confirmed hit → search again for the same TTP/same infrastructure, find those that slipped through)
• Use: alert-driven retro-hunting (one alert → reverse-hunt similar behavior of the same kind that did not alert, find those that slipped through)
• Do not use: pure compliance inspection (regular reports without a hypothesis are operations, not hunting; the two processes differ)
• Do not use: known-sample analysis ([[re-behavior]]); IOC lookup ([[re-ti]]); deep dive on a single point of evidence (domain-specific skills)
• Do not use: single-point incident response handling (hunting is the proactive side, incident response is passively triggered; conclusions can feed each other but the processes differ)
• Do not use: when there is no telemetry source (a missing data source cannot support hypothesis verification; first fill the collection gap, then hunt, see [[gotchas]])
• Do not use: device/host-level single-point investigation (that is the business of domain-specific skills; hunting targets the environment as a whole)

Tool preparation

Log analysis tools (general)

• Multi-platform: jq / grep / awk (bundled with most distributions or apt install jq / brew install jq）
• Verify: jq --version
• python3 (baseline statistics/clustering scripts): for installation see [[re-python]] Tool preparation
• Quick frequency statistics:grep -E + sort | uniq -c(usable for a first version of the baseline)

Telemetry query (by environment)

• SIEM/EDR query interface (provide query guidance according to the deployment environment; not tied to a specific tool)
• Local logs: journalctl(Linux, structured filtering:journalctl -o json --since "24 hours ago" | jq ...）；PowerShell Get-WinEvent(Windows, e.g. Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} -MaxEvents 100）
• Network telemetry: traffic/firewall logs (for deep dive see [[re-netcap]])
• Common Windows event IDs (verify against what is actually enabled in the environment): 4624/4625 logon success/failure, 4688 process creation, Sysmon 1 process creation, Sysmon 11 file creation

ATT&CK Navigator (hypothesis alignment reference)

• Web tool (publicly accessible); Navigator layer files can be downloaded locally; rule matching formats can reference Sigma (public rule format, adapt to the environment)
• Coverage comparison: after finishing, use Navigator layers to mark covered techniques and produce a coverage statement (compared against blind spots)

Operating steps

Execute in order; act only after the hypothesis is clear (pitfall 5). Archive each step's output (path + sha256, see [[re-triage]]).

1. Hunting hypothesis generation：

   • Inputs: threat intelligence ([[re-ti]]), known attack patterns ([[re-behavior]] experience), environment characteristics (exposure surface/business/historical incidents), red team/exercise reports (prioritize checking known successful paths)
   • Hypothesis sentence pattern: "The attacker may have used technique X to do Y in the environment" — X aligns with an ATT&CK technique, Y is an observable telemetry trace
   • Falsifiability check: for each hypothesis, write down "what should be seen if it is false" (the counter-evidence form); do not investigate those that cannot be written
   • Intelligence detectability mapping: every IOC/TTP in the intelligence must answer "which telemetry trace does it correspond to in the environment"; those that cannot be matched are listed as blind-spot hypotheses
   • Priority: impact × likelihood × detectability (those low in all three are not worth investigating)
   • Hypothesis count control: 3-5 high-priority hypotheses per round (too many prevents in-depth verification)
   • Hypothesis card: number/sentence form/source intelligence/telemetry traces/counter-evidence form/priority
   • Output: hypothesis list (each hypothesis = a falsifiable search target; cover multiple hypotheses by technique family to avoid single points)

2. Telemetry source selection：

   • Select data sources by hypothesis: process behavior → EDR/process logs (Windows 4688/Sysmon 1); network → traffic/firewall logs; login → authentication logs (4624/4625); files → file system monitoring (Sysmon 11)

   • Missing data source → mark blind spots (validity boundary of conclusions, see [[gotchas]] blind spot pitfalls)

   • When multiple data sources exist for the same hypothesis, query the most comprehensive coverage first, then cross-validate

   • First verify telemetry pipeline health (receive one known test event), then trust "no alerts"

   • Time normalization: unify timestamps from all data sources to UTC and the same format (ISO8601), do this before cross-source comparison

   • Data source mapping example (verify actual event IDs per environment):

     Hypothesis focus	Data source	Event/log	When missing
     Process/execution	EDR, process logs	4688、Sysmon 1	Cannot verify execution chain
     Network egress	Traffic/firewall/proxy	Connection logs/NetFlow	Cannot verify egress behavior
     Login/credentials	Authentication logs	4624/4625	Cannot verify credential stuffing/lateral movement
     File drop	File system audit	Sysmon 11	Cannot verify delivery

3. Baseline vs anomaly：

   • Baseline: statistical distribution of a normal window (frequency/source/target characteristics) — choose a known clean period for the window and cover the business cycle (see pitfall 1)
   • Statistical methods: frequency distribution/percentile baseline/period-over-period abrupt change (compared with the previous window); use python3 scripts for distribution statistics
   • Anomaly detection: behavior deviating from the baseline (new process chains, unusual time periods, abnormal targets), rule matching (known patterns)
   • Heuristic anomaly examples: first-seen processes/domains, logins during non-working hours, egress to rare ports
   • Clustering: cluster anomalous entries by characteristics (process name/path/target domain/time window) to reduce manual item-by-item review
   • Clustering output: anomaly group list (each group: characteristics/count/time range/associated hypothesis number)
   • Baseline artifacts: frequency distribution tables by entity (top N processes/domains/login sources) + threshold recommendations

4. Verification loop：

   • Hit confirmation: anomaly → deep dive ([[re-behavior]] behavior analysis, [[re-variant]] sample correlation, [[re-netcap]] network-side verification)
   • False positive exclusion: whitelist check, environmental explanation (legitimate changes/maintenance windows), confirmation with the business side
   • Document after exclusion: false positive determination record (why excluded), so reviews do not repeat the analysis
   • Whitelisting is a dynamic asset: after confirming legitimacy, add it to the whitelist (with reasons), and periodically re-review as the environment changes
   • Evidence archiving: review using the format per [[re-analyze/analysis-contract]] (conclusion/evidence/confidence)
   • Closed-loop output: confirmed hit → incident report (including IOC retention, can be converted to [[re-ioc]]); no hit → hypothesis archived (re-runnable, with blind spots annotated)
   • After a hit, expand the review: rescan with the same TTP/same source (hunting is iterative, not one-off)
   • Retrospective output: hypothesis hit-rate statistics (basis for next round's priorities)
   • Delivery structure: hypothesis list (including blind spots) → hit list (graded) → evidence package paths → recommendations (rule/collection enhancements)
   • For judgment grading and termination conditions, see [[decision-tree]] (four levels: confirmed/suspicious/unverified/no hit)

Cross-domain joint

• [[re-forensics]] gateway: this skill belongs to
• [[re-ti]]: intelligence input (hypothesis source)
• [[re-behavior]]: hit deep dive (behavioral evidence)
• [[re-variant]]: sample correlation
• [[re-netcap]]: network telemetry deep dive
• [[re-ioc]]: hit indicator retention (YARA/rules)
• [[re-triage]]: artifact archiving specification (path + sha256)
• [[re-analyze/analysis-contract]]: conclusions delivered in the review format

Common pitfalls and traps

• Baseline contamination: Symptom — anomalies are treated as normal; Cause — the environment itself has already been compromised (the baseline contains malicious activity); Countermeasure — choose the baseline window during a known-clean period, and annotate baseline assumptions
• Telemetry gap blind spots: Symptom — a no-anomaly conclusion despite activity in the environment; Cause — key data sources are not collected; Countermeasure — explicitly annotate blind spots in step 2, and limit conclusions to "within the collected telemetry"
• False positive fatigue: Symptom — a large number of hits with no one doing deep dives; Cause — rules too broad/thresholds too low; Countermeasure — cluster first, then review, and calibrate thresholds against the baseline
• Hypotheses too narrow: Symptom — only one technique was investigated; Cause — a single hypothesis; Countermeasure — generate multiple hypotheses by ATT&CK technique family (coverage declaration)
• Conclusions too strong: Symptom — a "the environment is clean" declaration; Cause — blind spots and hypothesis boundaries are not annotated; Countermeasure — qualify conclusions (see pitfall 2)
• Confirmation bias: Symptom — only evidence supporting the hypothesis is sought, while counterevidence is ignored; Cause — reaching a conclusion first and then looking for evidence; Countermeasure — for each hypothesis, list "what should be seen if it is false," and record counterevidence as well
• Clock skew/time zone: Symptom — the event sequence does not line up; Cause — endpoint clocks are not calibrated; Countermeasure — normalize to UTC first, and annotate the time source
• No alerts ≠ no activity: Symptom — declaring safety just because rule matches are all empty; Cause — monitoring blind spots/rule evasion/alerting system degradation; Countermeasure — state "collected + covered techniques" and "not covered" separately
• Investigate once without re-reviewing: Symptom — after handling a hit, the scope is not expanded; Cause — treating hunting as a one-off task; Countermeasure — after a hit, investigate again by the same TTP/same infrastructure, iterating for two rounds
• Insufficient query permissions: Symptom—the conclusion has blind spots but they are not labeled; Cause—only partial data source permissions were obtained; Countermeasure—list the unauthorized data sources, and limit the conclusion to the authorized scope
• The baseline window includes the maintenance period: Symptom—legitimate large actions during the maintenance window are treated as anomalies/pollute the baseline; Cause—coarse window selection; Countermeasure—exclude the maintenance period from the baseline window and label it
• A hit is immediately treated as a confirmed incident: Symptom—a single log hit immediately reports an event; Cause—no environmental interpretation was performed; Countermeasure—pass the "environmental interpretation" checkpoint before classifying it (decision tree grading table)
• For task type selection, hit grading, and archiving rules, see [[decision-tree]] / [[gotchas]]