Proactive Threat Hunting Methodology

Conventional security operations respond to alerts. Something triggers a detection rule, the alert is routed to an analyst, and the analyst investigates. The model works when adversaries behave in ways that detection rules anticipate. Skilled attackers work around this model by studying the environment's defences, using legitimate tools already present on endpoints, and operating at a pace and volume that blends with normal activity.

Threat hunting inverts the starting point. Instead of waiting for an alert, the hunter starts from the premise that an adversary is already present and has evaded existing controls. The question is not 'did something trigger a rule?' but 'if an adversary were here, what would we expect to see, and can we find evidence of it?' This reframe changes the entire analytical posture: the absence of alerts is not evidence of safety, it is simply the absence of a trigger.

This assumption does not mean an organisation is always compromised. Most hunts will find nothing. A negative hunt result is itself valuable: it provides evidence-based confidence that a specific attacker behaviour is not present in the environment at that time. Documenting negative results creates a historical record that informs future hunts and defence prioritisation.

Three approaches structure most threat hunting programmes. They are not mutually exclusive; experienced hunters move between them depending on available intelligence, the maturity of the environment's logging, and the specific threat being investigated.

Hypothesis-driven hunting starts from a model of adversary behaviour. The hunter selects a tactic or technique from a framework such as MITRE ATT&CK, forms a hypothesis about how that technique would manifest in the organisation's specific environment, identifies the data source that would show evidence of it, writes a query or analytic to surface that evidence, and interprets the results. The approach is particularly effective against advanced persistent threat actors who avoid known malware in favour of living-off-the-land techniques.

IOC-driven hunting starts from concrete artifacts produced by threat intelligence: file hashes from malware analysis, IP addresses of known command-and-control infrastructure, domains associated with phishing campaigns, or registry keys written by specific malware families. The hunter searches the environment for any occurrence of those artifacts. This approach is fast and directly actionable, but its value diminishes as IOCs age. An IP address that was malicious three months ago may now be clean or in use by a different actor.

TTP-based hunting goes one level deeper than IOCs by targeting the underlying method rather than specific artifacts. Instead of searching for a known malicious hash, the hunter searches for any process exhibiting the behaviour associated with credential dumping, such as reading the LSASS process memory space. This approach is more analytically demanding and generates more false positives to triage, but it catches novel variants and custom tools that share the same technique as known malware.

A hunting hypothesis is not a vague intention to look for threats. It is a specific, testable statement that can be confirmed or falsified by querying available data. A well-formed hypothesis has four components: the adversary behaviour or technique being investigated, the data source expected to contain evidence, the specific observable that would constitute evidence, and the expected result if the hypothesis is false.

MITRE ATT&CK is the most widely used framework for building hypotheses. It catalogues over 500 techniques organised under 14 tactics, each with documented procedure examples and suggested detections. A hunter might select technique T1059.001 (PowerShell execution) as the basis for a hypothesis: 'If an adversary is using PowerShell for command-and-control, we expect to see encoded PowerShell commands launched from unusual parent processes. We can test this by querying process creation events from our EDR for powershell.exe with the -enc or -EncodedCommand flag, grouped by parent process name.'

External threat intelligence shapes hypothesis selection. If a threat intelligence report identifies a campaign targeting organisations in the same sector using a specific technique, that technique becomes an immediate hunting priority. National cyber security agencies across multiple jurisdictions publish advisories that directly inform hypothesis selection: examples include CISA advisories (US), NCSC alerts (UK), CERT-In bulletins (India), and ENISA threat reports (EU). A hunter who tracks these feeds maintains a continuously updated backlog of hypotheses ranked by relevance to the organisation's environment.

The quality of a hunt is bounded by the quality and completeness of available data. Before executing a hypothesis, the hunter must confirm that the required data source is being collected, retained for a sufficient period, and queryable at the necessary level of detail. Gaps in logging coverage are themselves a finding: they represent blind spots that an adversary could exploit.

