Threat hunting priorities

Choosing capabilities to use, assets to cover, and threats to target.


Threat hunting can speed detection and reduce the cost of a breach, as well as reduce the chance of future compromise. Hunting isn’t free, though: it takes time, tools, and trained staff. To maximize the return, hunters need to prioritize three sets: 1) capabilities (people, tools, and info used), 2) assets (systems, services, data, users, and accounts covered), and 3) threats (actors, tactics, and techniques targeted).

This approach helps you prioritize and integrate these for the most hunting impact, and it can be extended to other infosec activities.


Infosec activities are financially rational to the extent they reduce risk, either by reducing the chance something bad happens, the negative consequences when it does, or both. Proactive threat hunting (a.k.a., compromise assessment) is popular, in part, because it can help on both fronts: earlier threat detection saves money,1 and finding and fixing weaknesses used by attackers reduces the chance of future compromise.

Hunting isn’t free, though; it takes time, tools, and trained staff. To maximize the return on these investments, organizations can optimize their hunt process by prioritizing in three main areas:

  1. Capabilities. The people, tools, and information used.
  2. Assets. The systems, services, data, users, and accounts covered.
  3. Threats. The actors, tactics, and techniques targeted.

Resources like sqrrl’s Hunt Evil: Your Practical Guide to Threat Hunting and Dan Gunter’s “A Practical Model for Conducting Cyber Threat Hunting” get into more detail on the hunt process, but they’re a bit thin on deciding which capabilities to use, assets to cover, and threats to target. This article is a companion to those, as well as to your own procedures, to make those decisions more effectively.

Note: This approach is extensible and supports most infosec activities across the CSF! To keep it manageable we focus on hunting here, but it’s broadly applicable.

General Notes on Prioritizing

Teams struggle to set clear priorities. We find the following tips helpful:

  1. Use a second axis. Priorities are multivariate, they don’t fall cleanly on a linear spectrum. All the examples here use two axes, to balance between simplicity and expressiveness.
  2. Start with binary, relative distinctions: “is x more or less than y (on this axis)?” Absolutism and granularity lead to bike-shedding, bike-shedding leads to suffering.
  3. Normalize. If you find your options clustered together (e.g., “high” on both scales), try re-orienting on the center of mass or following these other suggestions.
  4. Collaborate. Whenever things are assessed as “better” or “worse,” feelings become involved. Collaborate during this exercise to build trust and avoid misunderstandings, and remember this is solely in the context of threat hunting (not a global value judgment).

Doing nothing is a choice, a vote for the default, increasing risk of common cognitive biases like the availability heuristic (“let’s hunt for Emotet because I just read an article about it”), authority bias (“let’s hunt for Emotet because the CIO just read an article about it”), the bandwagon effect (“let’s use this tool because everyone at RSA said it was 🔥”), and so many more there should be an article on this alone.

The goal isn’t perfection, just reasonable examination. You can always reconsider, this is iterative!


What information, tools, and trained staff should we use?

Prioritize capabilities based on cost (time, effort, direct expense) and quality (usefulness, coverage, clarity, accuracy).

Lower Cost Higher Cost
Higher Quality 1st 2nd
Lower Quality 3rd 4th

We prioritize higher quality capabilities even when they’re higher cost, to reduce false positives and false negatives. Errors are costly, we find a little extra up-front effort hedges against them, but reasonable people prioritize the other direction.

To start your conversation, here are just some of the capabilities we’ve seen used to successfully hunt for high-impact threats:

Information (Data) Tools Teams
Process telemetry EDR/IDR Hunt team
Network telemetry NDR IR
Microsoft 365 logs SIEM 3rd party
Autoruns/ASEPs Aggregator SOC
System, IaaS, and access logs DFIR/hunt platforms MSP
App, web, and DB logs Scripts IT
NGFW and DNS logs Database Compliance
Email Search (e.g., yara) Developers
Endpoint protection logs Endpoint management DevOps
Capabilities example
Capabilities Example

Take a broad view of cost and quality. Time is sometimes the biggest factor, it represents a opportunity cost tradeoff; these are talented, well-trained folks who could be doing something else to reduce risk.

Projects like the MITRE ATT&CK CARET tool show certain events (e.g., process creation) and certain sensors (e.g., Sysmon) help detect a disproportionate percentage of attacker techniques. This ratio, percentage of relevant attacker activity detectable using a capability, is a solid proxy for relative quality.


Good news! Doing this once can last a long while, just update it when capabilities change. We go through this exercise when using our customers' organic capabilities alongside those we bring to the party. You may also want to update it more frequently if there is no good global ordering (e.g., developers might be higher priority to hunt in app logs).


What systems, services, data, users, and accounts should we cover?

Prioritize assets based on importance (criticality) and vulnerability (exposure, weakness).

More Important Less Important
More Vulnerable 1st 2nd
Less Vulnerable 3rd 4th

We wrote a whole post on asset importance, and vulnerability analysis is well-covered ground. Be sure to consider architectural vulnerability and threat modeling in addition to lists of CVEs. Thoughtful selection of covered assets (a.k.a., “terrain”) directly improves a hunt’s risk reduction, and a good global, prioritized list can support many infosec and compliance activities. Save this list.

A few general tips:

  1. Round up across asset types. If important data is on a system, the system is important. Think payroll or finance workstations.
  2. Round up across dependencies (within reason). If an important system depends entirely a server, treat the server as important. Think DNS or NTP.
  3. Round up across adjacency (within reason). If a vulnerable system is used to access a network, treat the network as vulnerable. Think ICS/SCADA jump boxes with internet-accessible, single-factor RDP.
  4. Use a consistent framework. Using MITRE ATT&CK, perhaps via MITRE ATT&CK Navigator, can help match asset vulnerability with threat techniques (below).

