What are the three types of threat hunting?
Threat hunting usually breaks into three types, and most mature teams run all three depending on what triggered the hunt. Structured hunting is hypothesis-driven and planned around attacker behavior, for example "if an adversary is doing credential dumping in this environment, I'd expect to see LSASS access from an unusual process," mapped to a MITRE ATT&CK technique. Unstructured hunting is triggered by an indicator or an anomaly you stumbled onto, such as a single odd domain in DNS logs that you decide to pull the thread on. Situational or entity-driven hunting centers on a specific asset, user, or crown-jewel system, for instance "hunt everything touching the finance file server over the last ninety days," usually because that entity matters more than the rest of the estate.
The three are not really competitors, they overlap constantly. A structured hunt often surfaces an anomaly that kicks off an unstructured one, and both frequently narrow down to a single entity worth a deeper look.
What's the difference between structured and unstructured threat hunting?
Structured hunting starts from a hypothesis. Unstructured hunting starts from a clue. That is really the whole distinction, but it matters in practice.
A structured hunt is planned around attacker behavior, usually anchored to a MITRE ATT&CK technique. You decide up front what you're testing for, such as lateral movement over SMB, and you go looking for evidence that confirms or refutes it. An unstructured hunt is exploratory, it typically kicks off when an indicator of compromise (IOC) or an odd anomaly shows up in the data and you follow it without a formal hypothesis written down first.
Structured wins when you want repeatable coverage you can measure against a framework and report on. Unstructured wins when your telemetry or threat intel surfaces something weird and waiting for a formal hunt plan would waste the lead. Most teams need both.
What are common threat hunting techniques?
Four techniques come up in almost every hunt, and they layer on top of each other. Stack counting, sometimes called frequency analysis, aggregates a field and looks at the rare tail. Count every parent process that spawned PowerShell across ten thousand endpoints, and the three hosts where that count is one are often the interesting ones. Grouping takes a set of events that share a specific attribute and looks at them together, such as pulling every authentication event tied to one service account inside a two-hour window. Clustering is the machine-learning cousin of grouping, it lets the data form its own buckets: group logins by time, geography, and device and see which cluster does not fit the others. Searching is the simplest, you already have a concrete indicator such as a hash or a domain and you query directly for it.
In practice you rarely run just one. A hunt often opens with stack counting to find the statistical outliers, then groups the events around a suspicious entity, then searches for the specific artifacts that confirm intent.
What's the difference between IOCs and IOAs?
An indicator of compromise (IOC) is evidence of something that already happened. An indicator of attack (IOA) is the behavior of something happening right now. That timing difference is the whole point, and it changes what you can catch.
An IOC is a forensic artifact left behind, such as a file hash, a malicious IP address, or a command-and-control domain. It tells you a specific known-bad thing was present. The problem is that attackers rotate this infrastructure constantly, so an IOC often goes stale within weeks. An IOA describes intent and technique, the pattern of an adversary doing something, such as a process injecting into another process and then reaching out to the network, regardless of which specific file or IP is involved.
Here is the practical contrast:
| Dimension | IOC | IOA |
|---|---|---|
| What it captures | An artifact from a past event (hash, IP, domain) | A behavior in progress (technique, intent) |
| Shelf life | Short, attackers rotate infrastructure | Long, techniques are harder to change |
| Best for | Fast matching against known-bad | Catching new or unseen campaigns |
Good hunting pivots off stale IOCs toward the behavior underneath. If you only sweep for known artifacts, the low-and-slow adversary who changed their infrastructure last week walks right past you.
What are IOCs, IOAs, and TTPs in threat hunting?
These three terms describe the same attacker at increasing levels of durability, and threat hunting generally works best when you climb from the bottom toward the top. An indicator of compromise (IOC) is a concrete forensic artifact, such as a file hash, an IP address, or a domain, cheap to detect but cheap for the attacker to change. An indicator of attack (IOA) is a behavior that signals intent, such as a suspicious parent-child process chain, which describes what the adversary is doing rather than which file they used. TTPs, tactics, techniques, and procedures, are the highest level, they describe how an adversary operates as a matter of habit, such as "uses valid accounts for lateral movement and living-off-the-land binaries for execution."
David Bianco's Pyramid of Pain maps these directly. Hashes and IPs sit at the bottom because an attacker swaps them out in minutes. TTPs sit at the top because changing them means changing how the whole crew operates, which is genuinely hard and expensive for them. TTPs are the most durable of the three, so a hunt built around TTPs keeps catching the same actor even after they burn their infrastructure. That durability is why hunting behavior beats hunting artifacts.
What is the Pyramid of Pain in threat hunting?
The Pyramid of Pain is a model David Bianco published in 2013 that ranks indicators by how much pain it causes an attacker when you detect and block them. It has become one of the standard mental models threat hunters use to decide what is actually worth hunting for.
At the bottom sit hash values, then IP addresses, then domain names. These are trivial for an adversary to change. A new hash is one recompile away, a new IP is one hosting account away, so detecting them causes the attacker almost no pain. In the middle sit network and host artifacts, then tools, which cost the attacker more to swap. At the very top sit TTPs, the tactics, techniques, and procedures that describe how the adversary actually operates. Forcing an attacker to change their TTPs is genuinely painful, because it means retraining, retooling, and rethinking their entire approach.
The lesson hunters take from the pyramid is to hunt as high up as they can. Hunting a hash catches one sample. Hunting a technique, such as credential dumping from LSASS or lateral movement over remote services, catches the actor no matter how many hashes and IPs they rotate through. Every rung you climb costs the adversary more, and that cost is the whole game.
How do you use MITRE ATT&CK for threat hunting?
MITRE ATT&CK is used two ways in hunting: as a menu to build hypotheses from, and as a map to find your coverage gaps. It is a knowledge base of real-world adversary tactics and techniques, things such as T1003 credential dumping or T1021 remote services, organized by the stages of an attack.
As a hypothesis menu, you scan the techniques relevant to your threat model and turn each into a testable question. "Do we see any evidence of T1021.001 remote desktop lateral movement in the last sixty days?" is a structured hunt straight off the matrix. As a coverage map, you lay your existing detections over the framework and the blank cells show you where an attacker could operate without tripping an alert. Those blanks are your best hunting ground, because that is where SOC rules are not watching.
Simbian maps every finding to MITRE ATT&CK, and that matters more than it sounds. ATT&CK is the shared coordinate system across all of Simbian's agents, so a technique the AI Threat Hunt Agent confirms in your logs lines up with what the AI SOC Agent sees in the alert queue. Every completed hunt renders a full kill-chain view, initial access through impact, with the entities attributed to each tactic, so you are reading findings in the same language your detection stack already speaks.
Why hunt for TTPs instead of IOCs?
Because IOCs go stale and TTPs don't. An indicator of compromise, such as a hash or a command-and-control IP, often has a useful shelf life measured in weeks. Attackers rotate infrastructure as a routine part of operations, so the domain you block today is dead to them tomorrow anyway. Hunting IOCs keeps you one step behind by design.
TTPs, the tactics, techniques, and procedures behind the artifacts, are durable because they reflect how an adversary actually works. A crew that favors living-off-the-land execution and pass-the-hash for lateral movement tends to keep doing that across campaigns, even after they burn every hash and IP you caught them with. Hunt the behavior and you keep catching the actor.
This matters most against low-and-slow adversaries. They deliberately move slowly enough to stay under alert thresholds, and they change infrastructure often enough to evade IOC sweeps, but they still have to execute techniques that leave a behavioral trace in your historical data, if someone looks.
What is identity threat hunting (ITDR)?
Identity threat hunting is hunting for identity-based attacks: credential abuse, token theft, anomalous authentication, privilege escalation, and MFA fatigue attacks where an attacker spams push prompts until a tired user approves one. ITDR (Identity Threat Detection and Response) is the broader category this sits inside. The premise is straightforward, identity is the new perimeter. SANS noted in 2025 that identity has become a primary attack surface, and once an adversary has valid credentials, most of their activity looks exactly like a normal user until you hunt for the seams.
This is entity-driven hunting, and it runs across your identity provider and authentication logs, the sign-in data, the token issuance records, the privilege-grant events. You are looking for the login that comes from an impossible location, the service account that suddenly authenticates interactively, the account that escalates its own permissions, or the burst of failed MFA prompts followed by one success at 3 a.m.
The reason identity hunts are hard by hand is that the signal lives in high-volume, mostly-benign auth data, and the malicious login is one row among millions.
What is living-off-the-land (LOTL), and how do you hunt for it?
Living-off-the-land is when an attacker uses the legitimate tools already installed on your systems, PowerShell, WMI, certutil, PsExec, instead of dropping their own malware. There is no malicious file to block and no signature to match, because every binary they touch is one your operating system shipped with and your admins use daily. That is exactly why it works, and why hunting is often the only way to catch it.
Since there is no IOC to sweep for, you hunt the behavior instead. The tells live in how these tools get used, not whether they run. Anomalous parent-child process chains are the classic starting point. Microsoft Word spawning PowerShell is not something a normal document does. Unusual command lines are another, such as certutil being used to download a file from the internet, which is a legitimate feature almost nobody invokes on purpose. Encoded PowerShell commands, WMI used for remote execution, and PsExec creating services on hosts that never see it are all worth a hard look.
This matters more every year. SANS flagged in 2025 that nation-state actors lean heavily on LOTL specifically to evade detection.
What is lateral movement, and how do you hunt for it?
Lateral movement is what an attacker does after initial access, moving host-to-host through your network to reach the systems that actually matter, using techniques such as pass-the-hash, RDP chains, remote service creation, and anomalous internal authentication. The hard part is that most of these techniques ride on legitimate administrative mechanisms. Admins use RDP, create remote services, and authenticate across hosts all day, so the malicious version and the benign version look nearly identical in the logs.
That similarity is exactly why lateral movement is a strong place to show the elimination game. When the threat hunter finds a candidate, say a service account authenticating to five servers it has never touched before, then creating a remote service on each, it does not just flag it and move on. Before it issues a verdict, the hunter actively tests the benign explanation: is this a patch-management run, a legitimate admin doing maintenance, a backup job that happens to fan out this way? Our threat hunt engineers describe it as an elimination game. On first glance it looks like a threat, but you go deeper on the alternatives until either they all fail or one holds up.
Every hunt report shows the benign explanations the agent tested and rejected, not just the conclusion. So when the verdict comes back Confirmed Threat, you can see the admin activity it ruled out to get there, and if it comes back Benign, you can see why.
