What Is Threat Hunting: Methodology and Tools

Threat hunting is a proactive defensive practice in which an analyst searches for evidence of malicious activity that automated detection tools have not alerted on. The difference with the standard operation of a SOC is the direction of the work: the SOC reacts to alerts that already fired, the threat hunter starts from a hypothesis (an attacker using a certain TTP would be in my environment) and actively looks for evidence in logs, EDR telemetry, identity and network. The starting assumption is realistic: if no alert fired it does not mean the attacker is not there.

This guide explains what threat hunting is, how it differs from reactive detection, the three most used methodologies, the role of MITRE ATT&CK, which tools are needed and how it fits a mature defensive programme.

What threat hunting is

Threat hunting is the activity of manually searching for malicious activity that has evaded automated controls. The operational definition any serious team accepts:

• It is proactive, not reactive. The analyst does not wait for the alert; they go find it.
• It is hypothesis-based. Every hunt starts with a concrete premise (an attacker doing kerberoasting would be in this domain, an infostealer would be exfiltrating data over DNS, an attacker with persistence via scheduled tasks would show up in these logs).
• It is iterative. Every hunt confirms or discards the hypothesis and produces new detection rules, new hypotheses or the start of a formal incident.
• It is investigative, not automatic. The threat hunter uses tools (SIEM, EDR, sysmon) but provides the brain. The tools deliver visibility; the hypothesis and the decision come from the human.

Threat hunting does not replace automated detection. It complements it by covering the space between what rules know to look for and what a skilled attacker knows to hide.

Threat hunting vs reactive detection

The two disciplines coexist in a mature defensive programme:

• Reactive detection (SIEM, EDR, IDS): rules and models that fire alerts when a known pattern appears. Operated by the SOC in 24/7 shifts. Indispensable, but limited to what you already know to search for.
• Threat hunting: active investigation on data from the last days, weeks or months to detect what did not trigger an alert. Usually run by senior analysts outside shifts in planned hunts (typically 1-3 hunts per week in established programmes).

The critical assumption of hunting is that the skilled attacker knows how to stay below the threshold of the rules: they do not use visible Mimikatz, they do not call net group "Domain Admins", they do not connect directly with PsExec. They use Living Off the Land, abuse legitimate processes, take long pauses between actions. SIEM rules do not see them; a human who knows their TTPs does.

The three threat hunting methodologies

Any professional hunting programme combines the three in varying proportions.

1. Hypothesis-driven

The most used methodology. The analyst starts from a concrete hypothesis based on recent threat intelligence, on a MITRE ATT&CK TTP or on an external incident in the sector.

Operational example. After the publication of an advisory on PetitPotam (NTLM relay against ADCS), the analyst proposes the hypothesis: if an attacker tried to exploit it in my environment, I would see in Active Directory logs authentications from the domain controller machine account against the ADCS server from unexpected internal IPs. They run the query and look for evidence.

2. IoC-driven

Starts from a concrete indicator: an IP, a hash, a domain, a registry key published in a recent threat intelligence report.

Example. CISA publishes an advisory with 30 indicators associated with Akira ransomware. The analyst searches for those indicators in EDR, SIEM, DNS, proxy and firewall over a 90-day window. The fastest modality and the minimum baseline of any programme.

Limitation: IoCs decay fast. A C2 IP changes within hours; a hash, within days. IoC-driven hunting covers recent incidents; it does not detect attackers who rotate infrastructure.

3. TTP-driven

The most mature. Instead of looking for indicators, it looks for behaviours. MITRE ATT&CK techniques are the reference catalogue.

Example. Technique T1078.002 (Valid Accounts: Domain Accounts) is heavily used by ransomware. The analyst builds a recurring hunt that detects successful authentications of privileged accounts from new workstations, from unusual IPs or outside business hours. A hunt that covers multiple groups and remains useful even when specific IoCs change.

TTP-driven hunts require the highest initial effort and have the longest useful life. A well-built hunt runs for years with minor adjustments.

MITRE ATT&CK: the common language

