Threat Hunting 101: Methodology: Finding Needles You Didn’t Know Existed

By Tech Corsair

There's a particular kind of optimism unique to cybersecurity: the belief that your perimeter defences caught everything. It's the same energy as assuming nobody touches the office biscuit tin when you're not looking. Spoiler: they do. Every time.

Threat hunting exists because that optimism is, statistically speaking, misplaced. While your SIEM dutifully fires alerts about failed SSH logins and someone trying admin/admin on the VPN portal for the nine hundredth time, the genuinely dangerous adversary slipped in three weeks ago via a compromised supplier and has been living off the land ever since. Your IDS didn't notice because the attacker used PowerShell and SMB -- tools your own sysadmins use daily.

Welcome to threat hunting: the discipline of proactively looking for threats that your automated defences missed. It's analyst-driven, hypothesis-based, and operates on a single foundational assumption -- you are already compromised; you just haven't found it yet.

Cheerful stuff. Let's crack on.

What Threat Hunting Actually Is (and Isn't)

Threat hunting is not scrolling through a SIEM dashboard waiting for something to turn red. That's monitoring. It's not incident response either -- by the time IR kicks in, someone's already found the fire. Hunting is the bit where you wander through the building sniffing for smoke before the alarm goes off.

More precisely, threat hunting is:

• Proactive -- initiated by the analyst, not triggered by an alert
• Hypothesis-driven -- starts with "what if?" rather than "what happened?"
• Iterative -- each hunt informs the next
• Human-led -- automation supports the hunt but doesn't drive it

The goal isn't necessarily to find an active intrusion (though that's always a memorable day). The goal is to reduce dwell time -- the gap between initial compromise and detection. The industry average hovers around 200+ days depending on which vendor report one reads, which is roughly the time it takes to binge every Star Trek series including the questionable ones.

Four Approaches to Threat Hunting

Not all hunts are created equal. There are four primary approaches, and a mature hunting programme will use all of them depending on context.

1. Hypothesis-Driven Hunting

The classic. Start with a hypothesis based on threat intelligence, industry trends, or sheer professional paranoia:

> "APT groups targeting our sector have been using DLL sideloading via legitimate signed binaries. What if that's happening in our environment?"

Then go look. Query the EDR for unsigned DLLs loaded by signed executables. Check for DLLs in unusual directories. Cross-reference with known sideloading targets like vmnat.exe or colorcpl.exe.

This approach requires threat intelligence awareness and a solid understanding of attacker tradecraft. It's the most intellectually satisfying hunt type, which is why analysts gravitate towards it and managers struggle to put it on a Gantt chart.

2. Baseline/Anomaly-Driven Hunting

Establish what "normal" looks like, then hunt for deviations. This requires decent telemetry and, critically, the patience to actually build baselines before declaring everything anomalous.

Examples:

• A service account suddenly authenticating interactively
• DNS queries to domains registered yesterday
• PowerShell execution on a server that's never run PowerShell before
• Outbound connections at 3 AM from a workstation in a timezone where 3 AM is definitively not working hours

The danger here is false positives. Anomaly hunting without good baselines produces noise, and noise produces analysts who quietly update their LinkedIn profiles.

3. Intel-Driven Hunting