For the corner cases, we prioritize more vulnerable assets because, outside obvious cases like domain controllers, it’s usually easier for an attacker to assess vulnerability over importance. Your mileage may vary.

Use a broad definition of “assets." Systems, services, data, users, and accounts are a good start, but customize this for your organization. Don’t find yourself on the back end of an incident because you didn’t treat a critical resource as “in-scope.”

By default, the choice is “whatever assets are covered by our capabilities.” If important, vulnerable assets are outside their coverage you end up with the streetlight effect: you’re only hunting where the light happens to shine. This exercise helps identify weaknesses and reduce risk even before the first hunt by ensuring your tools and data collection covers your highest priority assets.


What actors, tactics, and techniques should we target?

Prioritize threats based on impact (danger, frequency) and vulnerability (by technique).

Higher Impact Lower Impact
More Vulnerable 1st 2nd
Less Vulnerable 3rd 4th

Like most of the infosec industry we’re fans of MITRE ATT&CK as the de facto vocabulary for discussing attacker activity. We recommend it.

When prioritizing corner cases, we focus on techniques to which we’re more vulnerable, for the same rationale noted above. And since activity will be part of an attack chain, we can often trace it from lower-impact TTPs to more dangerous stuff. It’s easier to unravel the plot when you have a thread to pull.

There are a lot of great, free resources describing the threat landscape: who is targeting whom, and how, including on the MITRE ATT&CK Groups page and in products like the Verizon DBIR, plus you might have a servicing ISAC or commercial intel.

If you are, for example, in pharmaceuticals or biotechnology adjacent to COVID: US, UK, and other governments have been warning of Russian government groups targeting your world. Media articles about this are quite detailed, and ATT&CK has you covered too, so even without bespoke intelligence you can build a usable list of tools, tactics, and techniques to prioritize:

APT29 ATT&CK Navigator Snippet
APT29 ATT&CK Navigator Snippet

If you don’t have any specific information on threats to your organization or industry, start with common, general threats. Even a weak sort rationale is better than going alphabetically.

Finally, don’t neglect the base rate: if 80%+ of application hacking involves web apps and brute force or the use of lost or stolen credentials,2 it’s a decent bet you’ll find something in your web app authentication logs before seeing an exotic 0-day. You don’t need an intel report to know that phishing is common and often successful. Put another way: unless you know different, you’re probably not that different.

Intersections and Implications

With these prioritized sets in hand, think about how they interact and intersect. You won’t have perfect overlap, but rather something like this teddy bear venn diagram:

Threat Hunt Venn Diagram
Threat Hunt Priorities Venn Diagram

The bubbles represent the priority items in each set, above some threshold of viability or interest. Of course, this is an intuition pump to prompt critical thinking, not a scientific accounting. Each region has interesting characteristics and a loose-fitting, battle-inspired label:3

In the Hunt

  • Set 1, The Front: the sweet spot, where priority capabilities, assets, and threats are aligned. Start here.
  • Set 2, The Rear: where viable capabilities cover priority assets, without specific threats. Hunt here next, looking for common base-rate threats just in case, as discussed above.
  • Set 3, Skirmish: where viable capabilities target specific threats, but not to priority assets. Save this for last, to mitigate lateral movement risk.

Out of the Hunt

  • Set A, The Reserves: where viable capabilities neither cover priority assets nor address priority threats. Think of that Palo Alto NGFW appliance still in the box or not feeding into the SIEM, or that unused services retainer with your MSP. Many organizations have dead weight and waste, hence the size of this bubble. Eliminate or re-purpose this capacity.
  • Set B, The Flank: where priority assets have no relevant hunt capabilities, but are not (yet) under threat. Perhaps they’re in controlled enclave or managed by a third party. This is an opportunity to expand capabilities or harden assets (or remove them!). It’s tough to know if assets are here or in set D (“Breakthrough”).
  • Set C, The Wire: where we have threats not covered by hunt capabilities, but not (yet) on priority assets. This includes attacks currently stopped by protective controls. Be cautious: one mis-configuration can accidentally open the gates.
  • Set D, Breakthrough: where threats are targeting priority assets, but you have no hunt visibility. Ignorance is not bliss, this is the highest risk area. This is when you see your organization or industry in an intel bulletin, or worse, a breach notification, and you know you’re blind to the activity it describes. Like set B (“The Flank”), reduce this by expanding capabilities, or hardening/removing assets. Shown here asymmetrically small as an aspiration. 😃

For an alternative approach, start with these descriptions and work backwards to your separate sets.

Case Study

… forthcoming, as this post is already pretty long!


Infosec threat hunting requires us to prioritize the capabilities to use, assets to cover, and threats to target. We hope these methods have given you some better ways to think about that, as well as some of the interactions and implications of those sets. Try them, iterate, and you’ll learn what works best for your organization. Let us know if you use a different system that works for you!

We can help with hunting, forensics, incident response, and many other things infosec – please contact us if you need a hand. Good hunting!

  1. ↩︎

  2. 2020 Verizon Data Breach report, p. 19 ↩︎

  3. Sorry to mix metaphors! Also, we’re not advocates of the militarization of infosec terminology, but this seemed more useful than leaving them as “set 1” or “set C.” Naming things is hard, open to better ideas! ↩︎