MITRE ATT&CK is the reference matrix for describing attacker behaviour. It is organised into:

• Tactics: the "why" of the phase. Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Command and Control, Exfiltration, Impact.
• Techniques and sub-techniques: the concrete "how". For instance, under Credential Access you find OS Credential Dumping (T1003), Brute Force (T1110), Kerberoasting (T1558.003), among others.
• Procedures: concrete implementations observed in real campaigns.

For threat hunting:

• Building hunts mapped to concrete techniques guarantees coverage and lets you measure.
• ATT&CK Navigator helps visualise which techniques have automated detection, which are covered by hunting and which are blind.
• APT groups and commercial threat intelligence frameworks (Mandiant, CrowdStrike, Microsoft) publish which techniques each actor uses. That helps prioritise which hunts to set up first based on the organisation's threat profile.

Tools used in threat hunting

There is no single "threat hunting" product. Hunting runs across the defensive stack:

• SIEM: the heart of hunting when logs are well centralised. Splunk, Elastic, Sentinel, Chronicle, QRadar allow flexible queries over weeks or months.
• EDR with rich telemetry: CrowdStrike, SentinelOne, Microsoft Defender for Endpoint, Elastic, Tanium. The EDR gives visibility on processes, command lines, network connections per process, registry changes, persistence. The richest source for endpoint hunting.
• NDR (Network Detection and Response): ExtraHop, Vectra, Darktrace. Full network telemetry without depending on the endpoint. Useful for detecting exfiltration, tunnels and lateral movement when the EDR does not cover every asset.
• Active Directory and identity logs: Entra ID Audit, AD Security logs, Okta logs. Credential and lateral-movement hunting requires these logs and is not trivial without them.
• Threat intelligence: commercial feeds (Recorded Future, Mandiant, Microsoft Defender TI) and open ones (MISP, Open Threat Exchange) that supply fresh IoCs and TTPs to build hunts on.
• Dedicated hunting platforms: Hunt by SpecterOps, Vectra Recall, Microsoft Defender XDR Hunting, Elastic Security. They let you save hunts, run them on schedule and share results.

The most important thing is not the tool but the data: if the critical logs (Active Directory, DNS, proxy, firewall, EDR) are not centralised with enough retention, no hunting is possible.

Examples of frequent hunts

Three hunts that show up in any serious programme:

Kerberoasting detection

Hypothesis: if an attacker attempts kerberoasting, they will make TGS-REQ requests against SPN-bearing accounts. Hunt: count TGS-REQ requests per source account in the last 24 hours, alert when an account requests more than N tickets for different services without a known pattern.

Persistence via scheduled tasks

Hypothesis: many attackers create scheduled tasks for persistence. Hunt: detect scheduled task creation (event 4698) whose command runs PowerShell with suspicious arguments (-EncodedCommand, remote download), or whose creator account is not a known administrator.

Exfiltration via DNS

Hypothesis: an infostealer may tunnel exfiltration over DNS to avoid the proxy. Hunt: detect DNS domains with anomalous length, very high frequency of unique queries from one endpoint, or queries to low-reputation domains.

Each confirmed hunt generates a SIEM rule that automates it going forward.

Why threat hunting reduces dwell time

