Here is the statistic that should end every conversation about threat hunting being only for large organisations with dedicated security teams: in 2026, the average attacker breakout time — the time between initial access and lateral movement to a second system — is 29 minutes. The fastest observed is 27 seconds.

Your SIEM alert cycle runs in minutes at best. Your on-call rotation responds in tens of minutes at best. An attacker operating at 29-minute breakout speed is already moving laterally before your first alert fires.

The conventional response to this problem is “hire a threat hunter.” A dedicated threat hunter is a legitimate and effective solution. It is also a solution that 61% of organisations cannot implement, because they cite staffing shortages as their primary barrier to running any threat hunting programme at all. This article is for that 61%. It is a practical, step-by-step guide to running hypothesis-driven threat hunts inside an engineering organisation that has a SIEM, engineering curiosity, and protected time — but no dedicated threat hunter.

Foundations

What Threat Hunting Actually Is — and What It Is Not

Threat hunting is not alert triage. When your SIEM fires and an engineer investigates the alert, that is reactive security operations — valuable, necessary, but not hunting. Hunting starts before the alert fires. It assumes the attacker is already inside your environment, operating below your alert thresholds, and asks: where are they, and what are they doing?

Threat hunting is not random log archaeology. Pulling logs and looking for “anything suspicious” is not a hunt. It is expensive and produces nothing repeatable. A hunt starts with a specific hypothesis — a testable statement about attacker behaviour in your specific environment — and queries your telemetry to validate or refute it.

Threat hunting is not a one-time activity. A single hunt covers one hypothesis at one point in time. The discipline is a quarterly cycle: form a hypothesis, execute the hunt, document the findings, convert the findings into a detection rule, and repeat next quarter with a different hypothesis.

The output of every completed hunt is exactly two things, regardless of whether a threat was found: a hunt report documenting what was looked for and what was found, and a new detection rule that automates the same search going forward.

Every hunt makes your automated detection better. After a year of quarterly hunts, you have four new detection rules covering attacker techniques that were previously invisible to your stack.

Prerequisites

What You Need Before You Hunt

Threat hunting does not require specialised tooling beyond what most engineering organisations already have. The minimum viable hunting stack is four things:

Log retention
A SIEM or log aggregation platform with at least 90 days of retention. Patient adversaries operate over weeks and months. Twelve months is the preferred target.
Four log sources
Identity, endpoint, network, and Kubernetes API server audit logs. Missing any one leaves blind spots that patient adversaries will exploit.
Query interface
KQL in Sentinel, SPL in Splunk, Lucene in Elastic, or SQL against a data lake — any interface supporting multi-condition, time-bounded, grouped queries.
One senior engineer
Three to four hours of protected time per quarter. Environmental knowledge of the cluster matters more than security specialism.
⚠ Validate your data before you hunt

The most common reason hunts produce nothing useful is not a lack of attacker activity — it is a lack of data. Spend 30 minutes confirming the logs you need are actually being collected, in the right format, with sufficient retention, before writing a single query.

The Process

The Four-Phase Hunt Cycle

Every hunt, regardless of scope or complexity, follows the same four phases. Skipping any phase produces either wasted effort or wasted findings.

Phase 01
Form the hypothesis
Specific, testable, grounded in known attacker behaviour, targeting a gap in current detection coverage
Phase 02
Validate your data
Confirm required logs are collected, correctly formatted, and within the retention window
Phase 03
Execute the hunt
Queries, pattern matching, anomaly investigation. Time-boxed to 4–8 hours. Correlation over isolation.
Phase 04
Document and convert
Hunt report plus one new detection rule — mandatory regardless of whether a threat was found

Forming the Hypothesis

A good hypothesis has exactly three properties: it is specific enough to test, it is grounded in known attacker behaviour, and it targets a gap in your current automated detection. Use this template:

“[Attacker technique] may exist in our environment because [specific condition that makes this plausible], and our current detection does not cover it because [named gap].”

✦ Best sources for hypothesis generation

CERT-In advisories name techniques actively used against organisations in your sector and geography right now. FS-ISAC (for financial sector GICs and GCCs) publishes threat briefings identifying specific TTPs from recent incidents. MITRE ATT&CK Navigator shows which techniques your current detection covers and which it does not. Your own previous near-misses are the third source.

Executing the Hunt — Correlation, Not Isolation

