What threat hunting is
Detection rules wait for something to match. Threat hunting goes looking. A hunter starts from the assumption that something may already be in the environment that no rule has flagged, and searches stored data to find out.
Hunting without a plan tends to turn into scrolling through logs. Hypothesis-driven hunting gives each search a purpose: a specific idea about attacker behaviour, stated so that it can be proved or disproved with the data you have.
A good hunt ends in one of three ways. You find activity worth investigating. You find nothing, and you now have evidence the behaviour was absent for the period you searched. Or you find that the data is not good enough to say, which is a finding in its own right.
Writing a good hypothesis
A hypothesis is a short statement of what an attacker might be doing, where, and how it would show up in your data. It should be narrow enough to test and broad enough to matter.
Compare “attackers might be on our network” with “an attacker with a foothold on a Linux server would add a cron entry or a systemd service to survive a restart, and the file change would appear in our endpoint logs”. The first cannot be tested. The second names a behaviour, a place and a data source, and a search follows from it almost directly.
Hypotheses can come from many places: published reports of attacker techniques, findings from your own past investigations, a gap in your detection coverage, or a change in the business, such as a new remote access service or a newly acquired company joining the network.
- The behaviour, ideally tied to an ATT&CK technique
- Where it would happen: which machines or accounts
- What evidence it would leave, and in which logs
- What ordinary activity looks similar, and how to tell the two apart
Example hypotheses
These are generic starting points, each tied to a well-known attacker technique. Every one should be adapted to your environment, your important systems and the data you collect.
Notice that each one names the evidence, not only the threat. That is what makes it something you can run rather than something you worry about.
- New scheduled tasks or cron entries created outside change windows point to persistence.
- Office applications starting command shells or script interpreters point to a malicious document.
- Processes with no business reason connecting out on a regular interval point to beaconing.
- Accounts signing in to many machines in a short time, outside their usual pattern, point to lateral movement.
- Large archives created in user or temporary folders shortly before outbound transfers point to data being staged.
- Security tools or logging services being switched off on a machine point to an attempt to hide.
The data each hunt needs
A hunt is only as good as the data behind it. Before running one, check that the logs it depends on are arriving, from the machines it cares about, for the whole period it covers. A beaconing hunt needs network or process connection data. A persistence hunt needs file and process events from endpoints. A sign-in hunt needs authentication logs from your identity provider and your servers.
If the data is missing, the hunt cannot find anything, and an empty result will look reassuring when it should not. Record the data each hunt needs alongside the hunt itself, and check it before trusting a clean result.
The same check tells you which hunts you cannot run yet. A list of hunts waiting on data is a useful input to collection planning: it shows, in attacker terms, what each new log source would let you look for.
- Credential access9 huntsReady
- Persistence12 huntsReady
- Discovery8 huntsReady
- Lateral movement7 huntsNeeds Windows logon events
- Command and control6 huntsNeeds DNS logs
- Exfiltration5 huntsReady
Running hunts on a schedule
Many hunts are worth running more than once. A hunt for regular beaconing, run weekly, catches new footholds as they appear. Scheduling turns a one-off search into a standing check, without the noise of a detection rule that fires in real time.
Group hunts by technique so that coverage is easy to see: a pack of persistence hunts, a pack for credential access, a pack for data staging. When a new technique is reported, you can see straight away whether you already hunt for it.
Keep the results of each run. Comparing this week’s results with last week’s is often where the signal is: a new machine in the list, a new account, a new destination.
Write down who reads each scheduled hunt’s results, and by when. A hunt that runs on time and is read late is not much better than one that never runs.
Reading the results
Hunt results are rarely a clean yes or no. Most rows will be ordinary activity that happens to look like the behaviour you were hunting. The work is separating the two: checking each hit against what the machine is for, who the account belongs to and whether the activity has an obvious business reason.
Business context speeds this up. If you know which machines run payroll, which accounts belong to administrators and which servers are meant to talk to the internet, many hits can be explained in seconds, and the ones that cannot stand out.
When a hunt keeps finding the same harmless activity, record why it is harmless and tune the hunt. When it finds something real, open an investigation. And when a hunt reliably finds real activity with little noise, consider turning it into a detection rule.
armor360 keeps a library of hunts grouped into packs by attacker technique. Each hunt says what data it needs and can be run now or on a schedule. The agent reads the results and says whether they look like an attack, and a person decides what happens next.