End of summer sale is here! For a limited time. Enjoy a 15% discount on all our courses.
Mehmet Ergene

What Is Threat Hunting in 2026?

Nowadays, it is common to see many different definitions of threat hunting. As the cybersecurity field has expanded, professionals from different disciplines have started labeling a wide range of activities as threat hunting.

For example, you may see Cyber Threat Intelligence (CTI) analysts, and even CTI vendors, describe their work as threat hunting when they search for malware using YARA rules or track adversary infrastructure with tools such as Censys or VirusTotal.

Similarly, incident responders who begin investigating logs after receiving an alert sometimes refer to this activity as threat hunting, occasionally calling it reactive threat hunting.

But if almost any security investigation can be called threat hunting, does the term still mean anything?

Let's look at why I don't consider these activities threat hunting.

First, we need a working definition:

"Threat hunting is a proactive, iterative approach to searching through networks, endpoints, and datasets to detect malicious activity that evades existing security controls."
That definition gives us several useful boundaries: proactive, iterative, searching within an operational environment, and looking for malicious activity that existing controls failed to identify.

Adversary Infrastructure Tracking Using VirusTotal or Censys as Threat Hunting

Tracking adversary infrastructure using platforms such as VirusTotal or Censys is exactly that: tracking.

You are researching adversary infrastructure, malware, certificates, domains, IP addresses, relationships, and other artifacts.

That work can be extremely useful. It can produce intelligence that later becomes input for a hunt.

But what security control are you trying to determine was bypassed?

What operational environment are you hunting inside?

If I pivot through VirusTotal looking for infrastructure related to a malware family, I am conducting intelligence research. I am not searching my environment for malicious activity that escaped my security controls.

Tracking adversaries is cool and badass. It just doesn't need to be called threat hunting.

Alert Triage and Investigation as Threat Hunting

This is probably the most interesting claim.

Going back to the definition, threat hunting searches for malicious activity that has evaded existing security controls. An alert means that at least one security control detected something. That does not mean the adversary did not evade other controls before or after the alert. An alert can absolutely become a useful starting point for a broader investigation. 

But that does not automatically turn the investigation into threat hunting.

A common counterargument is:
"I hunt for what else the adversary might have done."
This sounds reasonable. But at that point, what separates the activity from alert triage or incident investigation?

You already have evidence of potentially malicious activity. You now need to determine scope, impact, affected systems, persistence, lateral movement, credential access, and whatever else the attacker may have done. That is exactly what incident responders are supposed to do. Calling part of that process "reactive threat hunting" does not necessarily create a new discipline. In many cases, it simply renames triage/investigation.
Another common argument involves hypotheses.

Let's say an alert indicates initial access, and you create the following hypothesis:
"The attacker may create a scheduled task for persistence."
So you search for scheduled-task creation.

What happens if the attacker used a service, WMI event subscription, startup folder, registry Run key, DLL side-loading, account manipulation, or another persistence mechanism?

Will you stop and close the alert as a false positive because your scheduled-task hypothesis was disproven?

Of course not.

You will investigate all plausible persistence mechanisms because you are trying to establish what the attacker actually did.

That is incident investigation.
Speaking of hypotheses, I've also seen people describe steps like these as threat-hunting hypotheses:

  • "Find the initial-access payload on the system."
  • "Identify the file referenced by the scheduled task."


Those are investigative tasks, not hypotheses. A hypothesis should make a testable statement about activity that may be occurring in the environment. 

If every investigative question, search query, or SOP step becomes a "hypothesis," the word loses its purpose too.

Grey Area: IOC Hunting

IOC-based threat hunting creates much more interesting debate.

Some practitioners argue that searching for IOCs is not threat hunting at all, while others strongly disagree.

I think the answer depends on what you are searching for and why.

Certain IOC searches should probably be automated, especially high-volume or low-context indicators such as IP addresses, file hashes, and domains. If your hunt consists of manually taking 500 SHA256 hashes from a threat-intelligence report and searching your SIEM for matches, you may want to ask why a detection or SOAR pipeline is not doing that continuously.

But not all indicators are equal. Some indicators describe artifacts or behaviors produced by attacker tooling and can expose malicious activity surprisingly well. For example, SharpHound, commonly used to enumerate Active Directory and collect data for BloodHound, can create output files using a predictable naming pattern:
<timestamp>_BloodHound.zip

An adversary may not change that behavior. They may not know about it, may not care, or may simply forget. That creates an opportunity. Instead of searching for known malicious hashes, you can search historical file-creation telemetry for files matching that pattern and then investigate the systems, users, processes, and surrounding activity associated with those files.

Does this provide broad coverage for Active Directory reconnaissance?

No.

Could it identify activity that your existing controls missed?

Absolutely.

That is where IOC hunting becomes more interesting. 

Threat Hunting in Practice

I've been working as a threat hunter in an enterprise environment for a long time, and I've never performed threat hunting like some of the examples above.

Most of my hunting work has involved reducing very large datasets until a small number of interesting observations remain. That frequently means looking for unusual behavior. Malicious activity usually affects a relatively small number of entities in an environment: a few users, endpoints, servers, applications, processes, or identities. That makes rarity useful. But rarity alone is not enough.

DeviceCount == 1 does not mean malicious.

Sometimes one system behaves differently because it is compromised. Sometimes it behaves differently because it is the server of the weird application a small department uses. That is why threat hunting cannot simply be reduced to finding outliers. 

There is also a useful distinction between an outlier and an anomaly.

  • An outlier is statistically uncommon or extreme.
  • An anomaly is an observation that is unusual in a way that becomes meaningful within its operational or security context.

A rare PowerShell command is an outlier.

A rare PowerShell command executed by a service account on a domain controller shortly after that account authenticated from a workstation it has never used before is something very different.

Context turns rarity into a hunting lead.

Threat hunters therefore need ways to reduce massive volumes of telemetry into a much smaller set of observations worth examining. Depending on the hunt, that may involve frequency analysis, clustering, baselining, peer-group analysis, time-series analysis, statistical methods, graph relationships, simple aggregations, or sometimes nothing more sophisticated than a carefully constructed query.
The technique matters less than the reduction process.

You might begin with 400 million events.

Your first query reduces them to 200,000.

Another aggregation reduces them to 3,000.

Entity context reduces them to 40.

Manual investigation leaves you with three.

And one of those three turns into an incident.

That is much closer to what threat hunting looks like in practice.

Once the dataset has been reduced, hunters usually need to validate what remains. That may include:

  • Searching for supporting or contradictory evidence across additional logs.
  • Correlating activity across endpoints, identities, network telemetry, cloud services, and other data sources.
  • Comparing the activity with historical behavior or peer groups.
  • Contacting the user or system owner to understand whether the behavior is legitimate.
  • Escalating suspicious activity to incident responders for deeper investigation.


And this is where human judgment becomes difficult to replace.

A query can tell you that something happened once.

Statistics can tell you that it is rare.

Threat intelligence can tell you that attackers have performed similar activity.

A detection rule can tell you that a known condition was satisfied.

The hunter still has to answer the harder question:

"Why is this happening here?"

That question is usually where the hunt actually starts.

Conclusion

Threat hunting should remain distinct from CTI research, alert investigation, and routine IOC searching.

The key question is simple:

What am I trying to find that my existing detections and security controls are missing?

If you cannot answer that clearly, you may still be doing useful security work.

But you are probably not threat hunting.
Share

Latest from our blog