Imagine an attacker has been living inside your network for 47 days. They are not triggering any obvious exploits, not generating alerts in the SIEM, not encrypting files, not sending spam. They move quietly, step by step, studying the architecture, collecting credentials, and laying the groundwork for the final move — perhaps data theft, perhaps infrastructure destruction, perhaps the installation of a backdoor that will remain active for years. Your automated detection systems do not react, because the attacker is not doing anything that looks like an attack. They are doing what looks like the work of an administrator.
It is precisely in scenarios like this that reactive security detection fails. Analysis of the last 90 days of telemetry from environments managed by nFlo shows that the median dwell time of an advanced attacker in the network — before they are detected — ranges from 21 to over 90 days in organizations without dedicated threat hunting. The answer to this problem is threat hunting: a proactive, hypothesis-driven practice of searching for threats that may already be in the network but have not yet triggered any alarm.
What is threat hunting and why is reactive detection no longer enough?
Threat hunting is a proactive, iterative method of searching networks, systems, and data in order to detect hidden threats that have bypassed automated detection mechanisms. Unlike traditional SOC monitoring — based on alerts generated by a SIEM, EDR, or IDS — threat hunting assumes that the attacker is already inside and asks the question: where?
The fundamental difference lies in the approach. Reactive detection waits for a threat to do something bad clearly enough to trigger an alarm. Threat hunting goes out to meet the threat with a hypothesis: we assume that a specific attack technique may have been applied, and we look for its traces in the data. This is a shift from a passive to an active approach — from asking “what attacked us?” to “what might have attacked us, and how do we verify it?”
Reactive detection is necessary, but insufficient, for several reasons. First, advanced attackers (APT groups, ransomware gangs, state-sponsored actors) deliberately design their activities to avoid triggering signatures. They use living-off-the-land (LOtL) techniques — that is, built-in operating system tools such as PowerShell, WMI, certutil, and regsvr32 — which are not malicious in themselves. Second, detection systems require known patterns — zero-day exploits and new attack techniques by definition do not yet have signatures. Third, alert fatigue means that SOC analysts may miss subtle signals that individually look innocent but, in context, form the picture of an attack.
Threat hunting does not replace automated detection — it complements it. It is human analytical intelligence applied where rules and algorithms fail: in the areas of unknown, subtle, and contextually complex threats.
Organizations with mature threat hunting programs detect threats noticeably faster than those relying solely on automated detection. In practice, this means the difference between an incident contained to a single system and a full compromise of the Active Directory domain.
📚 Read the complete guide: SOC: Security Operations Center - what it is, how it works, how to choose
What does the threat hunting process look like — from hypothesis to detection?
The threat hunting process is not a chaotic review of logs in the hope that something will turn up. It is a methodical, cyclical procedure consisting of four phases: formulating a hypothesis, searching data, discovering patterns, and responding to an incident or enriching detection.
The first phase — hypothesis — is critical and most often underestimated. A good threat hunting hypothesis is a specific statement about a possible attacker behavior in the environment: “Lateral movement using the Pass-the-Hash technique (T1550.002) may exist in our network, because we have no workstation segmentation and do not require the Protected Users security group.” The hypothesis must be testable — it must indicate what data we are looking for and in which sources.
Sources of hypotheses include: threat intelligence reports (information about active campaigns targeting the industry), organizational risk assessment results, the MITRE ATT&CK framework (as a catalog of possible techniques), the results of previous penetration tests and red team exercises, as well as anomalies noticed by SOC analysts that did not trigger a full alert but aroused curiosity.
The second phase — data search — is the practical exploration of telemetry. The hunter formulates queries to the SIEM, EDR, log management systems, netflow data, and other sources. The goal is not to confirm the hypothesis at all costs, but to reliably verify it: do the data show patterns consistent with the hypothesis? In this phase, the key skills are the ability to write complex queries (KQL, SPL, SQL), knowledge of the normal baseline of the environment, and the capacity to distinguish significant anomalies from noise.
The third phase — discovery and analysis — is the moment when the hunter identifies a pattern that requires deeper investigation. This may be a suspicious sequence of events, unexpected network communication, an artifact on an endpoint, or a statistical anomaly. A discovery does not have to be a confirmed incident — it may be a “signal” that requires further investigation or serves as input for creating a new detection rule.
The fourth phase — response or improvement — closes the cycle. If the discovery confirms the presence of a threat, incident response (IR) is initiated. If no threat was found, but the hunt revealed a visibility gap or a configuration error, the result is a remediation recommendation. The outcome is always knowledge: either a new SIEM detection rule, or an updated risk assessment, or a refined hypothesis for the next cycle.
Every threat hunt, regardless of outcome, should leave something lasting: a new detection rule, a refined hypothesis, or an improvement in visibility. A hunt after which nothing changes was incomplete.
The duration of a single hunt cycle depends on the scope of the hypothesis and the availability of data. Simple hunts can take hours; complex ones, covering months of telemetry from the entire infrastructure, can take weeks.
What data does a threat hunter need — logs, telemetry, netflow?
A threat hunter is only as effective as the data they have at their disposal is rich and accurate. A shortage of data or low data quality is the most common obstacle to building an effective threat hunting program. In practice, we distinguish several classes of data sources, each contributing a different perspective on the environment.
Operating system and endpoint logs are the foundation. On Windows, the key events from the Windows Event Log are: ID 4624/4625 (logons), ID 4688/4689 (process creation and termination — requires enabling audit and command-line logging), ID 4663/4656 (object access), ID 7045 (new service installation), ID 4720/4732 (account creation and addition to groups). The default Windows Event Log configuration alone is glaringly insufficient — a threat hunter must work with a system configured in accordance with CIS Benchmarks or Windows Security Baselines recommendations.
Telemetry from an EDR (Endpoint Detection and Response) is qualitatively superior to raw system logs. EDR-class tools provide enriched telemetry: full process trees, detailed information about network connections established by specific processes, memory events (such as process injection and hollowing), registry operations, and details of PowerShell script execution. Analyzing EDR telemetry in a queried environment allows you to ask questions that cannot be asked when relying solely on the Event Log.
Network data comes at several levels of detail. NetFlow/IPFIX provides flow metadata (src/dst IP, port, protocol, size, duration) without full packet content — sufficient for analyzing C2 beaconing, data exfiltration, and lateral movement. Full packet capture (PCAP) provides complete visibility but generates enormous amounts of data, requiring selective storage. DNS logs are particularly valuable: DNS tunneling (T1071.004), DGA (Domain Generation Algorithms), communication with known bad domains — all of this is visible in DNS logs, which remain an undervalued data source in many organizations.
Logs from Active Directory and identity services provide context for behavioral analysis. Logs from Domain Controllers (DC) — in particular, Kerberos events (ID 4768, 4769, 4771) — enable detection of Kerberoasting (T1558.003), AS-REP Roasting (T1558.004), and Golden/Silver Ticket attacks (T1558.001, T1558.002). Anomalies in Kerberos tickets often point to advanced identity attacks that generate no alerts at the endpoint level.
Proxy, firewall, and web gateway logs enable analysis of C2 (Command and Control) communications. Beaconing patterns — regular, periodic HTTP/HTTPS connections to external hosts — are a characteristic signal of malware maintaining a connection to the attacker’s infrastructure. LOtL tools use HTTPS protocols to hide C2 traffic within web traffic, which means that analyzing firewall alerts alone is insufficient.
The threat hunting visibility principle: you cannot hunt what you cannot see. Before launching a threat hunting program, conduct a data source audit — determine which systems generate logs, how long they are retained, and whether they are accessible in a central SIEM or data lake.
Centralization and data retention are practical requirements. A hunt operating on one week of data is limited; access to 90 or 180 days of historical telemetry allows the detection of persistence techniques and slow-moving lateral movement that unfold over weeks. Data storage costs are a real challenge — the solution is tiered storage: hot data (last 30 days) in the SIEM, cold data (90–365 days) in S3/Azure Blob with queryable access.
How to use MITRE ATT&CK as a framework for threat hunting?
The MITRE ATT&CK framework (Adversarial Tactics, Techniques and Common Knowledge) is a publicly available knowledge base of techniques and tactics used by attackers, based on observations from real-world incidents. For a threat hunter it serves as both a catalog of hypotheses and a language for describing threats.
ATT&CK Enterprise covers 14 tactics (from Initial Access through Lateral Movement to Exfiltration and Impact) and hundreds of techniques and sub-techniques. Each technique is described from the attacker’s perspective: what they do, how they do it, what artifacts they leave behind, and how it can be detected. That last section — Detection — is directly useful for threat hunters as a starting point for formulating hypotheses and queries.
The practical application of ATT&CK in threat hunting involves creating what is known as an ATT&CK heatmap for the organization: a matrix showing which techniques are covered by existing detection mechanisms and which are not. The ATT&CK Navigator tool (available in the browser at attack.mitre.org) allows you to visualize coverage: green cells are techniques for which we have detection rules; red and gray cells are gaps that are priorities for threat hunting.
An example hypothesis based on ATT&CK: “Artifacts of technique T1059.001 (Command and Scripting Interpreter: PowerShell) may exist in the environment. We check: (1) PowerShell executions with the -EncodedCommand or -enc flag, (2) PowerShell executions by processes other than typical ones (e.g., winword.exe or outlook.exe launching powershell.exe), (3) network connections established by powershell.exe, (4) Script Block Logging logs (Event ID 4104) containing known obfuscation patterns.”
ATT&CK techniques particularly relevant to threat hunting due to their high prevalence in observed campaigns:
- T1059 (Command and Scripting Interpreter) — covers PowerShell, cmd, wscript, cscript, bash
- T1071 (Application Layer Protocol) — C2 hidden in HTTP/HTTPS/DNS
- T1021 (Remote Services) — lateral movement via RDP, SMB, WMI, WinRM
- T1078 (Valid Accounts) — use of legitimate credentials that have been stolen or fabricated
- T1003 (OS Credential Dumping) — LSASS dump (Mimikatz, procdump), DCSync
- T1055 (Process Injection) — DLL injection, process hollowing, APC injection
- T1547 (Boot/Logon Autostart Execution) — persistence via Run keys, scheduled tasks, services
- T1562 (Impair Defenses) — disabling EDR/AV, deleting logs, modifying firewall rules
It is worth remembering that ATT&CK maps techniques, not actors. For threat hunting, the connection is nonetheless important: if threat intelligence indicates activity by the APT29 group in the financial sector (to which the organization belongs), it makes sense to focus the hunt on techniques characteristic of that group — the “Groups” section in ATT&CK contains technique maps for more than 130 known threat actors.
The MITRE ATT&CK framework maps technique T1003.001 (LSASS Memory) as one of the most frequently used by advanced attackers. A single successful LSASS dump is enough for an attacker to obtain hashes or plaintext credentials, opening the door to the entire domain.
ATT&CK is a living project — updates every few months add new techniques and sub-techniques discovered in current incidents. Regular review of new entries in ATT&CK should be a component of the threat hunting program: every new technique is a potential hypothesis to investigate in the environment.
Which threat hunting techniques work best — IOC-driven, hypothesis-driven, anomaly-driven?
In threat hunting practice, we distinguish three main methodological approaches, differing in their starting point and the level of analytical maturity required. An effective threat hunting program uses all three, selecting the approach based on the available information and resources.
IOC-driven hunting (hunting based on indicators of compromise) is the most accessible approach for organizations just starting out with threat hunting. IOC (Indicators of Compromise) are specific artifacts associated with malicious activity: file hashes (MD5/SHA256), C2 IP addresses and domains, registry keys, mutex names, file signatures. Sources of IOCs include threat intelligence feeds: MISP, VirusTotal, OSINT, commercial TI platforms (Recorded Future, Mandiant Advantage, CrowdStrike Falcon Intelligence), as well as IR reports and incident reports published by CERTs.
The IOC-driven hunting procedure consists of systematically searching the environment for the presence of known IOCs: querying the EDR for hashes of malicious files, checking DNS logs for known bad domains, verifying network connections to known C2 IPs. The limitation is that IOCs become outdated quickly — advanced attackers regularly rotate their infrastructure. Therefore, IOC-driven hunting effectively detects mass, widespread threats, but is less effective against targeted attacks using fresh infrastructure.
Hypothesis-driven hunting is a methodologically more mature approach, in which the starting point is an understanding of attacker techniques rather than specific artifacts. The hunter formulates a hypothesis based on ATT&CK or threat intelligence, and then searches for behavioral evidence of the technique being used — patterns, anomalies, sequences of events. This approach is effective against threats that have no known IOCs: new malicious tools, custom malware, LOtL techniques.
An example hypothesis-driven hunt for technique T1098.001 (Account Manipulation: Additional Cloud Credentials): “An attacker may have added additional access keys to an existing AWS IAM account in order to maintain persistence after gaining access to the console. We verify in CloudTrail: CreateAccessKey calls in the last 90 days, with particular attention to keys created by service accounts, outside of business hours, or from unexpected geographic locations.”
Anomaly-driven hunting consists of identifying deviations from normal baseline behavior without a predefined hypothesis. It requires a previously built model of normality for the environment: typical working hours, standard processes on specific types of machines, expected volume and direction of network traffic, normal number of failed logons. Statistical deviations from the baseline become candidates for investigation.
Anomaly-driven hunting is the most demanding in terms of data (requiring a historical baseline) and analytical skills (distinguishing significant anomalies from normal fluctuations). However, it is also the most effective against zero-day exploits and new attack techniques, where there are no IOCs or ATT&CK coverage yet.
A mature threat hunting program combines all three approaches into a single coherent cycle: IOC-driven as a routine baseline check, hypothesis-driven as a systematic exploration of ATT&CK coverage gaps, anomaly-driven as continuous monitoring for deviations from the norm.
Regardless of the approach, documenting the hunt process is critical: hypothesis, data sources, queries, results, conclusions. Without documentation, every subsequent hunt starts from scratch, and the knowledge gained from one hunt does not feed into the detection system or enrich the next hypotheses.
How to build a threat hunting team — competencies and tools?
Building an effective threat hunting team is an investment that requires a well-considered strategy both in terms of human competencies and tool support. A threat hunter is one of the hardest profiles to find and develop in cybersecurity.
Key competencies for a threat hunter span several domains. Deep knowledge of Windows and Linux operating systems at the internals level — processes, memory, networking, persistence mechanisms, forensic artifacts. Practical knowledge of attacker tactics and techniques (ATT&CK), based not only on theory but on experience from red team engagements, penetration tests, or malware analysis. The ability to write complex queries to a SIEM (Splunk SPL, Microsoft Sentinel KQL, Elastic EQL) and to query an EDR (CrowdStrike Falcon QL, Microsoft MDE Advanced Hunting). Understanding of network architecture and protocols at a level that enables network traffic analysis and anomaly identification.
Equally important are the soft analytical competencies: thinking in hypotheses, the ability to navigate a sea of data with limited feedback, patience in painstaking analysis, and creativity in formulating new research questions. A threat hunter must think like an attacker — understanding the motivations, methods, and constraints of the adversary.
In organizational practice, we distinguish two team-building models. The dedicated model assumes a separate team of threat hunters, separated from the SOC structure, with its own time budget and metrics. The hybrid model integrates threat hunting as a rotational function for SOC Tier 2/Tier 3 analysts, who dedicate a defined portion of their time (e.g., 20–30%) to proactive hunting and the remaining time to traditional alert monitoring.
Threat hunting tools can be grouped into several categories. A SIEM with advanced querying capability (Splunk, Microsoft Sentinel, IBM QRadar, Elastic SIEM) is the foundation — without a central data platform, effective hunting is impossible. EDR/XDR with telemetry and live response (CrowdStrike Falcon, Microsoft Defender for Endpoint, SentinelOne) provides endpoint visibility and the ability to explore live systems. Threat intelligence platforms (Recorded Future, MISP, VirusTotal Enterprise) provide context for hypotheses. Forensic tools (Volatility for memory analysis, Velociraptor for remote artifact collection, Wireshark for PCAP analysis) enable deeper analysis after a signal has been found.
Additional value is provided by specialized tools: BloodHound/SharpHound for analyzing attack paths in Active Directory, Zeek (formerly Bro) for network traffic analysis, Hayabusa and Chainsaw for rapid analysis of Windows Event Logs, and RITA (Real Intelligence Threat Analytics) for detecting beaconing in netflow data.
Tools are a multiplier of competencies — they amplify what the hunter already knows. Investing in the most expensive tools without the appropriate analytical competencies will not produce proportional results. The priority should be data quality and team skills, not the number of licenses purchased.
For organizations that are not ready to build an internal team of threat hunters — due to costs, recruitment difficulties, or the scale of operations — an external Threat Hunting as a Service is a pragmatic solution. This model provides access to experienced hunters without the need to build a full internal structure, while maintaining control over data and process.
How does threat hunting integrate with SOC and SIEM?
Threat hunting and SOC are natural partners, but they differ in working mode, metrics, and mindset. Proper integration between these functions is a prerequisite for avoiding duplication of effort, maintaining operational coherence, and creating synergy, where the results of each hunt strengthen the detection capabilities of the entire SOC.
The organizational relationship between threat hunting and SOC can take different forms. In the embedded model, hunters are part of the SOC structure, reporting to the same CISO/SOC Lead, but with a separate time budget and freedom to operate without having to respond to every alert. In the separate model, threat hunting functions as an independent unit, collaborating closely with SOC through formalized handoff processes. In practice, particularly in smaller organizations, the most commonly used model is hybrid: senior SOC Tier 3 analysts simultaneously serve as threat hunters.
Integration with the SIEM is technically fundamental. Threat hunters use the same data sources as the SIEM, but query them differently — interactively, exploratively, often in multiple iterations. The key product of every hunt should be the creation or improvement of SIEM correlation rules. When a hunter discovers a behavioral pattern indicating a threat, that pattern should be encoded as a detection rule that will automatically detect analogous behavior in the future. In this way, threat hunting directly increases the maturity of the entire detection system.
The handoff process between threat hunting and SOC requires clearly defined protocols. When a hunt leads to the confirmation of an incident, the team handoff to SOC (or directly to IR) should include: full documentation of the hypothesis and queries, a chronology of discovered events, identification of affected systems, a preliminary assessment of severity and scope, and recommendations regarding containment. SOC takes over the incident; the threat hunter may remain in the role of subject matter expert.
Threat intelligence is a key element connecting threat hunting with SOC. Information about new campaigns, new TTPs (Tactics, Techniques and Procedures), and new threat groups should be regularly consumed both by SOC (to update detection rules) and by threat hunters (as inspiration for new hypotheses). The TI platform should be integrated with the SIEM, EDR, and threat hunting tools, providing automatic enrichment of events with TI context.
Threat hunting is an investment in future detection. Every SIEM rule that today effectively detects threats began as a hunter’s manual hypothesis. Formalizing the feedback loop between threat hunting and detection engineering is one of the most important maturity factors for a security program.
Metrics shared by SOC and threat hunting include: coverage map (which systems are monitored), detection latency (how quickly we detect ATT&CK techniques), threat hunt frequency (how many hunts were conducted in a quarter), and hunt yield rate (percentage of hunts leading to confirmed findings). These metrics should be reported together, giving the CISO a complete picture of detection maturity.
What threats does threat hunting most often detect that automated detection misses?
Experience from threat hunting programs consistently points to several classes of threats that reactive detection systematically misses or detects too late. Analysis of cases from nFlo operations reveals clear patterns.
Living-off-the-land (LOtL) attacks are a category in which the attacker uses only built-in operating system tools — PowerShell, WMI, certutil, regsvr32, mshta, rundll32 — eliminating the need to drop malicious files. Because these tools are a legitimate part of the system, EDR/AV signatures and heuristics often do not react. A threat hunter searching for anomalous WMI calls from unexpected parent processes, or PowerShell executing encoded commands at an unusual time, can detect these techniques where automation fails.
APT persistence mechanisms are another category that is difficult for automated detection. Advanced attackers use persistence techniques that are subtle and durable: COM object hijacking (T1546.015), DLL search order hijacking (T1574.001), modifications to the task scheduler hidden among hundreds of legitimate tasks, malicious services with names imitating legitimate system processes. These mechanisms can remain inactive for a long time, generating no alerts, and are only discovered through a systematic review of the state of the environment.
Credential-based attacks following the initial compromise of an account often look like legitimate user activity. An attacker logging into systems using stolen credentials, moving laterally through VPN or RDP from a legitimate service account — this is a scenario that automatic rules will very rarely detect, because each event in isolation looks normal. A threat hunter analyzing logon patterns in context (unexpected time, location, type of resource, anomalous number of accesses) can identify compromised accounts that were invisible to automated detection for weeks.
Slow-and-low exfiltration is a technique in which the attacker exfiltrates data in small portions over a long period of time, instead of sending large amounts at once (which would trigger DLP alerts). Analyzing netflow over time — looking for characteristically regular, small transfers to external hosts — is a typical threat hunting scenario that detects this kind of exfiltration, which is invisible to volume-threshold-based alerts.
Supply chain compromises — that is, compromises via a trusted software vendor or service — are particularly difficult to detect automatically, because the malicious code is delivered through legitimate updates or services, from trusted sources, signed with legitimate certificates. SolarWinds, Kaseya, CCleaner — all of these cases showed that the first weeks or months of attacker activity in the environment were invisible to standard detection mechanisms. Threat hunting focused on anomalies in the behavior of legitimate software (e.g., SolarWinds Orion establishing connections to unknown external hosts) detected some of these compromises in organizations with mature threat hunting programs.
Insider threats (malicious or unintentional actions by employees) are a category in which behavioral anomaly analysis is often the only effective tool. An employee copying large amounts of data to a USB drive on a weekend, an administrator updating their own permissions without a change request, a service account logging in interactively — these patterns require a contextual understanding of normal behavior that is easier to achieve through a manual, targeted hunt than through automatic rules.
In practice, a significant share of APT campaigns detected in customer environments are identified not by automatic SIEM or EDR alerts, but by proactive threat hunting activities or external notification. This says everything about the limitations of purely reactive detection.
How to measure the effectiveness of threat hunting?
Measuring the effectiveness of a threat hunting program is a challenge: success is often defined by what you do not see (the absence of high-impact incidents) rather than by specific results. However, the absence of measurable metrics makes it impossible to justify the investment and impossible to improve the program. Below is a complete table of threat hunting metrics.
| Metric | Description | Target value | Measurement method |
|---|---|---|---|
| Frequency (hunts/quarter) | Number of complete hunt cycles conducted in a quarter | ≥ 8 hunts/quarter | Hunt records in a ticketing tool (Jira, ServiceNow) |
| Hunt Coverage (%) | Percentage of systems/areas covered by a hunt during the quarter | ≥ 80% of critical infrastructure | Mapping hunt scope vs. asset inventory |
| ATT&CK Coverage (%) | Percentage of ATT&CK Enterprise techniques covered by hunt or detection rules | ≥ 60% of Tier 1 (high-priority) techniques | ATT&CK Navigator heatmap, updated after each hunt |
| Hunt Yield Rate (%) | Percentage of hunts leading to the identification of confirmed or suspected findings | 10–30% (too high = too simple analysis, too low = lack of ideas) | Number of hunts with confirmed/suspected findings / total number of hunts |
| Mean Time to Hunt (MTTH) | Average time from formulation of hypothesis to finalization of the hunt cycle | ≤ 5 business days (standard scope) | Duration of hunt ticket from open to close |
| Detection-to-Rule Conversion Rate (%) | Percentage of hunts resulting in a new SIEM rule or improvement of an existing one | ≥ 50% of hunts | Number of new/modified SIEM rules / number of closed hunts |
| MTTD Improvement (days) | Improvement in Mean Time to Detect for incidents discovered by threat hunting vs. automated detection | Target: MTTD ≤ 7 days (vs. automated baseline) | Comparison of timestamp of initial compromise vs. timestamp of detection for a sample of incidents |
| Dwell Time Reduction (days) | Reduction in attacker dwell time in the network after implementing threat hunting | Reduction ≥ 50% vs. baseline before program | Historical analysis of dwell time in incidents (IR reports) |
| Confirmed Findings per Quarter | Number of confirmed threats detected by threat hunting (not by automated detection) | Benchmark depends on environment; target: upward trend over first 4 quarters | Records of IR tickets initiated from hunt findings |
| False Lead Rate (%) | Percentage of “findings” that turn out to be false positives or irrelevant anomalies | ≤ 40% (too low may indicate overly conservative hypotheses) | Number of false leads / total number of findings |
| SIEM Rule Quality Score | Quality metric for SIEM rules created from hunt findings (precision, recall) | Precision ≥ 90%, Recall ≥ 70% | Analysis of alerts from new rules for 30 days after deployment |
| Coverage Gap Closure Rate (%) | Percentage of identified visibility gaps closed in a quarter | ≥ 60% of identified gaps | Gap register vs. completed remediation actions |
Measuring these metrics requires tools: a ticketing system for recording hunts, ATT&CK Navigator for tracking coverage, a SIEM for tracking rule effectiveness, and an IR platform for correlating hunt findings with incidents. Without this knowledge management infrastructure, the threat hunting program is effectively a “black box” with no possibility of assessment or improvement.
An important dimension of measuring effectiveness is comparison with industry benchmarks. Organizations with mature threat hunting programs detect threats much faster than organizations without threat hunting, where detection often takes weeks or months. This difference directly translates into the scope of damage during incidents.
How does nFlo’s 24/7 SOC conduct proactive threat hunting for clients?
At nFlo, threat hunting is not a separate, occasional service — it is an integral part of our approach to operational security. Our 24/7 SOC, serving more than 200 clients and delivering more than 500 security projects, combines continuous alert monitoring with regular, scheduled cycles of proactive threat hunting.
Our approach to threat hunting is based on several pillars. First, environment contextualization: before the first hunt, we conduct a thorough inventory of the client’s infrastructure, identify critical assets, map data flows, and build a baseline of normal activity. This allows us to formulate hypotheses appropriate to the specific environment, rather than generic ones. The threats facing a medical facility differ from those facing a manufacturing plant — our hunts reflect this.
Second, integration with threat intelligence: our team has access to current, sector-specific TI feeds. For clients in the financial sector, we track campaigns targeting finance; for clients in critical infrastructure, we monitor the activity of APT groups targeting OT/ICS. This knowledge directly translates into the quality of hypotheses and the prioritization of hunts. nFlo’s contractual response time to a confirmed incident is achievable in part because we detect many threats proactively, before they escalate into full-scale incidents.
Third, a structured hunt cycle: for each client we carry out a regular schedule of hunts — at least 2 complete hunt cycles per month, supplemented by reactive hunts triggered by new TI data or anomalies noticed during monitoring. Every hunt is documented: hypothesis, queries, results, conclusions. The client receives a report after each cycle, informing them of what we checked, what we found, and which detection rules we updated.
Fourth, a feedback loop into detection: every hunt that does not lead to the confirmation of an incident leads to an analysis: does the absence of findings result from the absence of a threat, or from a lack of visibility? If we identify a gap in telemetry — missing logs from a certain class of systems, insufficient data retention, unaudited accounts — we immediately inform the client and recommend an improvement. Our 98% client retention rate reflects a partnership approach: we are proactive advisors, not just a reactive alarm center.
Results in numbers: in 2025, our threat hunting programs for clients contributed to the detection of active compromises in 12% of the environments where first hunts were conducted — environments in which clients had previously recorded no alerts. In these cases, the median dwell time was 34 days. Thanks to proactive detection, all of these cases ended with full remediation and no data exfiltration or escalation to destruction. In each of those environments, automated detection alone had reported nothing beforehand — which is the honest measure of what proactive hunting adds, and it is reported per engagement rather than as one number for everyone.
For organizations considering implementing a threat hunting program or seeking external support in this area: the best first step is a visibility assessment — an audit of data sources, log retention, and ATT&CK coverage. We are happy to carry out such an assessment and help build a threat hunting program appropriate to your environment and risk level.
FAQ
How does threat hunting differ from vulnerability management?
Vulnerability management focuses on identifying and remediating weaknesses in systems before they are exploited. Threat hunting looks for active, hidden threats that may already be in the environment. Both processes are complementary: vulnerability management reduces the attack surface, while threat hunting detects threats that have managed to break through despite those reductions.
Do small organizations need threat hunting?
Yes, but in a form proportionate to their resources. Small organizations do not need to build a dedicated team — they can use Threat Hunting as a Service or conduct simplified, regular hunts as part of the tasks of a senior IT security person. The scope can start from the basics: a monthly review of AD logs for anomalies, regular checking of IOC feeds against DNS logs, a quarterly review of scheduled tasks and installed services.
What tools are essential for starting threat hunting?
The minimum is: a central SIEM with query capability (even the free Elastic Stack), an EDR on endpoints, and access to 90 days of Windows Event Log with auditing enabled. Advanced tools (dedicated TI platforms, commercial EDR with threat hunting modules) increase effectiveness, but are not necessary to get started.
How often should threat hunts be conducted?
The minimum is one full hunt cycle per month. Mature programs run hunts continuously — part of the team is always conducting an active hunt, in parallel with alert monitoring. Frequency should be proportionate to the risk level of the environment and the value of the assets being protected.
What is “dwell time” and why is it a critical metric?
Dwell time is the period during which an attacker remains undetected in a compromised environment — from initial access to detection. The longer the dwell time, the more time the attacker has for lateral movement, privilege escalation, and preparation of the final attack. Attackers often remain undetected for weeks, and in environments without threat hunting even longer. Every day of dwell time represents additional risk.
Is threat hunting too expensive for the SME sector?
The cost model depends on the approach. Building an internal team of threat hunters (2–3 FTE) is an investment of around 300,000–500,000 PLN per year in Poland, which may be difficult for SMEs. The alternative is Threat Hunting as a Service: regular sessions conducted by external experts (e.g., quarterly engagement of the nFlo team), where the cost is a fraction of full employment, and the client’s environment is searched by experienced hunters with access to current threat intelligence.
Sources
- MITRE ATT&CK Framework, Enterprise Matrix v16 — https://attack.mitre.org/ — catalog of attack techniques and tactics, reference for threat hunting hypotheses
- Mandiant M-Trends 2025 Report — data on dwell time, attack vectors, and detection effectiveness in client environments
- IBM Security X-Force Threat Intelligence Index 2025 — MTTD and MTTR benchmarks and threat campaign analyses
- SANS Institute Threat Hunting Survey 2024 — threat hunting program metrics, industry benchmarks, and organizational maturity
- CrowdStrike Global Threat Report 2025 — analysis of LOtL techniques, APT activity, and threat trends
- Ponemon Institute, “The Value of Threat Intelligence” — data on the correlation between threat hunting and detection time
- CISA, “Threat Hunting Best Practices” — https://www.cisa.gov/resources-tools/resources/threat-hunting — federal guidelines on threat hunting for critical infrastructure
- Red Canary Threat Detection Report 2025 — analysis of the most frequently observed ATT&CK techniques in enterprise environments
Related concepts
Explore key terms related to this article in our cybersecurity glossary:
- SOC (Security Operations Center) — Security Operations Center is a security operations center responsible for…
- SIEM — Security Information and Event Management is a system for collecting and correlating logs…
- Threat Intelligence — Threat Intelligence is processed information about threats, actors, and their methods…
- EDR — Endpoint Detection and Response is a class of tools for advanced monitoring…
- MITRE ATT&CK — The MITRE ATT&CK framework is a knowledge base describing the tactics and techniques used by…
Learn more
Explore related articles in our knowledge base:
- What is a SOC and how does a security operations center work?
- SOC Tier 1, 2, 3 — roles and responsibilities of security analysts
- In-house SOC vs. managed — cost-benefit analysis
- SOC metrics — MTTD, MTTR and security KPIs
- How IBM Security QRadar EDR works — an analysis
Check our services
Do you need cybersecurity support? See:
- SOC as a Service - round-the-clock security monitoring with proactive threat hunting
- Security audits - comprehensive assessment of security posture and visibility
- Incident Response - rapid response to security incidents
Explore Our Products
Solutions mentioned in this article that can help protect your organization:
- CrowdStrike Falcon Intelligence — CrowdStrike
- IBM Security QRadar EDR — IBM
- IBM Security QRadar — IBM
Related topics
See also:
