Threat hunting is not alert triage by another name. The hunter starts from a hypothesis and tests it against the data; the SOC analyst reacts to an alert produced by a rule. Both roles are needed and they should be separated: if the hunter is covering alert backlog, they are not hunting.
What threat hunting is
Threat hunting is the proactive search for adversaries already inside the environment, without waiting for an alert to fire. It starts from a reasoned hypothesis (for example, «an attacker with initial access would persist via scheduled task» or «group X active in our sector exfiltrates over slow DNS») and tests it against the available telemetry: endpoints, identities, network, cloud, email. Hypotheses usually draw on TTPs from MITRE ATT&CK, on threat intelligence reports and on knowledge of the business itself. Unlike the traditional SOC, the hunter does not receive alerts: they build them. That is why hunting is the only function able to catch adversaries who have not yet made noise, and to generate new detections that later flow into the SIEM.
Why it matters
For an organisation running a SOC, the uncomfortable message is that most serious incidents in recent years were discovered by an external tip (a supplier, a customer, a researcher) and not by an internal alert. Dwell time has dropped, but it is still measured in weeks or months in public reports. Threat hunting addresses precisely that gap: the adversary who has already cleared preventive controls and has not yet triggered a SIEM rule. Each validated hypothesis leaves a permanent asset behind — a new detection rule or a refined use case — that improves SOC capability for the rest of the year. For regulated programmes (NIS2, DORA, ISO 27001) hunting provides evidence of active defensive capability, not only reactive capability, which auditors increasingly demand.
Key points
Hypotheses are built on three sources. Specific TTPs from MITRE ATT&CK relevant to the organisation's sector, threat intelligence reports on actors currently active against similar estates and knowledge of the environment itself (which identities are privileged, which assets would be extortion targets).
Hunting needs enough telemetry. EDR with process and command-line visibility, identity logs (Entra ID, on-prem AD), DNS, proxy, authentication into critical applications and, when applicable, cloud telemetry (CloudTrail, Azure Activity, GCP Audit). Without that foundation the hypotheses are theoretical exercises with no way to verify them.
Every hunt produces something. A new SIEM rule, a refined alert, an improved playbook, a hardening recommendation or, in the worst case, an open incident. A session that delivers none of those five outputs is a wasted session and the hypothesis or the data quality needs to be revisited.
Public frameworks help structure the work. SANS publishes a hunting maturity model and MITRE's own documentation includes techniques with detection examples. Leaning on these frameworks avoids reinventing the wheel and helps communication with auditors and internal stakeholders.
Threat hunting complements the managed SOC and incident response. The SOC monitors, the hunter hunts and response contains. In mid-sized organisations the three functions may share people, but the time dedicated to each must be explicit: if everything is response, there is no hunting.
Example: monthly persistence and C2 hunt in a company on Microsoft 365 with EDR
A company with an in-house SOC, EDR deployed across the estate and Microsoft 365 as its collaboration core schedules a monthly threat hunting cycle. The first cycle picks two concrete hypotheses. The first, based on common MITRE ATT&CK TTPs (T1053 Scheduled Task), looks for scheduled tasks created by non-administrative processes on workstations that do not belong to IT. The second, based on recent reports affecting the sector, hunts for signs of C2 over slow DNS and outbound communications to paste sites from Office processes.
The team queries EDR telemetry, DNS logs and task-creation records covering the last ninety days. The first hypothesis yields no relevant findings, but reveals that DNS queries are not fully reaching the SIEM from two small offices; that result, though not an incident, feeds a coverage improvement. The second hypothesis surfaces a beaconing pattern over DNS on a workstation in finance. An indicator of compromise is raised and, after cold forensic analysis, an implant with active C2 connectivity is confirmed, with no visible follow-on action yet. Incident response isolates the endpoint, captures memory, looks for lateral movement and persistence on adjacent assets and closes the loop. The hunt produces three outputs: the contained incident, a new SIEM rule to spot the beaconing pattern in the future and a documented coverage gap on the two offices.
Common mistakes
- Mistaking hunting for writing more SIEM rules. Rules are written by anyone with detection knowledge; hunting starts from a hypothesis and tests against data. The output may be a rule, but the exercise is not «write rules without context».
- Launching hunts without enough telemetry. If EDR does not capture command lines, identity logs are not in the SIEM or internal DNS is not stored, hypotheses become theoretical. Data first, hunting second.
- Hunting only when spare time appears. Without a cadence (monthly or fortnightly depending on maturity) and without coverage targets per ATT&CK category, the programme evaporates as soon as alert load rises.
- Not documenting the result. A session without a recorded hypothesis, data sources consulted and a concrete output (rule, improvement, incident) is neither auditable nor reproducible. Recording is half the value of hunting.
- Assuming that bought-in threat intelligence is hunting. Intelligence is an input; without hunters translating it into hypotheses on the local environment, the monthly reports pile up without ever turning into detection.
Related services
This concept may be related to services such as:
Frequently asked questions
How is threat hunting different from a traditional SOC?
A traditional SOC reacts to alerts generated by predefined rules. Threat hunting starts from reasoned hypotheses and actively looks for malicious activity that has not yet triggered any rule. The SOC detects the known; the hunter chases the unknown. Both functions are needed and they should be separated so neither cannibalises the other's time.
What data do you need to start hunting?
The minimum baseline is EDR with process and command-line visibility, identity logs (Entra ID or Active Directory), DNS logs, proxy or browsing logs and authentication records into critical applications. If the organisation lives in the cloud you also need CloudTrail, Azure Activity or GCP Audit. Without that baseline hypotheses cannot be verified.
How often should threat hunting run?
It depends on maturity. Early programmes start with one session a month around one or two hypotheses. Mature programmes run continuous hunting distributed across MITRE ATT&CK categories with measurable coverage. What matters is cadence: without regular frequency the programme evaporates as soon as SOC load rises.
Do you need threat intelligence to hunt?
It helps a great deal, but it is not strictly mandatory. You can start with public ATT&CK TTPs and knowledge of the environment. Threat intelligence raises hypothesis quality because it lets you prioritise the actors and techniques currently active against similar estates at the time of the hunt.
Can threat hunting be outsourced?
Yes. A managed threat hunting service provides continuous capacity without needing to maintain the role in-house. The condition is that the service has access to enough telemetry and delivers concrete outputs (new rules, coverage improvements, hypotheses executed with results) rather than generic monthly reports.