Manual Threat Hunting Queries: A Practical Guide

Manual threat hunting queries are one of the most powerful tools a security team can use to find attackers before they cause damage. Instead of waiting for an alert to fire, threat hunters write custom searches that dig through raw log data, endpoint activity, and cloud events — looking for signs that something is wrong before it becomes a crisis.

This guide breaks down how manual threat hunting queries work, which languages and platforms you’ll use, and how to build a practical hunting process even if your team is small. Whether you’re a business owner trying to understand what your security team does or an analyst looking for a structured approach, you’ll walk away with a clear, usable framework.

What Are Manual Threat Hunting Queries?

A manual threat hunting query is a custom search written by a human analyst to actively look for hidden threats inside a network or system. These aren’t automated alerts — they’re deliberate investigations launched before any alarm goes off.

Think of it like this: automated security tools are smoke detectors. They sound an alarm when they recognize something they’ve seen before. Manual threat hunting queries are more like a detective walking through the building, looking for signs that something is off even when the alarms are silent.

The queries themselves are written in specialized query languages designed for searching large volumes of log and event data. The most common are:

• KQL (Kusto Query Language) — used in Microsoft Defender XDR and Azure Sentinel
• SPL (Splunk Search Processing Language) — used in Splunk’s SIEM platform
• SQL-based queries — used in various database-driven security tools and open-source platforms like ELK Stack

Human-driven investigation catches threats that signature-based tools miss because attackers constantly evolve. They modify malware, blend into normal traffic, and abuse legitimate tools — behaviors that don’t match any known signature. A skilled analyst writing targeted queries can spot those patterns by reasoning about what unusual looks like in a specific environment.

The foundation of this practice is hypothesis-driven hunting. Before writing a single query, the analyst forms a specific, testable assumption — for example, “An attacker may be using PowerShell to run commands quietly on our servers.” Every query then works to confirm or rule out that hypothesis using real data.

Core Query Languages and Platforms

Choosing the right platform shapes how you write manual threat hunting queries and what data you can access. The three dominant options each have distinct strengths.

KQL in Microsoft Defender XDR gives analysts access to up to 30 days of raw data from endpoints, identity systems, cloud apps, email, and Azure Sentinel. It’s expressive and readable, making it well-suited for complex multi-table queries. Defender offers two modes: a guided query builder for analysts less familiar with KQL syntax, and an advanced mode for writing custom KQL scripts from scratch. If you’re just getting started, the guided mode lets you build searches visually before graduating to full syntax.

SPL in Splunk is deeply flexible and widely used in enterprise security operations centers (SOCs). Splunk’s tstats command lets hunters summarize large volumes of metadata quickly — useful when you need to scan broad event categories without reading every individual log line. For a deeper look at how SIEM tools support security workflows, CISA’s SIEM resource page offers a solid reference point.

SQL-based tools and open-source platforms like ELK Stack (Elasticsearch, Logstash, Kibana) give smaller organizations a cost-effective entry point. These require more setup but offer strong flexibility for teams willing to invest in configuration.

Regardless of platform, you’ll pull data from four core source categories:

1. Endpoint data — process execution, file changes, registry modifications
2. Identity logs — login events, privilege escalation, account changes
3. Cloud app activity — SaaS usage patterns, API calls, data access
4. Network events — DNS queries, connection logs, traffic anomalies

One important practical note: Microsoft Defender enforces strict query limits. Results cap at 100,000 rows per query, queries time out after 10 minutes, and result sizes cannot exceed 64 MB. CPU resources are throttled based on your tenant’s available compute. Writing efficient, focused queries isn’t just good practice — it’s a requirement.

Threat Hunting Methodologies

No two threat hunts look exactly alike, but most fall into one of four structured approaches. Understanding each one helps you match your method to the threat you’re investigating.

Hypothesis-driven hunting is the most common starting point. The analyst forms a specific assumption about attacker behavior — “Lateral movement may be happening through remote desktop sessions” — then builds queries to test it. This keeps the hunt focused and measurable.

Intelligence-driven hunting uses external threat intelligence to guide the search. The MITRE ATT&CK framework is the gold standard here. It catalogs real-world attacker tactics, techniques, and procedures (TTPs) in a structured matrix. Hunters use it to map known adversary behavior — like a specific APT group’s preferred persistence technique — directly to queries targeting those patterns in their own logs.

Analytics-driven hunting starts with machine-generated anomalies. Tools using UEBA (User and Entity Behavior Analytics) assign risk scores to users and devices based on statistical baselines. When a user account suddenly accesses five new servers at 2 a.m., the system flags it. A threat hunter then writes manual queries to investigate that anomaly further — using the ML output as a lead, not a conclusion.

Situational-awareness hunting focuses attention on your organization’s most critical assets — often called crown jewels. These might be your finance servers, customer database, or intellectual property repositories. Because analyst time is finite, prioritizing these assets ensures the highest-value systems get the deepest scrutiny.

Many mature teams use hybrid methods that combine all of the above. A hunt might start with a MITRE ATT&CK technique, incorporate UEBA risk scores, pull in recent threat intelligence feeds, and layer in geopolitical context — for example, heightened scrutiny after a publicized attack campaign targeting your industry.

How to Write Effective Manual Threat Hunting Queries

Good queries don’t start with syntax — they start with a clear question. Before you open a query editor, define exactly what behavior you’re looking for and why it would be suspicious in your environment.

Step 1: Scope your hypothesis first. “Find anything weird” will produce nothing useful. “Find PowerShell executions initiated by non-administrative user accounts in the last seven days” gives you something to work with.

Step 2: Baseline normal behavior. You can’t spot an anomaly if you don’t know what normal looks like. Run broad, aggregated queries first to understand typical process counts, login volumes, or network connection patterns. Anomalies only stand out against that baseline.

