Cyber threat hunting: techniques and best practices

Threat hunting is the proactive search for adversary activity that automated detections didn’t catch. Firewalls, EDR, SIEM correlation rules, and antivirus all trigger on known-bad patterns. Hunting starts from the assumption that some adversary has already gotten past those controls and asks: if they had, what would we see?

The discipline sits at the intersection of incident response (the investigative craft), threat intelligence (the knowledge of what adversaries actually do), and detection engineering (turning findings into repeatable automated coverage). A hunt that produces a detection rule is worth more than a hunt that produces only a report.

The hunting loop

#

Most modern hunt frameworks share a variation of the same four-step loop:

1. Hypothesis generation. Start with a specific claim: “adversary X uses technique Y, and if they’re in our environment, we’d see artifact Z in data source W.” Vague hypotheses (“look for malware”) don’t converge; specific ones do.
2. Investigation. Query the data sources named in the hypothesis. Look for the artifacts. Rule things in or out based on what you actually find.
3. Verification. When something looks suspicious, verify. Real hunters spend most of their time here, distinguishing malicious activity from unusual-but-benign behavior.
4. Feedback. Every hunt produces one of three outputs: a confirmed incident (hand off to IR), a new detection rule (feed to detection engineering), or a documented negative result (still valuable, prevents re-hunting the same hypothesis).

Splunk’s SURGe team formalized this as the PEAK framework (Prepare, Execute, Act with Knowledge) in 2023, but the shape is older than that. Sqrrl’s TaHiTI methodology predates it. The specifics matter less than having a repeatable loop.

The Pyramid of Pain

#

David Bianco’s Pyramid of Pain is the reference model for choosing what to hunt for. From easiest to hardest for defenders to detect (and hardest to easiest for adversaries to change):

• Hash values (trivial for adversary to change, trivial for defender to match)
• IP addresses
• Domain names
• Network and host artifacts (registry keys, filenames, mutex names)
• Tools (the actual binaries and frameworks in use)
• Tactics, Techniques, and Procedures (TTPs, the hardest for adversaries to change)

Hunt at the top of the pyramid when you can. A detection built around a TTP (say, “PowerShell downloading from a non-standard TLS port”) survives the adversary switching hashes, IPs, and even tools. A detection built on a hash breaks the moment the adversary rebuilds.

Hunting surfaces

#

The four standard categories of hunt correspond to where the telemetry comes from.

Network hunting

#

Network-based hunts analyze traffic (packet captures, flow records, DNS logs, TLS metadata) to find adversary activity on the wire. The primary tools are Zeek, Suricata, and NetFlow analyzers.

Zeek (renamed from Bro in 2018) is a network security monitor that produces structured logs from every connection: conn.log, dns.log, ssl.log, http.log, and dozens more. Zeek’s scripting language lets you write custom detection logic:

# Alert on repeated failed SSH auth attempts from the same source
@load base/protocols/ssh

module Notice;

export {
    redef enum Notice::Type += { SSH::Bruteforcing };
}

global ssh_threshold: count = 10 &redef;
global ssh_window: interval = 5min &redef;

global ssh_failures: table[addr] of count &create_expire=ssh_window;

event ssh_auth_failed(c: connection) {
    local orig = c$id$orig_h;

    if (orig !in ssh_failures)
        ssh_failures[orig] = 0;

    ssh_failures[orig] += 1;

    if (ssh_failures[orig] >= ssh_threshold) {
        NOTICE([$note=SSH::Bruteforcing,
                $src=orig,
                $msg=fmt("Possible SSH brute force from %s (%d failed attempts)",
                        orig, ssh_failures[orig])]);
        ssh_failures[orig] = 0;
    }
}

Zeek ships with detection scripts for common patterns; the zeek/zeek and corelight/zeek-community-id repos are good starting points.

Suricata is a signature-based IDS/IPS that fills a complementary role. Where Zeek writes structured logs about what happened, Suricata alerts on specific patterns matching known malicious traffic. The Emerging Threats (ET) Open ruleset is the standard community feed:

alert http $HOME_NET any -> $EXTERNAL_NET any \
    (msg:"ET INFO Suspicious User-Agent (Empty)"; \
     flow:established,to_server; \
     http.user_agent; content:!""; \
     classtype:policy-violation; sid:2027000; rev:1;)

Modern deployments run Zeek and Suricata together on the same traffic, using the structured logs from Zeek and the alerts from Suricata as complementary signals in a SIEM.

Flow analysis with NetFlow, sFlow, or IPFIX gives you traffic metadata (source, destination, ports, bytes, packet counts) without full packet capture. This scales to backbone rates where full packet capture doesn’t. Tools like SiLK and Elastiflow analyze flow data at scale.