A single anomalous data point is often benign. The same data point in combination with two or three contextual signals is the finding. Start broad, group by account and endpoint to see the baseline distribution, then look for deviations. Time-box the hunt. A focused hunt against a single hypothesis should take four to eight hours of engineer time. A hunt stretching beyond one week without findings is too broad — tighten the hypothesis.

The Non-Negotiable Phase 4 Outputs

Every hunt produces two mandatory outputs regardless of findings. A hunt report — at minimum: the hypothesis, ATT&CK technique, data sources queried, queries used, time window, findings including documented true negatives, engineer name, and date. And a new detection rule — encode the search logic as an automated SIEM alert whether the hunt found a threat or confirmed its absence. After twelve months of quarterly hunts, you have at minimum four new automated detections covering techniques your stack previously could not see.

The Five Hunt Templates

Starter Hypotheses for Kubernetes and Cloud-Native Environments

These are the five hunts to run first for any engineering organisation operating cloud-native infrastructure in 2026. Each is grounded in MITRE ATT&CK techniques consistently observed in incidents affecting GICs, GCCs, and engineering organisations — and each targets a gap that most automated detection stacks leave open.

Hunt 01
Service Accounts Making API Calls Outside Business Hours
ATT&CK technique
T1078.001 — Valid Accounts: Default Accounts
Data source
Kubernetes API server audit logs
Window
90 days
Hypothesis: Compromised or abused service accounts may be making Kubernetes API server calls outside their normal operational hours, because automated workloads follow consistent schedules and anomalous off-hours activity indicates either a compromised credential or an unknown automation job.
Query logic: Pull all API server calls from all service accounts over 90 days. Group by service account name and hour of day. Identify accounts where more than 5% of calls occur between 22:00 and 05:00 local time. Exclude accounts whose documentation explicitly states they run scheduled jobs outside business hours.
Positive finding looks like
A service account normally associated with a specific microservice making API calls to secrets or exec endpoints at 02:30 AM with no corresponding deployment pipeline activity visible in CI/CD logs.
Hunt 02
Pods Communicating with Destinations Outside Your Approved Egress List
ATT&CK technique
T1071 — Application Layer Protocol (C2)
Data source
Network flow logs / Cilium Hubble
Window
30 days
Hypothesis: A compromised pod may be establishing outbound connections to attacker-controlled infrastructure, because default-deny NetworkPolicy may have pre-existing pods exempted during rollout that have never been reviewed.
Query logic: Pull all outbound connections from pods to external IPs. Cross-reference against your approved egress destinations. Flag any external IP not on the approved list receiving more than 100 bytes of data. Enrich with threat intelligence — flag any destination appearing in Abuse.ch or OTX.
Positive finding looks like
A production namespace pod making regular HTTPS connections to an IP range outside any known vendor or cloud provider, especially one appearing in threat intelligence feeds as known C2 infrastructure.
Hunt 03
Unusual Volume of Secret Reads from Any Single Identity
ATT&CK technique
T1552.007 — Unsecured Credentials: Container API
Data source
Kubernetes audit logs — secrets resource, get verb
Window
30 days
Hypothesis: An attacker with a valid credential may be reading Kubernetes secrets at a volume inconsistent with normal application behaviour. Legitimate applications typically read secrets once at startup — not repeatedly throughout the day.
Query logic: Pull all secret read events from audit logs. Group by requesting identity and count distinct secrets read per day. Establish the baseline per identity. Flag any identity that reads more than three standard deviations above their personal baseline on any single day, or reads secrets from namespaces they do not normally access.
Positive finding looks like
A front-end application service account reading 47 secrets in a single afternoon — including secrets from a namespace serving a completely different service. Either a misconfiguration or credential theft followed by secret enumeration.
Hunt 04
DNS Queries to Newly Registered Domains from Production Workloads
ATT&CK technique
T1568 — Dynamic Resolution
Data source
CoreDNS query logs
Window
14 days
Hypothesis: A compromised pod may be communicating with newly registered attacker infrastructure via DNS, because attackers frequently register fresh domains to avoid blocklists — and legitimate production workloads have no operational reason to contact domains registered in the last 30 days.
Query logic: Pull all DNS queries from production namespace pods over 14 days. Enrich each queried domain with registration date via WHOIS bulk lookup or threat intel platform. Flag any domain registered within the last 30 days receiving more than 3 queries from production pods. Exclude known CDN and cloud provider dynamic domain patterns.
Positive finding looks like
A pod making repeated DNS queries to a domain registered three weeks ago, hosted on a bulletproof hosting provider, with no entry in your vendor registry or application dependency documentation.
Hunt 05
Cloud Console Authentication from Outside Your Known Engineering Footprint
ATT&CK technique
T1078 — Valid Accounts
Data source
AWS CloudTrail / Azure Activity Log / GCP Cloud Audit Logs
Window
90 days
Hypothesis: A compromised developer credential may be used to authenticate to your cloud provider console from a geography your engineering team does not operate from. Existing alerts only fire on failed authentications — successful logins from unusual locations generate no alert.
Query logic: Pull all successful console authentications over 90 days. Geolocate the source IP to country and city. Define your known engineering footprint — the cities where your engineering teams are based, any locations where your organisation operates remotely, and approved VPN exit points. Flag any successful authentication from outside this footprint. Correlate with breach intelligence — cross-reference authenticating account email addresses against recent breach databases.
Positive finding looks like
A senior engineer’s AWS account authenticating successfully from a city they have never worked in, at 3 AM local time, in the same week their email address appears in a newly published breach database. Warrants immediate credential rotation and access review.
Sustaining the Programme

