Microsoft SC-200: KQL for Threat Hunting

Kusto Query Language is one of the most practical skills on Microsoft SC-200 because threat hunting begins with questions that telemetry must answer. The current Microsoft SC-200 objectives explicitly include KQL and hunting across Microsoft Sentinel and connected security data. You do not need to become a database-language specialist, but you do need to read and build queries that narrow large datasets into evidence.

The strongest hunting queries are driven by a hypothesis. “Show me all events” is not a hunt. “Show me successful sign-ins from a new country followed by privilege-sensitive activity within thirty minutes” is a huntable question. KQL then becomes the language used to turn that question into filters, joins, summaries, time windows, and entity context. Before a hunting query becomes a production analytic rule, test it against normal activity and known incidents so that signal quality does not collapse under predictable false positives.

Start by choosing the table that contains the evidence

A query can be perfectly written and still fail to answer the question if it begins with the wrong dataset. Identity hunts need authentication or identity telemetry. Endpoint hunts need process, file, or network events. Sentinel environments can contain many tables, so first identify which source records the behavior you are investigating.

Then inspect available columns before writing complex logic. Time, account, device, IP address, process name, action, and result fields often provide the first useful filters. Hunting is faster when you understand the schema instead of guessing column names. A missing field may indicate that the relevant connector or data source is not being ingested.

Filter early to reduce noise

The where operator is fundamental because security datasets are large and most rows are irrelevant to a particular hypothesis. Restrict the time window, event type, result, account population, or suspicious value as early as practical. Early filtering improves readability and can reduce the amount of data later operators must process.

Filters should reflect the hypothesis, not merely make the result set small. Excluding all administrative tools because they are noisy can hide attacker abuse of those tools. A better filter may exclude a known automation account or approved management host while preserving the same behavior elsewhere.

Project only the fields needed for analysis

Security tables can contain dozens or hundreds of columns. project and extend help shape output into the fields that support reasoning. Showing timestamp, account, device, IP, action, and a few relevant details is often more useful than returning every property.

extend can also create derived values, normalize fields, or extract pieces used later in the query. Clear output matters during hunting because analysts frequently pivot from a query result into another investigation. A concise result set makes patterns easier to see and reduces the chance of overlooking the one field that explains the behavior.

Use summarize to find abnormal concentration

summarize turns events into patterns. Count failed sign-ins by user, distinct devices by account, process executions by host, or connections by destination. Large counts are not automatically malicious, but aggregation reveals outliers that are hard to see in raw event streams.

Time bins are especially useful. A hundred failures over six months may be normal; a hundred failures in two minutes may indicate password spraying or automation gone wrong. Grouping by both entity and time helps distinguish background noise from sudden concentration.

Join data only when the relationship adds meaning

Threats cross domains, which makes joins powerful. A hunt might connect sign-in data to endpoint activity, or an alert table to asset context. But joins can also create duplicates, large intermediate datasets, and confusing results when keys are not unique.

Before joining, decide the relationship you expect. Is one user record matching many events? Are you correlating on device ID, account, IP, or another stable identifier? A join based only on a display name can be unreliable if names change or repeat. The same reasoning that makes data-engineering joins correct also makes security correlations defensible.

Use time as part of the correlation

Attack sequences are temporal. A suspicious sign-in followed by process execution three days later may be unrelated; the same sequence within minutes is more interesting. KQL supports time comparisons and windows that help express this relationship. The analyst should define what “close enough to be connected” means for the hypothesis.

Chronology can also reveal cause and effect. If a security control changed before a spike in alerts, configuration may explain the pattern. If malicious process activity began before the risky sign-in, the identity event may be a consequence rather than the initial access. Reconstructing an attack lifecycle requires checking those relationships instead of assuming that alert order alone describes the attack.

Build reusable hunting queries around entities

Useful hunts often produce entity-focused output that analysts can pivot from: accounts, hosts, IPs, URLs, files, and processes. Queries become easier to reuse when variable values such as a time range, account name, or suspicious domain can be changed without rewriting the entire expression.

Reusable structure also helps teams standardize investigations. A query that identifies a suspicious device can feed a second query that searches the same device for related process activity. Over time, strong hunting queries may inform analytics rules or other detections after they are tested and tuned against normal behavior.

Validate a hunting hypothesis before operationalizing it

A hunt that returns interesting results is not automatically a good detection rule. First determine how often the pattern appears in benign activity, which exclusions are justified, and whether the relevant data arrives consistently. A query that works only because one analyst knows to ignore half the results is not ready for automation.

This is where threat hunting becomes detection engineering. Analysts can use historical data to test thresholds, entity mappings, and expected alert volume. Patterns of enterprise security threats suggest behaviors worth hunting, but local telemetry determines whether a query is precise enough for the organization.

String matching needs care because security indicators appear in inconsistent forms. Domains can vary by case or subdomain, file paths can contain user-specific prefixes, and command lines may include changing arguments. Functions that normalize case, parse components, or search for meaningful tokens can make a hunt more robust than exact full-string comparison.

KQL also supports reusable definitions and let statements that make longer hunts easier to read. Separating a list of suspicious indicators, a time boundary, or an intermediate result from the final query can reduce duplication and clarify intent. Readability matters during incident response because another analyst may need to modify the hunt under time pressure.

When queries are slow, reduce scope before adding complexity. Narrow the time range, select only required columns, filter early, and avoid large unconstrained joins. Performance is not merely convenience; a hunt that takes too long may be unusable during an active incident. Efficient queries let analysts iterate on hypotheses quickly.

Threat hunting should also produce a disposition. A query that finds an anomaly should lead to investigation, enrichment, or a documented benign explanation. Saving interesting queries without recording what they mean creates a library of curiosities rather than a hunting program. The value comes from closing the loop between hypothesis, evidence, and operational action.

Watch for dynamic fields and nested data. Security records sometimes store details in JSON-like structures that require parsing before useful attributes can be filtered or summarized. If the interesting value is buried inside a dynamic column, a query that ignores parsing may return broad records without exposing the exact indicator needed for the hunt.

Hunting queries should preserve enough context for investigation. A query that returns only an IP address may identify an outlier but force the analyst to rerun another query to learn the user, device, and time. Returning the minimum useful context makes handoff and pivoting faster while still keeping the result readable.

Finally, learn to interpret empty results correctly. No matches can mean the behavior is absent, the time window is wrong, the data source is missing, the field value is normalized differently, or the query logic is too restrictive. Validate data availability before concluding that a hunt found nothing suspicious.

Use comments and descriptive variable names in saved queries when the logic is not obvious. Hunting content becomes part of the team’s shared knowledge base, and a query that only its original author can understand is difficult to maintain. Clarity improves both peer review and incident-time reuse.

That makes the hunting library easier to trust.

It also improves peer review.

Read KQL questions by predicting the result shape

On SC-200, ask what the query should return before focusing on syntax. Does the scenario need raw events, one row per user, a count by device, the latest event per entity, or correlated records from two tables? Once the result shape is clear, the required operators become easier to identify.

Also watch for queries that are syntactically plausible but logically wrong: grouping by too many fields, joining on an unstable key, omitting a time filter, or counting rows when distinct entities are required. KQL is most powerful when it expresses a precise security question. Exam success follows the same rule: understand the question first, then choose the operators that produce the evidence needed to answer it.