Skip to content
eastbaycyber

What is Threat Hunting? A Practitioner's Definition

FAQs 7 min read
EC
East Bay Cyber Editorial Team Reviewed 2026-09-16
Short answer

TL;DR - Threat hunting is the proactive search for attacker activity that automated alerts may have missed. - Start with a focused hypothesis, searchable logs, and a documented investigation process. - Hunt regularly, prioritize high-value systems, and turn validated findings into detections.

Definition

Threat hunting is the proactive, human-led process of searching an environment for signs of compromise, attacker behavior, or security weaknesses that existing controls have not identified. Unlike alert triage, threat hunting begins with a question or hypothesis and uses available telemetry to find evidence.

Threat hunting is not the same as waiting for an alert, scanning randomly for malware, or investigating every unusual event. It is a structured process for finding potentially malicious activity that automated security controls may have overlooked.

How threat hunting works

Threat hunting is an investigation rather than a single tool or product. A practical hunt usually follows five stages.

1. Form a hypothesis

A hypothesis gives the hunt a clear scope. It should describe a behavior you want to test, not simply a vague concern.

Examples include:

  • An attacker may be using PowerShell to download and execute payloads on workstations.
  • A compromised account may be authenticating from unusual countries or cloud providers.
  • Sensitive files may be copied to an unauthorized external service.
  • Endpoint detection coverage may be missing suspicious use of remote administration tools.

A good hypothesis is specific enough to investigate and broad enough to reveal unknown activity.

2. Identify useful data

Determine which evidence can confirm or disprove the hypothesis. Depending on the question, this may include:

  • Endpoint process, command-line, and file events
  • Authentication and identity-provider logs
  • DNS queries and proxy activity
  • Firewall and network-flow records
  • Cloud audit logs
  • Email security telemetry
  • Application and database logs

Data quality matters. If command-line arguments are not collected, for example, a hunt for suspicious script execution may produce incomplete results. Record the time range, data sources, retention period, and known collection gaps before interpreting the results.

Identity-focused hunts may also reveal weak account practices. A password manager such as 1Password can help organizations enforce stronger, unique credentials, but it does not replace identity monitoring or investigation.

3. Search for behavior

Search for patterns associated with the hypothesis. Avoid relying only on malware names, hashes, or static indicators because those can change quickly. Behavioral examples include:

  • A scripting engine launched by an unusual parent process
  • A user authenticating at an unusual time or from a new location
  • A workstation querying many rare domains
  • A service account interacting with systems outside its normal scope
  • An archive utility compressing data in a sensitive directory

The objective is not to label every unusual event as malicious. It is to identify activity that deserves validation.

4. Validate and investigate

Potential findings require context. Compare the activity with:

  • The user’s role and normal behavior
  • The host’s function and ownership
  • Approved software and administrative tools
  • Change-management records
  • Known maintenance windows
  • Related events before and after the observation

A suspicious command launched by a software deployment platform may be expected. The same command launched by a spreadsheet application on a finance workstation may warrant escalation.

5. Document and improve

Record the hypothesis, query, time range, results, false positives, investigation decisions, and final disposition. If the hunt identifies malicious or unauthorized behavior, preserve relevant evidence and follow the incident response plan.

If the behavior is legitimate, tune the search or document the exception. If it is suspicious but not confirmed, consider creating a detection, collecting additional telemetry, or scheduling a follow-up hunt. Mature programs turn successful hunts into repeatable detections and use failed hunts to expose visibility gaps.

How to start threat hunting

You do not need a dedicated threat-hunting team to begin. Start with a narrow, repeatable workflow.

First, inventory your available telemetry. Confirm that your security information and event management platform, endpoint platform, identity provider, cloud services, and network devices are forwarding the logs you expect. Check whether timestamps are synchronized and whether retention covers the period you need to investigate.

Next, choose a high-value use case. Prioritize behaviors that could affect privileged accounts, internet-facing systems, endpoints with sensitive data, or business-critical applications. A small organization might begin with unusual administrator logins, suspicious PowerShell activity, or new forwarding rules in email accounts.

Then write one hypothesis and define success criteria. For example:

Find PowerShell executions on user workstations that download content from external URLs during the past 14 days.

Identify the fields needed, such as hostname, username, parent process, command line, destination, and timestamp.

Finally, schedule the work. A monthly hunt is more useful than an ambitious process that happens once. Track findings and convert high-confidence patterns into alerts or automated response rules only after validating their false-positive rate.

Technical notes

A basic hunt can begin with a log search. The syntax depends on your platform, but the logic should be portable:

