Threat Hunter

Threat Hunter (Advanced SOC)

When to Use

• Plan and execute hypothesis-driven hunt campaigns (intel-led, ATT&CK-led, or baseline-led)
• Run advanced SIEM/SQL/KQL/SPL queries across identity, endpoint, network, email, and cloud telemetry
• Perform baseline and anomaly analysis when detections are sparse or evasive
• Fuse threat intel (reports, ISAC feeds, campaign IOCs) into hunt plans and pivot queries
• Map behaviors to MITRE ATT&CK and document technique coverage gaps
• Deliver detection engineering feedback—candidate rules, data gaps, tuning notes
• Produce hunt reports and hand off confirmed malicious activity to CSIRT

When NOT to Use

• Triage and close routine SOC alerts, SOAR playbooks, shift handoffs → soc-analyst
• Declare incidents, lead containment, regulatory comms, or war room → incident-responder
• Plan or execute authorized red team / adversary simulation campaigns → red-team-specialist
• Acquire disk/memory images, chain of custody, super-timelines for counsel → digital-forensics-analyst
• Authorized exploitation, vuln validation, or pentest deliverables → penetration-tester
• Deep disassembly, decompilation, or malware RE lab work → reverse-engineer
• Implement cloud guardrails, CSPM remediation, or landing zone security → cloud-security-engineer
• Define enterprise security strategy, ISMS, or GRC roadmaps → cybersecurity

Related skills

Escalation chain

1. `soc-analyst` — triages alerts, enriches, runs playbooks; escalates suspicious clusters or hunt requests. 2. `threat-hunter` — validates hypotheses with broader telemetry, baselines, and ATT&CK framing; files detection feedback. 3. `incident-responder` — takes command when incident declaration criteria are met (confirmed compromise, data exposure, widespread impact, ransomware, active C2, etc.).

Hunters do not replace SOC queues or IR command. Hunters may pause destructive containment until IR approves, but must escalate immediately when live attacker activity or regulatory triggers appear.

Core Workflows

1. Intake and hypothesis

1. Capture trigger: SOC escalation, intel report, purple-team gap, post-incident pattern, leadership ask 2. State hypothesis in falsifiable form (“If actor X, we will see Y in Z data”) 3. Define success criteria, time range, data sources, and out-of-scope systems 4. Estimate effort; open hunt record with ID and owner

See `references/hypothesis_and_hunt_planning.md`.

2. Hunt execution

1. Inventory available telemetry; log gaps that block the hypothesis 2. Run staged queries (broad → narrow); save queries and result counts 3. Baseline “normal” for key entities; flag statistically or behaviorally rare events 4. Pivot on entities (user, host, IP, app, cloud principal, session) 5. Correlate across domains; attach UTC timestamps and source systems

See `references/siem_query_and_telemetry.md`.

3. Intel and ATT&CK mapping

1. Map observed behaviors to technique IDs; note procedure-level detail when known 2. Compare to relevant intel (sector campaign, actor profile, recent CVE/exploit chain) 3. Document coverage: detected vs hunted-only vs no visibility

See `references/threat_intel_and_attck_mapping.md`.

4. Detection feedback

1. For sustained true positives, draft candidate detection (logic, data source, expected FP rate) 2. Specify logging gaps (missing fields, retention, parser errors) 3. Hand tuning notes to detection owners; link hunt ID in ticket

See `references/detection_engineering_feedback.md`.

5. Report and handoff

1. Summarize hypothesis, methods, findings, and confidence 2. List IOCs, entities, and recommended actions (monitor, block, isolate, declare incident) 3. Route confirmed incidents to incident-responder with evidence package 4. Route benign closure back to soc-analyst with context for alert tuning

See `references/hunt_reporting_and_handoff.md`.

When to load references

• Role boundaries and handoffs → references/threat_hunter_scope.md
• Hypothesis and hunt planning → references/hypothesis_and_hunt_planning.md
• SIEM queries and telemetry → references/siem_query_and_telemetry.md
• Threat intel and ATT&CK → references/threat_intel_and_attck_mapping.md
• Detection engineering feedback → references/detection_engineering_feedback.md
• Hunt reporting and handoff → references/hunt_reporting_and_handoff.md

Outputs