Start with specific indicators or TTPs from threat intelligence feeds, ISACs, government advisories, or that alarming blog post doing the rounds on InfoSec Twitter (or whatever we're calling it this week).

Got fresh IOCs from a CISA advisory? Sweep the environment. New YARA rule for a commodity loader? Run it across your estate. APT group known to target your sector just got a new write-up? Map their TTPs to your telemetry.

This is the most reactive of the hunting approaches -- it's still proactive relative to waiting for an alert, but it's driven by external intelligence rather than internal hypotheses.

4. Situational/Environmental Hunting

Triggered by changes in the environment or threat landscape:

• Major vulnerability disclosure (the next Log4Shell is always just around the corner)
• M&A activity bringing in unknown infrastructure
• Geopolitical events increasing threat actor activity
• New cloud services deployed without security review (it happens more than anyone admits)

This approach is about context awareness -- understanding that the threat landscape shifts and hunting priorities should shift with it.

The Hunting Loop

Threat hunting isn't a one-off activity. It follows an iterative loop, and each cycle should leave the organisation marginally less likely to be caught with its trousers down.

Step 1: Hypothesis

Formulate a testable hypothesis. "Bad things might happen" is not a hypothesis. "Attackers may be using scheduled tasks for persistence on domain controllers" is.

Good hypotheses are:

• Specific enough to investigate
• Testable with available data
• Relevant to the current threat landscape
• Documented before the hunt begins (this matters more than people think)

Step 2: Investigate

Query your data sources. Build searches. Pivot on findings. This is where the analyst earns their keep, manually working through data that automated tools haven't flagged.

# Example: Hunting for suspicious scheduled tasks on Windows
# Look for tasks created via command line rather than GUI
index=windows EventCode=4698
| where NOT match(TaskContent, "Microsoft")
| stats count by ComputerName, SubjectUserName, TaskName
| where count < 3

Step 3: Enrich

Found something interesting? Don't stop at the first indicator. Enrich with additional context:

• Threat intelligence lookups on IPs, domains, hashes
• Historical correlation -- has this activity been seen before?
• Scope assessment -- is this one endpoint or fifty?
• ATT&CK mapping -- where does this sit in the kill chain?

Step 4: Report

Document everything. Everything. Even -- especially -- when you find nothing.

A hunt that finds no evidence of compromise is still valuable if it can demonstrate:

• What was tested
• What data sources were queried
• What the coverage gaps are
• What the confidence level is

This is threat hunting's great existential truth: finding nothing is still a success, as long as you document why. It's the only job where "I looked everywhere and found absolutely nothing" is a legitimate deliverable. Try that in any other profession and see how the performance review goes.

Step 5: Operationalize

The most important and most frequently skipped step. Take hunting findings and turn them into:

• New detection rules -- if you found something manually, automate detecting it
• Updated baselines -- refine what "normal" looks like
• Playbook updates -- feed findings back into IR procedures
• New hypotheses -- each hunt should generate questions for the next

A hunt that doesn't operationalize its findings is just expensive tourism through your own logs.

Data Sources: Where to Hunt

A hunter is only as good as their data. Here's the essential toolkit:

The single biggest obstacle to effective threat hunting isn't skill -- it's data availability. Can't hunt for lateral movement if nobody's logging authentication events. Can't find beaconing if there's no network flow data. Invest in logging before investing in hunting tools.

The Hunting Maturity Model

David Bianco's Hunting Maturity Model (HMM) provides a framework for assessing an organisation's hunting capability. It runs from HM0 to HM4, and most organisations are considerably lower on the scale than they'd like to admit at conferences.

HM0 -- Initial

No hunting capability. Reliant entirely on automated alerting. The organisational equivalent of leaving the front door open and hoping for the best.

HM1 -- Minimal

Can search for indicators (hashes, IPs, domains) provided by external sources. Essentially reactive IOC sweeping. Better than nothing, but only just.

HM2 -- Procedural

Can follow documented hunting procedures created by others. Knows which buttons to press but may not fully understand why. The "following a recipe" stage of threat hunting.

HM3 -- Innovative

Can create new hunting procedures and hypotheses. Understands attacker tradecraft well enough to anticipate techniques. This is where hunting starts to genuinely reduce risk rather than tick a compliance box.

HM4 -- Leading

Automates successful hunts into detection rules. Hunting findings drive security architecture decisions. The hunting programme feeds directly into organisational risk management. This is the promised land, and very few organisations actually live here despite what their slide decks claim.

The honest self-assessment is: most organisations sit between HM1 and HM2. Getting to HM3 requires investment in people and data, not tools. No amount of expensive software compensates for analysts who can't formulate a hypothesis.

Common Hunts by ATT&CK Tactic

Here's a practical starting point -- common hunts mapped to MITRE ATT&CK tactics, for those wanting to move beyond "we checked the IOCs from that PDF."

Initial Access (TA0001)

• Hunt for phishing payload execution patterns (Office spawning cmd/PowerShell/wscript)
• Search for exploitation artefacts from public-facing applications
• Look for VPN authentications from unusual geolocations

Execution (TA0002)

• PowerShell with encoded commands (-enc, -EncodedCommand)
• mshta.exe, wscript.exe, or cscript.exe executing from user-writable directories
• WMI-based remote execution across multiple hosts

Persistence (TA0003)

• New scheduled tasks or services on critical servers
• Registry run key modifications outside software deployment windows
• Startup folder additions on endpoints

Defence Evasion (TA0005)

• Process injection indicators (cross-process memory writes)
• Signed binary proxy execution (LOLBins like rundll32, regsvr32, certutil)
• Timestomping detection via $MFT analysis versus $STANDARD_INFORMATION

Lateral Movement (TA0008)

• SMB connections from workstations to other workstations (peer-to-peer is unusual in most environments)
• PsExec or remote service creation patterns
• RDP sessions from non-admin accounts or outside business hours

Command and Control (TA0011)

• DNS beaconing -- regular interval queries to low-reputation domains
• HTTP/S connections with consistent intervals and jitter patterns
• Connections to cloud services (Slack, Discord, Telegram) from servers that shouldn't use them

Exfiltration (TA0010)

• Unusual outbound data volumes, particularly to cloud storage providers
• DNS tunnelling indicators (high-entropy subdomain queries, TXT record abuse)
• Archive creation (.zip, .rar, .7z) followed by outbound transfers

Getting Started

For those staring at this and wondering where to begin, here's the pragmatic advice:

1. Start with your data. Audit what logging you actually have, not what you think you have. The number of organisations that discover their DNS logging was silently broken three months ago is distressingly high.
1. Pick three hunts. Don't try to boil the ocean. Choose three hypotheses relevant to your threat landscape and run them properly.
1. Document obsessively. A hunt without documentation is just someone browsing logs. Write up what you searched for, what you found (or didn't), and what you'd do differently.
1. Operationalize findings. Every successful hunt should produce at least one new detection rule. Otherwise you'll hunt for the same thing again next quarter and wonder why this feels familiar.
1. Iterate. The first hunt will be rough. The tenth will be considerably better. The hundredth will occasionally find something genuinely terrifying that justifies the entire programme.

Final Thoughts

Threat hunting is fundamentally about refusing to trust your own defences. It's institutionalised paranoia with a methodology, and in a landscape where the average dwell time still measures in months, that paranoia is entirely justified.

The best threat hunters combine technical depth with creative thinking -- they can write a Splunk query and also wonder "what would I do if I'd compromised this environment?" It's equal parts engineering and imagination, supported by good data and better documentation.

And remember: a hunt that finds nothing is still a successful hunt. It means either the adversary wasn't there, or they were better than you. Document which one you think it was, and plan the next hunt accordingly.

Happy hunting. Mind the needles.

---

Tech Corsair -- navigating the digital seas so you don't have to.