Step 3: Balance specificity and coverage. Filters narrow your results and reduce noise. Wildcards and broader conditions help you catch variants you didn’t anticipate. Use both deliberately — not as an afterthought.

Step 4: Use aggregations to surface patterns. Raw event logs are too granular to read line by line. Functions like summarize, count(), and groupby compress thousands of events into meaningful patterns.

Here’s a concrete example. This KQL query hunts for suspicious PowerShell process chains in Microsoft Defender XDR:

DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName == "powershell.exe"
| summarize count() by InitiatingProcessFileName
| where count_ > 10

This query looks at seven days of process events, isolates PowerShell executions, and groups them by the parent process that launched them. If PowerShell is being spawned repeatedly by an unusual parent — say, a Word document or a scheduled task — that’s a strong signal worth investigating further. It’s a simple query, but it surfaces real behavior that attackers use regularly.

Hypothesis Development and Query Scoping

A hypothesis is only as good as the intelligence behind it. Strong starting points come from several reliable sources.

Threat intelligence feeds from vendors, government agencies like CISA’s Known Exploited Vulnerabilities catalog, and industry sharing groups (ISACs) regularly publish indicators and attacker behaviors. When a new vulnerability or active campaign is announced, it immediately suggests a hypothesis worth testing in your environment.

ML anomaly alerts from your SIEM or EDR platform generate leads automatically. These aren’t confirmations of compromise — they’re questions worth asking. Treat each anomaly as a potential hypothesis and write queries to explore it.

The PEAK framework (Prepare, Execute, Act with Knowledge) provides a structured guardrail for scoping hunts. It pushes analysts to define their scope, data sources, and success criteria before they start — preventing the hunt from sprawling into an unfocused data fishing expedition.

OSINT (Open Source Intelligence) and geopolitical context add another layer. If a ransomware group is actively targeting healthcare organizations in your region, you can write queries specifically tuned to that group’s known TTPs — even if you haven’t been attacked yet. That targeted approach is far more efficient than generic searches.

Always prioritize high-value assets when analyst time is limited. A well-scoped hunt on your five most critical servers is worth more than a broad, shallow sweep of your entire environment. Focus produces findings; breadth often produces noise.

Advanced Techniques: Automation, Playbooks, and Timelines

Manual threat hunting queries don’t have to stay manual forever. One of the most valuable outcomes of a successful hunt is converting what you found into an automated detection rule — so the next attacker who tries the same technique gets caught immediately.

In Microsoft Defender, you can promote a custom KQL query directly into a scheduled detection rule with customizable alert thresholds. In Splunk, saved searches can trigger alerts on the same logic. This creates a feedback loop where hunting continuously improves automated coverage.

Building a query playbook library is equally important. Every successful hunt should be documented with the original hypothesis, the queries used, the data sources accessed, and the findings. Over time, these playbooks become institutional knowledge — a library of proven searches your team can reuse and adapt instead of rebuilding from scratch every time.

Visual timeline correlation takes the output of raw queries and maps it into a chronological view of events tied to a specific user, device, or process. Tools like Exabeam do this automatically, connecting related events across log sources into a readable investigation timeline. Entity relationship mapping — visualizing how a compromised account connected to which servers and triggered which processes — turns complex query output into actionable investigative direction.

ML-generated leads work best as starting coordinates, not destinations. Let the algorithm surface the anomaly; let the human analyst write the queries that determine what actually happened. That combination consistently outperforms either approach alone. You can learn more about cybersecurity tools for small business that support this kind of integrated workflow.

Common Mistakes to Avoid When Writing Manual Threat Hunting Queries

Even experienced analysts run into the same pitfalls. Knowing them in advance saves significant time and frustration.

Writing queries that are too broad is the most common problem. A query that returns 90,000 rows tells you almost nothing. Data overload obscures real signals just as effectively as not searching at all. Always apply at least one meaningful filter before running a production query.

Skipping the baselining step makes false positives inevitable. If you don’t know that your backup software legitimately spawns 200 PowerShell processes every night, you’ll waste hours investigating routine automation. Establish your normal baseline before you hunt for abnormal.

Ignoring query performance limits wastes analyst time directly. A query that times out after 10 minutes — or locks up your SIEM with an unoptimized scan — produces nothing except frustration. Test queries on small time windows before expanding scope. Use indexed fields and aggregations early in the query to reduce the data set before applying complex filters.

Failing to document queries and findings is an organizational mistake as much as a technical one. If your best analyst writes a brilliant hunting query and doesn’t record it anywhere, that knowledge walks out the door with them. Every hunt, successful or not, should be logged. Even null results — hunts that found nothing — are valuable because they confirm the absence of a specific threat pattern.

For small businesses building a security program from the ground up, reviewing a small business cybersecurity checklist alongside your hunting practice helps ensure the fundamentals are covered before you invest in advanced techniques.

Frequently Asked Questions

Start Hunting Before the Incident Happens

The single biggest advantage of manual threat hunting queries is timing. By the time an automated alert fires, an attacker may have already been in your environment for days — or weeks. Proactive hunting closes that gap by going looking before there’s a crisis to respond to.

You don’t need a massive security team to get started. Even a small operation can run meaningful hunts by starting with focused hypotheses, targeting their most critical assets, and building a simple playbook of reusable queries. The tools exist. The frameworks exist. What it takes is a decision to stop waiting and start looking.

Build your first hypothesis. Write your first query. Document what you find. Then do it again next month — a little smarter, a little faster, with a little more institutional knowledge behind you. That compounding effort is what separates organizations that find attackers from organizations that get found by them.