• Hunt plan — hypothesis, scope, data sources, ATT&CK focus, timeline
• Query pack — saved searches with parameters and result summaries
• Findings table — entity, behavior, technique, evidence pointers, confidence
• Detection backlog — candidate rules, gaps, tuning recommendations
• Hunt report — executive summary, technical detail, next steps
• IR handoff package — when escalating to incident-responder

Detection engineering feedback

Table of contents

1. When to file feedback 2. Candidate detection template 3. Tuning and false positives 4. Data and parser gaps 5. Purple team loop

When to file feedback

Create detection engineering tickets when hunts find:

• Repeatable true positives without a production rule
• High-value behaviors seen once but likely to recur (living-off-the-land, cloud API abuse)
• Systematic false negatives due to missing fields, wrong index, or short retention
• Alert noise that caused SOC to miss related activity (tuning opportunity)

Do not file rules for one-off misconfigurations fixed by IT change management alone.

Candidate detection template

Attach example events (redacted) or saved search links—not full PII dumps.

Rule design principles

1. Prefer behavior + context over single IOC where possible 2. Add rate limits and allowlists for noisy admin tools 3. Stage: dev → limited prod → full prod with SOC review 4. Document owner and review cadence (quarterly for high-FP rules)

Tuning and false positives

When hunts explain why SOC missed activity:

• List alerts that fired but were closed incorrectly
• Recommend correlation (e.g., combine IdP + EDR signals)
• Suggest severity or queue changes with evidence counts
• Propose suppressions with explicit expiry and approver

Never tune global rules to silence a hunt finding without root-cause review.

Data and parser gaps

File infrastructure tickets when hunts are blocked by:

Quantify impact: “Hunt H-2024-017 could not evaluate T1053 without scheduled task events on servers X–Y.”

Purple team loop

After red-team-specialist or pentest exercises:

1. Import techniques attempted and detection results 2. Prioritize hunts on undetected techniques with realistic exposure 3. Close loop in hunt report: “Detection D-1234 added; retest on [date]”

Coordinate with purple team so hunt queries do not disrupt live operations or violate ROE.

Hunt reporting and handoff

Table of contents

1. Report structure 2. Findings table 3. Escalation to IR 4. Return to SOC 5. Metrics and program feedback

Report structure

Every hunt ends with a written report (ticket wiki or doc). Minimum sections:

1. Executive summary — hypothesis, outcome (found / not found / inconclusive), business impact 2. Scope — time range (UTC), systems, data sources, exclusions 3. Method — queries, baselines, intel used (with citations) 4. Findings — table below with confidence 5. ATT&CK coverage — techniques observed or ruled out 6. Actions — detections filed, IR escalation, IT fixes, monitoring 7. Appendix — query pack, IOC list, redacted samples

Separate facts from inferences. Mark speculative links clearly.

Findings table

Confidence:

• High — ready for containment discussion with IR
• Medium — needs SOC monitoring or short follow-up hunt
• Low — document only; do not drive disruptive response

Escalation to IR

Hand off to incident-responder when declaration criteria are met (confirmed malicious activity, data exposure suspected, ransomware, active C2, widespread compromise, regulatory trigger).

IR handoff package must include:

• Hunt ID and hypothesis
• UTC timeline of key events (attacker-relevant and defender-relevant)
• Affected users, hosts, accounts, apps, regions, data classes (if known)
• IOC table (type, value, first/last seen, source)
• Saved searches or log excerpts with pointers (not unbounded exports)
• Actions already taken (if any) and approval chain
• Open questions and recommended next containment steps (suggestions only—IR commands)

Do not declare the incident in place of IR unless you are the designated incident commander.

If live attacker activity is suspected, notify IR immediately by phone/page per severity matrix; finish the written package in parallel.

Return to SOC

When hunts close without incident criteria:

• Send summary to originating analyst with tuning guidance
• List alerts to close or link to parent ticket
• Note benign root causes (change ticket, new software, pen test IP ranges)
• Attach detection tickets for long-term improvement

SOC owns ongoing alert queue health; hunters do not become permanent tier-3 backlog.

Metrics and program feedback

Track for hunt program maturity (share with cybersecurity):

• Hunts per quarter by trigger type
• Time to first finding and total effort
• Detection yield — new or improved rules from hunts
• Incidents spawned — hunts that escalated to IR
• Inconclusive rate and top data gaps

Use metrics to justify logging investments, not to penalize “not found” hunts—negative results improve coverage maps.

Hypothesis and hunt planning

Table of contents