Converting Hunt Findings into the Detection Engineering Backlog

The five hunts above are a starting point, not a repeating cycle. After you run each one and convert it into a detection rule, the rule takes over the automated search and the next hunt quarter targets a different hypothesis.

Build a detection engineering backlog that maps each new hunt to the gap it closes: hypothesis, ATT&CK technique, hunt date, finding (positive or true negative), detection rule created, SIEM rule ID, and engineer who owns it. After four quarters, review the register — which parts of your ATT&CK coverage are most heavily tested versus most lightly tested. That pattern is the input for your threat hunting roadmap the following year.

Where AI Fits — and Where It Does Not

In 2026, AI-assisted threat hunting tools have matured to where they are genuinely useful for the search and correlation phases of a hunt. AI-augmented SIEM platforms can run federated queries across multiple data sources simultaneously and surface prioritised anomalies for human review. What previously took a full day of analyst time can now take closer to an hour for data gathering.

✦ The practical 2026 model

Use your SIEM’s AI-assisted search to accelerate data gathering and anomaly surfacing in Phase 3. Keep hypothesis generation and final investigation in human hands — the hypothesis requires environmental knowledge of your specific cluster that no AI tool has without significant training on your specific data. This is AI making a non-dedicated threat hunter more effective, not AI replacing the hunter.

The Quarterly Hunt Calendar

Month 1 — Week 1
  • Select quarter’s hypothesis from CERT-In or FS-ISAC advisory
  • Validate required data exists in SIEM
  • Document hypothesis in hunt register
Month 1 — Week 2–3
  • Execute the hunt (4–8 hrs engineer time)
  • Write queries, run analysis, investigate anomalies
  • Document findings including true negatives
Month 1 — Week 4
  • Write detection rule (mandatory)
  • Add to detection engineering backlog
  • Write test case for the rule
Month 2–3
  • SIEM rule runs automatically
  • Review any alerts it fires
  • Refine rule if false positives emerge
  • Prepare next quarter’s hypothesis

This cadence is sustainable for one senior engineer dedicating one day per month to the programme. It produces four new detection rules per year and a documented history of what your environment has been searched for and what was found. That documentation is itself security programme maturity that compliance frameworks and auditors recognise.

Closing

Threat hunting without a threat hunter is not a compromise. It is an acknowledgement that proactive detection is within the reach of any engineering organisation that has logs, a SIEM, and one engineer who knows the environment. The constraint is not skill or tooling. It is discipline — the discipline to form a hypothesis instead of searching randomly, to time-box the hunt instead of letting it expand indefinitely, and to convert every finding into a detection rule that makes the programme smarter over time.

The attacker operating at 29-minute breakout speed is relying on the fact that most organisations never look for them until an alert fires. A quarterly hypothesis-driven hunt finds the threats that were already inside and waiting.

The hunt starts with a question: if an attacker were already in our environment right now, using the techniques most commonly observed against organisations like ours, what would we see in our logs? Start there. Write the query. Look at the results. The answer is either reassuring or actionable. Either way, it is more than most organisations currently have.