By Cyber Defense Technologies July 7, 2026 4 min read
Security tools generate alerts when activity matches known patterns. Skilled adversaries know this and work to stay below those thresholds, using legitimate tools, valid accounts and patient, quiet activity. Threat hunting is how organizations find them anyway.
A threat hunt starts from a simple premise: an attacker may already be in the environment, undetected. Hunters then search deliberately for evidence, rather than waiting for an alert.
Hypothesis-driven threat hunting
-
1 Hypothesize
Form a testable idea based on threat intelligence, such as "an actor is using netsh to proxy traffic."
-
2 Collect
Identify and gather the data needed: process, network, authentication and cloud logs.
-
3 Investigate
Search, analyze and pivot to confirm or refute the hypothesis.
-
4 Respond
Escalate true positives to incident response.
-
5 Improve
Turn findings into detections, logging improvements and new hypotheses.
Then the cycle repeats.
Hunting is not alert triage
Security operations center analysts respond to alerts. Hunters look for what did not generate an alert. The two are complementary: hunting finds gaps in detection, and those gaps become new alerts for the operations team.
The hypothesis-driven approach
The most effective hunts start with a hypothesis: a specific, testable statement about adversary behavior that might be present. Good hypotheses are:
- grounded in intelligence, such as techniques described in a recent advisory about actors targeting your sector
- specific, naming a technique and where it would appear
- testable with data you have, or can obtain
Examples:
- "An actor has extracted Active Directory credentials using ntdsutil on a domain controller."
- "A compromised account is being used to sign in from infrastructure associated with anonymizing services."
- "An attacker has configured netsh port forwarding on a server to proxy traffic."
- "A web shell has been placed on an internet-facing web server."
Using MITRE ATT&CK
MITRE ATT&CK catalogs adversary tactics and techniques observed in real intrusions. It helps hunters:
- choose techniques relevant to threat actors that target their sector
- understand how each technique appears in data
- track which techniques they have hunted for and which they can detect
- communicate findings consistently
Many organizations map their detection coverage against ATT&CK and use the gaps to plan hunts.
The data you need
Hunting is only as good as the data available. Core sources include:
- Endpoint telemetry: process creation with command lines, script logging, file and registry changes, network connections
- Authentication logs: domain controllers, identity providers, VPNs and cloud sign-ins
- Network data: flow records, DNS, proxy and firewall logs
- Cloud audit logs: administrative actions, API calls and configuration changes
- Email and collaboration logs: message traces, forwarding rules and sharing activity
Retention matters. Long-dwell intrusions may have started months ago; a few weeks of logs will not reveal them.
Running a hunt
- Define the hypothesis and the techniques involved.
- Identify the data needed and confirm it is available and complete.
- Search and analyze, starting broad and narrowing, pivoting on anything unusual: accounts, hosts, times and processes.
- Establish normal. Much of hunting is understanding legitimate activity well enough to recognize what does not fit.
- Escalate confirmed or suspected malicious activity to incident response immediately.
- Document what was searched, what was found and what could not be examined.
Turning hunts into lasting value
Every hunt should leave the organization stronger, whatever it finds:
- New detections: if a technique can be found by a query, automate it as an alert.
- Logging improvements: if the needed data was missing, fix the gap.
- Hardening: if a technique was possible because of a configuration weakness, fix it.
- Documented clean results: knowing a technique was hunted for and not found is valuable information.
- New hypotheses: findings often suggest the next hunt.
When to hunt
- after new advisories describe techniques relevant to your sector
- after a critical vulnerability in a system you run is disclosed and exploited in the wild
- after incidents, to confirm attackers have been fully removed
- on a regular schedule, cycling through high-priority techniques
- before and after major changes such as mergers or network redesigns
Frequently asked questions
Do we need a dedicated hunting team? Not necessarily. Many organizations start with analysts who spend part of their time hunting, or engage outside hunters periodically. What matters is protected time and good data.
What if we find nothing? That is a useful result, provided the hunt was well designed and the data was complete. Document it, and turn the queries into detections so the technique is covered going forward.
Is hunting only for large organizations? Organizations of any size facing capable adversaries benefit. The scope can be scaled to available data and staff.
Your first hunt
If you have never hunted before, start with one well-documented technique, such as unusual use of ntdsutil or netsh on servers. Confirm you collect process creation logs with command lines from domain controllers and servers, search for the technique over the last 90 days, and investigate every result until you understand it. Then write the query as a detection. That single cycle teaches most of what hunting requires.
How CDT can help
CDT's cyber hunt team runs intelligence-driven hunts based on the latest adversary techniques, turns findings into detections for managed security, and escalates to incident response when needed. Purple team exercises validate the resulting detections.