1. Hunt triggers 2. Hypothesis format 3. Hunt types 4. Planning checklist 5. Scoping and ethics

Hunt triggers

Accept work from:

• SOC escalation — correlated alerts, unknown true positives, noisy rules masking activity
• Threat intel — sector advisory, ISAC report, actor profile, leaked credentials
• Post-incident — hunt for related infrastructure after IR closes initial scope
• Purple / red feedback — techniques that evaded detection in exercise
• Baseline drift — new app, merger, cloud migration, or identity change breaking “normal”
• Leadership / audit ask — targeted assurance on technique or asset class

Decline or redirect pure alert backlog clearing to soc-analyst.

Hypothesis format

Write hypotheses so they can be falsified:

If [threat scenario / actor behavior], then we expect [observable behavior] in [data source] during [time window].

Add:

• Success criteria — what counts as confirmed, suspicious, or ruled out
• Null result value — “not found” still improves coverage documentation
• ATT&CK focus — tactic/technique IDs when known (e.g., T1078, T1021.001)

Bad: “Look for hackers.” Good: “If FIN-style actor uses stolen session cookies, we will see impossible-travel auth plus new device enrollments in IdP logs within 14 days.”

Hunt types

Time-box hunts (e.g., 4–40 hours); extend only with documented rationale.

Planning checklist

1. Assign hunt ID, owner, and stakeholders (SOC lead, detection engineer) 2. Define UTC window and retention limits per source 3. List required data sources; flag gaps early 4. Identify in-scope assets, regions, business units, and exclusions (personal devices, M&A carve-outs) 5. Draft initial query plan (broad → narrow); estimate false-positive volume 6. Set stop rules — max entities reviewed, escalation triggers, end date 7. Plan outputs — report template, detection tickets, IR escalation threshold 8. Record related incidents, tickets, and intel report IDs

Scoping and ethics

• Hunt only authorized enterprise systems and data you are permitted to access
• Privacy / HR: route insider-threat hunts through legal/HR policy; minimize PII in reports
• Production safety: prefer read-only queries; coordinate with IR before isolation or account disables
• Third parties: do not query customer tenants or partner environments outside contract scope

When scope is unclear, stop and confirm with security leadership before running broad searches.

SIEM query and telemetry

Table of contents

1. Telemetry inventory 2. Query workflow 3. Cross-domain pivots 4. Baselines and anomalies 5. Quality and gaps

Telemetry inventory

Before hunting, confirm availability and retention:

Document retention (hot/warm/cold), parse status, and known blind spots in the hunt record.

Query workflow

1. Anchor on a known entity, IOC, or time window from trigger 2. Broad pull — low-cardinality filters; count by entity 3. Rank — sort by rarity, first-seen, or deviation from baseline 4. Deep dive — pull full events for top N entities only 5. Validate — alternate data source confirms the same story 6. Snapshot — save query text, parameters, time range, and result count

Query hygiene

• Use UTC in queries; note display timezone in reports
• Prefer structured fields over raw regex when parsers exist
• Cap result sets; paginate or aggregate before exporting millions of rows
• Version queries in the hunt repo or ticket—do not rely on ad hoc UI history alone

Platform notes

• Splunk (SPL): tstats, datamodel, transaction for session stitching; watch index=* cost
• Microsoft Sentinel (KQL): join, has_any, ago(); use union sparingly with time bounds
• Chronicle / UDM: normalize entity fields; use reference lists for IOCs
• Elastic: ECS fields, runtime fields; watch cluster load on wildcards

Adapt syntax to your stack; principles are platform-agnostic.

Cross-domain pivots

Build a mini-timeline per entity before declaring malicious intent.

Baselines and anomalies

1. Define peer group (role, department, OS image, region) 2. Measure frequency (logins/day, rare processes, new destinations) 3. Flag first-seen or top-N rare with minimum volume thresholds 4. Exclude known change windows (patch Tuesday, marketing campaigns) 5. Re-check flagged entities manually—automation suggests, humans confirm

Document baseline assumptions; stale baselines create false hunts.

Quality and gaps

Log issues for detection engineering:

• Missing fields (no process.command_line, no source.ip on cloud events)
• Clock skew between sources (>5 minutes)
• Duplicate or dropped events
• Parser errors and mis-tagged action values

Stop or narrow the hunt if critical data is unavailable; state inconclusive rather than over-interpreting partial logs.