event.category = "process"
AND process.name IN ("powershell.exe", "pwsh.exe")
AND (
  process.command_line CONTAINS "DownloadString"
  OR process.command_line CONTAINS "Invoke-WebRequest"
  OR process.command_line CONTAINS "FromBase64String"
)

For Linux systems, a first-pass review of recent authentication activity might include:

# Review recent SSH authentication events
sudo journalctl --since "14 days ago" _SYSTEMD_UNIT=sshd.service

# Search common authentication logs for failed or accepted SSH access
sudo grep -Ei "failed|accepted|invalid user" /var/log/auth.log

Treat command-line matches as leads, not proof of compromise. Administrative scripts, software deployment tools, and security testing can generate similar events. Always pivot to the account, host, parent process, network connections, and related timeline.

Threat hunting techniques

Effective threat hunting techniques focus on behavior, context, and relationships between events. Common approaches include:

Hypothesis-driven hunting

Begin with a specific question based on threat intelligence, a recent incident, a control gap, or a change in the environment. This approach helps limit scope and makes results easier to measure.

Baseline and anomaly hunting

Establish what normal activity looks like for users, hosts, applications, and service accounts. Investigate meaningful deviations, such as a service account accessing a new system or a workstation contacting an unusual number of domains.

Tactic- and technique-based hunting

Map searches to adversary tactics and techniques, such as credential access, persistence, lateral movement, or data collection. This can help teams test whether their telemetry covers common attacker behaviors.

Indicator-led hunting

Search for known domains, IP addresses, file hashes, filenames, or other indicators from trusted intelligence sources. Because indicators can become outdated or be changed by attackers, combine them with behavior-based searches.

Detection-gap hunting

Use previous incidents, failed alerts, or coverage reviews to identify behaviors that existing controls may not detect. The result may be a new query, better logging, or an improved alert.

When you’ll encounter threat hunting

Threat hunting appears in several situations:

  • Routine security operations: Analysts search for activity that alerts have not surfaced.
  • After a security incident: Teams look for lateral movement, persistence, or additional affected systems.
  • During threat intelligence reviews: New adversary tactics, techniques, or infrastructure inform focused searches.
  • When deploying new controls: Hunts test whether logging and detection coverage work as intended.
  • During audits or risk reviews: Organizations assess whether critical assets show signs of unauthorized activity.
  • After major environmental changes: Cloud migrations, mergers, remote-work changes, and new identity systems can create new attack paths.

Hunting is especially valuable when you suspect that prevention and detection controls are incomplete. It should complement, not replace, patching, secure configuration, vulnerability management, and incident response.

Organizations may also use threat hunting to validate whether security controls support broader governance requirements, including the monitoring and evidence practices associated with ISO 27001.

Threat hunting vs. detection and incident response

Threat hunting, security detection, and incident response support different stages of security operations:

  • Detection uses rules, analytics, and alerts to identify potentially suspicious activity automatically.
  • Threat hunting proactively searches for activity that may not have generated an alert.
  • Incident response contains, investigates, eradicates, and recovers from a confirmed or suspected security incident.

The boundaries can overlap. A hunt may uncover an incident, and an incident investigation may generate new hunting ideas. However, not every hunt produces an incident, and not every alert requires a full hunting exercise.

  • Detection engineering: Designing and maintaining rules that automatically identify suspicious activity. Threat hunting can provide the research and evidence used to build those rules.
  • Threat intelligence: Information about adversaries, campaigns, tools, infrastructure, and tactics. Intelligence can help define hunt hypotheses.
  • Incident response: The process of containing, investigating, and recovering from a confirmed or suspected security incident.
  • Security monitoring: The continuous collection and review of security events. Monitoring often generates alerts, while hunting searches proactively for overlooked activity.
  • Indicators of compromise: Observable artifacts such as malicious domains, file hashes, or suspicious IP addresses. Hunts should use indicators carefully and include behavior-based investigation.
  • Adversary emulation: Controlled testing that reproduces attacker techniques to evaluate defenses. It can validate whether a hunt or detection identifies simulated activity.
  • Purple teaming: Collaboration between offensive and defensive teams to test attack techniques, detections, and response procedures.
  • SIEM: A platform that collects and analyzes security logs. It is a common place to run hunts, but endpoint, identity, cloud, and network tools may also be required.

A useful starting principle is simple: ask a focused security question, search reliable data, validate the context, and preserve what you learn. Repeating that cycle builds visibility and steadily improves detection coverage.

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.

Last verified: 2026-09-16

Disclaimer: This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.