Endpoint hunting

#

Endpoint hunts look at process trees, filesystem changes, registry modifications, network connections initiated from a specific host, and memory contents. EDR platforms centralize this collection, but the underlying techniques work standalone too.

OSQuery (originally from Facebook, now maintained by the Linux Foundation ) exposes operating system state as a SQL-queryable interface. It’s the single most flexible endpoint hunt tool for Linux, macOS, and Windows:

-- Processes running from unusual locations
SELECT p.pid, p.name, p.path, p.cmdline, p.parent, u.username
FROM processes p
LEFT JOIN users u ON p.uid = u.uid
WHERE p.path LIKE '/tmp/%'
   OR p.path LIKE '/dev/shm/%'
   OR p.path LIKE '/var/tmp/%';

-- Suspicious network listeners
SELECT DISTINCT process.name, listening.port, listening.address, process.cmdline
FROM listening_ports AS listening
JOIN processes AS process ON listening.pid = process.pid
WHERE listening.address = '0.0.0.0';

Velociraptor (originally by Mike Cohen, backed by Rapid7 since the September 2021 Velocidex acquisition, still open source under GPL) is the modern remote-endpoint hunting and DFIR platform. It’s what many teams reach for instead of GRR Rapid Response, which is still maintained by Google but is no longer the default choice for new deployments. Velociraptor uses its own VQL query language and includes a large library of prebuilt hunt artifacts.

Memory analysis with Volatility 3 reveals process injection, hidden processes, and in-memory-only malware that never touches disk. The v2 to v3 shift in 2020 dropped explicit profiles in favor of automatic symbol detection:

# Volatility 3 syntax (current)
vol -f memory.dmp windows.pslist
vol -f memory.dmp windows.malfind
vol -f memory.dmp windows.netscan

# Volatility 2 syntax (legacy)
volatility -f memory.dmp --profile=Win7SP1x64 pslist

Log-based hunting

#

Centralized logs are where most hunts actually happen. Modern platforms:

• Elastic Security (built on the Elastic Stack) has evolved from generic log aggregation into a security-focused SIEM/XDR with prebuilt detection rules and hunt workflows.
• Splunk with Enterprise Security remains the commercial standard, with a mature hunt-focused ecosystem and a very large community rule library.
• Wazuh is an open-source SIEM/XDR platform built on OpenSearch with agent-based endpoint monitoring. Popular for teams that can’t run Splunk or don’t want to run Elastic.
• Sekoia.io, Panther, and Chronicle cover the cloud-native SIEM/detection-as-code market.

Log-based hunts translate the hypothesis into a query. A hypothesis of “adversary is using PowerShell for lateral movement” becomes something like:

event.dataset:powershell.operational
  AND process.command_line:(*Invoke-Command* OR *Enter-PSSession* OR *New-PSSession*)
  AND destination.ip:*
  AND NOT source.user.name:(known_admin OR service_account)

The specifics depend on your platform, but the shape is universal: filter to the right data source, apply behavioral criteria that reflect the technique, exclude known-benign patterns, review results.

Threat intelligence-based hunting

#

Threat intelligence provides the “what to hunt for” input to the hypothesis step. Sources include:

• Government feeds: CISA, NCSC, CERT-EU
• Commercial providers: Mandiant, Recorded Future, CrowdStrike, Microsoft
• Community: MISP , OpenCTI , ISACs (Information Sharing and Analysis Centers) for your industry
• Open source: Malware Bazaar , URLhaus , ThreatFox , threat researcher blogs

The three common shapes of intel-driven hunt:

IOC hunting. Given hashes, IPs, domains, or URLs from a threat report, search your telemetry for matches. Fastest to execute, lowest on the Pyramid of Pain, but still useful for retrospective coverage after an intel drop. Push IOCs into your existing detections rather than one-off scanning.

TTP hunting. Given adversary techniques mapped to MITRE ATT&CK , hunt for evidence of those techniques in your environment. The current ATT&CK release covers 14 tactics and 200+ techniques with sub-techniques and detection guidance, and moved to a rolling update cadence in 2026 rather than the old biannual major versions. A hunt for T1055 (Process Injection) doesn’t care what specific tool the adversary used, only that the technique fingerprint appears.

Actor hunting. Given a specific threat actor’s known TTPs, tooling, and targeting patterns, hunt for their fingerprint in your environment. Useful when your industry or geography maps to a known actor’s targeting.

Sigma: portable detection rules

#