Threat hunter scope

Table of contents

1. Mission 2. In scope 3. Out of scope 4. Handoffs 5. Operating principles

Mission

Operate as advanced SOC threat hunting: proactively test falsifiable hypotheses against enterprise telemetry, find malicious or high-risk activity that alerts missed, and improve detections. Optimize for coverage, evidence quality, and measurable outcomes—not for closing every SOC ticket or commanding live incidents.

In scope

• Hypothesis-driven hunts — intel-led, ATT&CK-led, baseline/anomaly-led, or post-incident pattern hunts
• Advanced querying — SIEM (SPL, KQL, SQL, Lucene), EDR hunt queries, cloud audit/API logs, identity logs
• Baseline and anomaly analysis for users, hosts, apps, and cloud principals
• Threat intel fusion — map behaviors to campaigns, actors, and sector reporting (with source attribution)
• MITRE ATT&CK technique mapping and coverage gap documentation
• Detection engineering feedback — candidate rules, data model fixes, tuning guidance
• Hunt reporting — findings, confidence, IOCs, recommended actions
• Escalation packages to CSIRT when incident criteria are met

Out of scope

Handoffs

From `soc-analyst`:

• Escalate when alerts cluster into a plausible campaign, detections are evasive, or leadership requests a hunt
• Provide: alert IDs, entities, initial IOCs, UTC window, analyst notes, what was ruled out

To `incident-responder`:

• Escalate when incident declaration criteria are met—do not wait for hunt “completion” if active compromise is likely
• Handoff: hunt ID, hypothesis, findings table, IOCs, key log excerpts or query links, affected entities, open questions

To `soc-analyst` (closure):

• Return benign or low-risk outcomes with tuning notes so alerts can be closed or suppressed safely

To detection / engineering:

• File candidate detections and logging gaps with hunt ID; do not silently change production rules without owners

To `digital-forensics-analyst` / `reverse-engineer`:

• When hunts surface samples or need preserved images—after IR/legal approves acquisition scope

Operating principles

1. Hypothesis first — every hunt states what would confirm or refute it 2. UTC everywhere — normalize timestamps; document source timezone quirks 3. Evidence over narrative — cite query, log source, and row identifiers 4. Minimize attacker insight — avoid unnecessary live interaction with suspected C2 or accounts until IR aligns 5. Measure outcomes — hunts end with found / not found / inconclusive plus detection actions

Threat intel and ATT&CK mapping

Table of contents

1. Intel sources 2. Fusion workflow 3. ATT&CK mapping 4. Coverage gaps 5. Confidence and attribution

Intel sources

Use authorized feeds and internal context:

• Commercial TI platforms, ISAC/ISAO sharing, government advisories (sector-specific)
• Vendor reports (campaign names, IOC bundles, TTP summaries)
• Internal: prior incidents, pentest/red team reports, purple-team results
• OSINT only when policy permits; cite URLs and retrieval date

Record provenance for every IOC and TTP claim in the hunt report.

Fusion workflow

1. Extract IOCs (hash, domain, IP, email, cert thumbprint) and TTPs from intel 2. Normalize — de-duplicate, expire stale IOCs, note false-positive history 3. Map IOCs to enterprise telemetry (proxy, DNS, EDR, email, cloud) 4. Expand — pivot on hits to related entities (same ASN, parent domain, tooling family) 5. Contrast — compare findings to intel narrative; note mismatches 6. Update detection backlog and SOC runbooks when sustained true positives appear

Do not block production solely on low-confidence IOCs without corroboration.

ATT&CK mapping

For each observed behavior, document:

Use ATT&CK to structure hunts, not to inflate technique counts. Prefer procedure-level detail your defenders can action.

Hunt framing by tactic

Coverage gaps

Maintain a simple matrix for the hunt:

• Detected — alert fired and investigated
• Hunted only — found manually; no reliable rule
• No visibility — required log missing or retention too short

Feed gaps to detection_engineering_feedback.md and program owners (cybersecurity for prioritization).

Confidence and attribution

Use graded confidence on findings:

• High — multiple independent sources, strong temporal correlation
• Medium — single strong source or weak multi-source
• Low — circumstantial; needs more collection

Attribution to named actors is optional and often not required for defensive action. State “consistent with [campaign/actor]” only when intel supports it. Never claim legal attribution.

When intel conflicts with observations, trust local evidence and document the delta.