Threat hunting is the deliberate search for an attacker who is already inside and has not triggered any alarm. It starts from an uncomfortable assumption: that the tools did not detect them, that the logs did not flag them, and that if no one goes looking, no one will find them.
It is not a tool you buy or a feature you turn on. It is work that someone does, with a hypothesis, some data and a few hours ahead of them.
How is it different from waiting for an alert?
In who starts the conversation.
The normal model of an operations center is reactive by design: an alert arrives, someone analyzes it, decides whether it is real and acts. It works well, and it is where the vast majority of day-to-day work gets resolved.
But that model has a limit worth understanding without drama: can only alert on what someone programmed it to alert on. Every alert exists because a human, at some point, described a pattern and said it deserved attention. What no one described generates nothing. It is not a flaw in the tool, it is its nature.
Hunting reverses the order. It does not wait for something to go off. Someone sits down with a specific suspicion and goes to check it in the data.
Why is it needed if I already have SIEM and EDR?
Because the SIEM and the EDR are excellent at what is known and blind to what has not been modeled. And there are three fairly common situations where that leaves a gap.
When the attacker uses legitimate tools. An intruder who moves using the administration utilities that already come with the system installs nothing unusual, runs nothing unknown and triggers almost nothing. Everything they do is allowed. The problem is not each action on its own, it is the sequence.
When what gets in is valid. A stolen credential or a hijacked session does not produce a failed login attempt. It produces a successful login. There is nothing to block.
When the rule exists but the coverage does not. This is the most common and the most uncomfortable: the detection is well written, but the server where it happened does not send that type of log. The rule did not fail, it never got to run.
What does a real hunt look like?
It always starts with a hypothesis, not with a tool. A hypothesis is a statement that can be confirmed or ruled out with data. For example, this one:
“If someone stole an administrator's credentials, I should see privileged account sessions outside normal hours and from devices that person never uses.”
From there the work is orderly and fairly boring, which is exactly what it should be:
- Decide what data would answer that question: authentication logs, device inventory, each person's actual working hours.
- Establish what is normal before looking for what is abnormal. Without that baseline there is nothing to compare against and everything looks suspicious.
- Look for deviations and review them one by one, knowing in advance that most of them will have an explanation.
- Document the result, even when the result is that there was nothing.
- Turn what you learned into an automated detection, so you don't have to hunt for the same thing again next month.
That last step is what separates a useful hunt from a moment of curiosity. Every hypothesis tested should leave behind a new rule or a data source that was not arriving before.
To prioritize which hypotheses are worth pursuing, almost the entire industry uses the MITRE ATT&CK catalog, which compiles the documented techniques used by real attackers. It lets you turn the question around: of all those techniques, which ones would you detect today and which ones would you not?
Which hypothesis is worth pursuing first?
This is the hardest question to answer when you are starting out, so here are four that work in almost any mid-size company and require no special tools. Each one is framed so it can be ruled out with data.
Privileged accounts outside their pattern. If someone stole administrator credentials, there should be sessions from those accounts at times or from devices that do not match the person. It is the most cost-effective place to start because privileged accounts are few and the data volume is manageable.
Administration tools used where they don't belong. The utilities that come with the operating system are legitimate in the hands of the IT team and highly suspicious on an accounting workstation. Searching for executions of those tools outside the area that should be using them finds things with uncomfortable frequency.
Data outflows that don't fit. Volumes of information leaving toward destinations the company does not work with, or at hours when nothing should be leaving. You don't need to know what it contains: it is enough that the pattern has no explanation.
Service accounts behaving like people. An automated identity that suddenly accesses new systems, or changes its pace, or authenticates from a different location. Almost no one monitors them, precisely because they are automated and it is assumed they always do the same thing.
All four have something in common, and it is worth noticing: none of them looks for malware. They look for behavior that does not fit. A competent attacker avoids malware precisely because they know that does get detected. What they cannot avoid is behaving differently from the person they claim to be. CISA advisories are a good source for choosing the hypothesis of the month, because they describe what is being used right now against real companies.
What do you need to be able to do it?
Four things, and the last one is the one that is almost always missing.
- Sufficient telemetry. You cannot hunt in data that does not exist. If critical servers do not send process and authentication logs, no hunting is possible, no matter how much talent there is.
- Retention. An attacker can be inside for months. If only seven days of logs are kept, the hunt begins and ends within that week.
- Knowledge of the environment. Knowing what is unusual in this specific company. A process running at three in the morning can be an intruder, or it can be the monthly accounting close.
- Protected time. Hours from someone that are not taken up handling the alert queue. This is the first one to go: when there is pressure, hunting is what gets postponed, because no one is asking for it.
How often is it done?
What is reasonable in a mid-size company is one formal hunt a month, of between four and eight hours, on a carefully chosen hypothesis. You don't need more to start getting value, and it is a commitment that can be sustained.
What does not work is improvised hunting, the “when we have some time” kind. That time never comes, because there is always something more urgent with someone behind it asking for it.
It is also worth launching an ad hoc hunt when a new threat relevant to your industry appears, to check whether that specific technique would have gone unnoticed in your environment.
What if it finds nothing?
It is the most common result, and many people interpret it as wasted time. It is exactly the opposite.
A hunt that finds no intruders almost always finds other things, and all of them are worth money:
- Devices that were not sending logs and no one knew.
- Detections that were misconfigured and would never have fired.
- Accounts with permissions that no longer belong to anyone.
- A documented baseline of what is normal, which makes the next real investigation faster.
And it produces something harder to measure but just as real: the difference between believing no one is inside and having verified it. They are not the same, even if the report looks similar.
That, by the way, is the underlying difficulty of all prevention, and we have covered it separately in the article on how to measure what never happened.
Frequently asked questions
Can threat hunting be automated?
Do you need a dedicated team?
How is it different from a pentest?
What is dwell time?
Can an external provider do it?
Searching instead of waiting
The difference between an operations center that only reacts and one that also hunts is not noticeable on the day the alarm goes off. It shows on the day it does not go off and it turns out something was there.
No one can guarantee that there is no one inside your network. What you can do is go look, put it in writing and do it again next month.