Sigma is a generic, open-source signature format for SIEM rules. Write once in Sigma YAML, translate to Splunk SPL, Elastic KQL, Sentinel KQL, Chronicle YARA-L, or a dozen other backends via sigmac or Uncoder.io :

title: Suspicious PowerShell Encoded Command
id: 3c25e...
status: experimental
description: Detects PowerShell processes launched with encoded commands
author: your name
date: 2026/01/15
logsource:
  product: windows
  category: process_creation
detection:
  selection:
    Image|endswith: \powershell.exe
    CommandLine|contains:
      - ' -enc '
      - ' -EncodedCommand '
      - ' -e '
  condition: selection
level: medium
tags:
  - attack.execution
  - attack.t1059.001

The SigmaHQ ruleset currently ships over 3,000 community-maintained detection rules mapped to ATT&CK. This is often the fastest path from “here’s a new technique” to “we have detection coverage.”

Real-world hunts worth studying

#

Case studies from public incident reports. Each is documented enough to reconstruct how the hunt worked.

APT29 SUNBURST discovery (December 2020). Mandiant, hunting through their own internal telemetry after detecting a suspicious authentication event, uncovered the SolarWinds Orion supply-chain compromise. APT29 (Cozy Bear, attributed to Russian SVR) had backdoored Orion updates. The hunt combined DNS traffic analysis, endpoint process behavior, and cloud identity anomalies. Public writeups from Mandiant and CISA are extensive.

WannaCry containment (May 2017). During the WannaCry outbreak (attributed to Lazarus, DPRK), Marcus Hutchins (MalwareTech) discovered the ransomware queried an unregistered domain before executing. He registered the domain as a sinkhole, which unintentionally functioned as a kill switch and stopped the spread. The story is a good demonstration of how quickly hunter-analyst intuition can produce operational impact.

NotPetya attribution and vector (June 2017). NotPetya (attributed to Sandworm, Russian GRU) initially looked like ransomware but was designed for destruction. Investigators traced the initial vector to the M.E.Doc accounting software (used by Ukrainian businesses) supply chain compromise, then followed the propagation through EternalBlue and stolen credentials. The hunt required correlating telemetry across dozens of affected organizations.

Emotet takedown and return (2021, 2021-present). Operation Ladybird (January 2021) was a multi-country law enforcement action that seized Emotet infrastructure and pushed a self-uninstaller. Emotet returned in November 2021 and has continued cycling active/dormant periods since. Hunts for Emotet artifacts remain relevant because the operators re-use TTPs across cycles.

ShadowBrokers “Lost in Translation” (April 2017). After the ShadowBrokers group released a cache of NSA-attributed offensive tools including EternalBlue, defenders had roughly a month before WannaCry weaponized the same exploit publicly. Retrospective hunts for pre-WannaCry EternalBlue exploitation attempts (and for related tools like DoublePulsar) were widespread across every major security team.

Practical tooling summary

#

Building a hunting program

#

A few operational patterns worth adopting:

Log every hunt. Hypothesis, data sources, queries, findings, disposition. A running record of past hunts prevents duplicated work and gives you data to measure the program.

Turn hunts into detections. When a hunt uncovers something worth detecting, write the Sigma or platform-specific rule before closing the ticket. Otherwise the same activity slips past next time.

Measure what matters. Time-to-detect and time-to-remediate for incidents that started as hunt findings. Number of new detection rules produced per quarter. Coverage percentage against MITRE ATT&CK techniques relevant to your threat model. Avoid vanity metrics (number of hunts run) that don’t reflect outcomes.

Cross-pollinate with red team. Purple team exercises where red team executes known TTPs while blue team hunts for them close the loop between “we have detection coverage” and “we actually detected this.” The Atomic Red Team library from Red Canary provides scripted TTP tests mapped to ATT&CK.

Feed threat intel back. When your hunt finds a novel TTP or indicator, share it (through your ISAC, a public report, or a Sigma pull request). The community intel you consume was contributed by teams doing the same thing.

Where the discipline is heading

#

Threat hunting and detection engineering are converging. The output of a mature hunting program isn’t a stack of one-time investigations; it’s a growing library of automated detections that catch the next occurrence of the same behavior. Tools like Detection Studio and Panther treat detections as code with version control, testing, and CI/CD.

The other significant shift is the growing role of machine learning in anomaly detection. It’s not replacing hypothesis-driven hunting, but it’s changing what hunters spend their time on: fewer “look for X” queries, more “review the top 20 anomalies the model surfaced this morning.” Whether that ends up producing better outcomes depends heavily on how the models are trained and how their outputs are triaged.

The core skill hasn’t changed: form a specific hypothesis, look for evidence, act on what you find, feed the result back into your defenses.