Endpoint telemetry from EDR platforms is the richest source for most host-based hunting. Modern EDR tools record process creation and termination with full command-line arguments, file read and write operations, registry modifications, network connections initiated from each process, and loaded DLLs or kernel drivers. This level of detail is necessary for TTP-based hunting: searching for credential dumping, persistence mechanisms, or process injection requires process-level visibility that traditional antivirus logs do not provide.

Network logs provide a different vantage point. DNS query logs reveal domains that endpoints are resolving, including those associated with command-and-control beaconing or DNS tunnelling. NetFlow or IPFIX records show connection volume, duration, and direction without capturing payload content, which makes them useful for detecting unusual data volumes or connections to unexpected destinations. Proxy logs capture HTTP/S requests and can reveal user-agent strings and URIs associated with known attack frameworks. Full packet capture is rarely retained at scale but is invaluable when available for a specific suspicious timeframe.

Authentication and identity logs are critical for detecting credential abuse, account compromise, and lateral movement. Active Directory event logs record authentication attempts, Kerberos ticket requests, group membership changes, and privilege assignments. Identity provider logs from cloud platforms such as Entra ID (Azure AD) or Okta record SSO events and flag anomalies such as logins from unusual geographies or devices. Cloud control-plane logs, including AWS CloudTrail, Azure Activity Logs, and Google Cloud Audit Logs, record API calls made to cloud services and are the primary data source for hunting in cloud environments.

A structured hunt follows a repeatable workflow regardless of the approach used. The hunter begins by selecting a hypothesis from the backlog, confirms that the required data source is available and covers the relevant time period, writes and executes the initial query, reviews results to separate true-positive candidates from false positives, investigates any suspicious findings to determine whether they constitute confirmed malicious activity, and documents the outcome whether positive or negative.

Hunting maturity models describe how programmes evolve over time. At the lowest maturity level, hunts are ad hoc, triggered by specific intelligence reports, executed manually with simple search queries, and undocumented. At intermediate maturity, the programme maintains a hypothesis backlog, uses structured query languages against a centralised SIEM or data lake, and tracks hunt results. At high maturity, hunts are mapped to a comprehensive coverage model such as MITRE ATT&CK, the team maintains a library of reusable analytics, findings consistently feed new detection rules, and metrics such as time-to-hunt and confirmed findings per quarter are tracked. The Sqrrl Threat Hunting Maturity Model, published in 2015, was an early formalisation of this progression and remains a widely referenced baseline.

A threat hunting programme that only finds threats without improving defences is operating below its potential. The full value of hunting is realised when each confirmed finding produces a durable improvement to the security programme. This loop is what separates hunting from a perpetual manual effort: over time, successful hunts shrink the space of activity that requires human investigation by converting discoveries into automated detections.

When a hunt confirms malicious activity, three outputs follow. First, the finding triggers formal incident response: the compromised systems are handed off to the IR team with the hunter's documentation as the initial analysis, transitioning directly into containment and investigation. Second, the analytic or query that surfaced the finding is converted into a permanent detection rule in the SIEM or EDR platform, so that the same behaviour will generate an alert automatically in future without requiring a hunt. Third, the incident response playbook is updated if the hunt revealed a gap in documented response procedures.

Hunt findings also surface logging gaps. If a hypothesis could not be adequately tested because a required data source was missing or the retention period was too short, that gap is documented and escalated to the logging and infrastructure team. Over successive hunting cycles, this process drives the organisation toward comprehensive telemetry coverage aligned to the threats it faces rather than default logging configurations designed for operational monitoring rather than security investigation. Regulators in multiple jurisdictions increasingly treat logging adequacy as an auditable control: the UK ICO, the US SEC, and the EU's NIS2 Directive all reference logging and monitoring requirements in incident response contexts.

For organisations subject to breach notification obligations, a threat hunting programme that detects adversaries early can materially reduce the regulatory and legal exposure associated with a breach. Faster detection means shorter dwell time, which typically means less data exfiltrated and a more defensible narrative in post-incident regulatory review. India's Digital Personal Data Protection Act 2023, the EU's GDPR, the UK GDPR, and the US state-level breach notification laws all connect notification timelines and obligations to the scope and duration of a breach, making early detection a compliance consideration as well as a security one.