/hunting-threats

name: hunting-threats
description: Run hypothesis-driven threat hunts across endpoint, network, cloud, and identity telemetry using stack counting, outlier analysis, and ATT&CK-based hypotheses, with SIEM query patterns for Splunk, KQL, and Elastic. Use when proactively searching for undetected compromise, validating an intel report against your environment, or converting a hunch into a repeatable hunt.
verified: 2026-07-27

Hunting Threats

Hunting starts from an assumption of failure: the controls are deployed, no alert has fired, and the adversary may still be present. The output is not usually a compromise — it is a detection, a telemetry gap, or a documented negative result. Hunts that only count as successful when they find something degrade into confirmation bias.

When to Use

• Proactively searching for compromise that detection missed
• Testing a specific hypothesis about attacker behaviour in your environment
• Operationalizing a threat intel report against your telemetry
• Validating that a control or detection actually works in production
• Baselining an environment to enable future outlier analysis

When NOT to Use

• **Working an alert queue rather than a hypothesis** — use

`triaging-security-alerts`; a hunt starts from a question, triage from a queue

• **Confirmed incident in progress** — use `responding-to-incidents`
• **Writing the rule for what you found** — use `engineering-detections`
• **Sample analysis** — use `analyzing-malware`
• **A packet capture to work through** — use `analyzing-network-traffic`
• **A confirmed AWS compromise to investigate** — use `investigating-aws-incidents`
• **Pivoting on indicators, tracking an actor, or producing a finished intel

product** — use `producing-threat-intelligence`; a hunt consumes intelligence, it does not produce it

• **Offensive testing of defenses** — use the red team skills

Hypothesis Before Query

An unstructured search through logs is browsing, not hunting. Every hunt gets a written hypothesis in this shape:

> **Hypothesis:** An adversary with [access level] is using [technique] to > [objective], which would produce [observable] in [data source], which is > distinguishable from normal because [discriminator]. > > **If true, I expect to see:** ... > **If false, I expect:** ... > **Telemetry required:** ... (verified present: yes/no)

If you cannot name the discriminator — what makes the malicious instance look different from the thousands of benign ones — the hunt is not ready. Go find the discriminator first; that research is the hunt.

Hypotheses come from: recent intel on actors targeting your sector, ATT&CK techniques with no detection coverage, crown-jewel assets and the paths to them, anomalies noticed during other work, and post-incident "what else would this actor have done."

Hunting Techniques

Stack counting (frequency analysis)

The workhorse. Aggregate a field, sort ascending, investigate the rare values. Malicious activity is usually rare; commodity noise is common.

-- Splunk: rarest parent-child process pairs
index=sysmon EventCode=1
| stats count dc(host) as hosts by ParentImage, Image
| where count < 10 AND hosts < 3
| sort count

// KQL: rarely-seen signed binaries making external connections
DeviceNetworkEvents
| where RemoteIPType == "Public"
| summarize Count=count(), Hosts=dcount(DeviceName) by InitiatingProcessFolderPath
| where Hosts <= 2 and Count < 20
| order by Count asc

Stack the right field. Stacking `Image` finds unusual binaries; stacking `ParentImage, Image` finds unusual *relationships*, which is where living-off the-land abuse shows up (`winword.exe` → `powershell.exe`).

Outlier analysis

Same shape, different axis: what is normal *for this entity*?

• A service account that has never used interactive logon, now doing so
• A workstation talking to an internal subnet it has never touched
• A user authenticating outside their historical hours and geography
• A host whose process-count baseline shifted after a specific date

-- Elastic ES|QL: first-seen external destinations per host
FROM logs-network-*
| WHERE destination.ip NOT IN CIDR("10.0.0.0/8","172.16.0.0/12","192.168.0.0/16")
| STATS first_seen = MIN(@timestamp), n = COUNT(*) BY host.name, destination.domain
| WHERE first_seen > NOW() - 7 days AND n > 20

Grouping and clustering

Cluster on a shared attribute to surface campaigns: same JA3/JA4 across unrelated hosts, same rare user agent, same certificate serial, same working hours, same directory of execution.

Intel-driven hunting

Take a report, extract the TTPs rather than the IOCs, and hunt those. The report's hashes and IPs are dead; its described behaviour is not.

Report says:  "uses schtasks to create a task running a DLL via rundll32"
Bad hunt:     search for the report's hash
Good hunt:    every scheduled task created in the last 90 days whose action
              references rundll32, stacked by task name and DLL path

High-Yield Hunting Grounds

| Hypothesis area | What to look for | | --- | --- | | Execution via LOLBins | `rundll32`, `regsvr32`, `mshta`, `certutil`, `bitsadmin`, `msiexec` with network or unusual arguments; `curl`/`wget` piping to a shell on Linux | | Persistence | Scheduled tasks/cron/systemd units created recently; WMI event subscriptions (rare and almost always malicious); run keys; new services; `authorized_keys` modifications | | Credential access | LSASS handle opens, `ntds.dit` copies, shadow-copy creation, Kerberos RC4 requests (4769 with encryption type 0x17), DCSync replication rights use | | Lateral movement | Admin share writes followed by service creation, WinRM/WMI from non-admin hosts, SSH from workstations to servers, RDP chains | | C2 | Beacon timing regularity, long-lived connections, DNS with high entropy or high subdomain cardinality, TLS with rare JA3/JA4 | | Exfiltration | Outbound volume outliers per host, archive creation followed by