Dwell time (time between the attacker's initial access and detection) is the metric that most influences the cost of an incident. Annual reports (Mandiant M-Trends, IBM Cost of a Data Breach) put the global average dwell time at a few weeks with a downward trend, but a skilled attacker who stays below the reactive SOC threshold can spend months inside.

Threat hunting attacks exactly that gap: it finds what automated controls have not detected. Mature programmes report measurable reductions in dwell time after introducing regular hunts.

Threat hunting and compliance

• NIS2 (article 21). Effectiveness of technical measures and detection procedures. Programmes with documented and traceable hunting form part of the evidence. More in NIS2 in Spain: a compliance guide for 2026.
• DORA (article 9). Detection and response capabilities in financial entities. Hunting is a natural part of the programme. More in DORA compliance guide for financial entities 2026.
• ENS (Spanish Royal Decree 311/2022, Operational Framework). Incident detection with frequency appropriate to the system level. Hunting covers the layer above automated monitoring.
• ISO 27001:2022 (controls 8.16 and 5.7). Monitoring activities and threat intelligence. Documented hunting provides evidence for both.

Common mistakes when setting up a threat hunting programme

Four patterns that appear in programmes that never fully take off:

1. Hunting without enough data. Without Active Directory logs, internal DNS, sysmon or an EDR with complete telemetry, hunts stay superficial. Before hiring senior hunters, secure the log stack.
2. Hunting without a hypothesis. "Let's see what we find" is not hunting. Every hunt needs a concrete question and a success criterion.
3. Not automating confirmed hunts. Every confirmed hunt should become a SIEM or EDR rule. Otherwise the team repeats the same hunt monthly instead of moving forward.
4. Confusing hunting with response. When a hunt confirms malicious activity, the next step is to activate the incident playbook, not to keep investigating indefinitely.

Frequently asked questions

What is the difference between threat hunting and SOC monitoring?

SOC monitoring is reactive: it handles alerts that the SIEM or EDR already fired. Threat hunting is proactive: the analyst starts from a hypothesis and goes looking for evidence that did not trigger an alert. They are complementary; a mature SOC does both.

What profile does a threat hunter have?

Senior. Combines deep knowledge of Windows internals, Active Directory, networks and at least one concrete SIEM and EDR. Reads threat intelligence reports, translates TTPs into queries and has the patience to investigate without a prior alert. Usually comes from a background in SOC, blue team or incident response.

Do you need a dedicated team or can the SOC do it in spare time?

Depends on maturity. An initial programme can start with weekly hunts run by the SOC on published IoCs. Serious programmes separate hunting from reactive monitoring, because mixing the two disciplines in the same shift overloads the analyst and drags out the investigation.

How often is a hunt run?

Established programmes launch 1-3 planned hunts per week, with variable duration (some close in hours, others take several days of cross-investigation). Every hunt is documented and, if it confirms malicious activity, escalated to a formal incident.

Does threat hunting require expensive commercial tools?

They help, but they are not a requirement. With a well-deployed SIEM (Wazuh, Elastic SIEM, Sentinel in its base tier), an EDR with detailed telemetry and open threat intelligence feeds (MISP, Open Threat Exchange), you cover 80% of the value. The non-negotiable piece is the data: without centralised logs with retention, there is no hunting.

How do you measure the success of a hunting programme?

Reasonable metrics: number of hunts executed, number of hunts that produced a new detection rule, dwell time of the last confirmed incident, mapped ATT&CK coverage (what percentage of techniques relevant to the threat profile are covered by detection or hunting). Measuring by raw number of incidents detected doesn't work: a good hunt may find nothing, which is also information.

Related resources

• What is a SOC (Security Operations Center): the team and processes where threat hunting usually integrates in mature organisations.
• What is SIEM and how it works: the platform where the threat hunter runs queries over weeks or months of telemetry.
• What is EDR (Endpoint Detection and Response): the richest source of telemetry for endpoint hunting.
• What is MDR (Managed Detection and Response): the outsourced operation that often includes hunting as a service.
• What is ransomware: how it works: the family with the shortest dwell times in 2025-2026, where hunting makes the difference between catching in time and restoring from backup.
• What is OSINT: cycle, sources, tools: the source of intelligence that feeds many hunt hypotheses.
• What is a CVE: vulnerabilities explained: how new CVE disclosures generate fresh hunt hypotheses.

Threat hunting at Secra

At Secra we support defensive programmes in the threat hunting phase with tactical analysis (ATT&CK mapping of the threat profile, hunt design, integration with existing SIEM/EDR) and execution of ad hoc hunts on the client's telemetry when activity is suspected or hunting coverage needs validation. If your team is building a hunting programme or wants to integrate tactical intelligence into the SOC, get in touch through contact or check our managed cybersecurity services.