Threat hunting with Kusto Query Language (KQL) is a way to test security hypotheses directly against telemetry rather than waiting for an existing detection to generate an alert. In Microsoft’s unified security operations model, KQL appears across Microsoft Defender XDR advanced hunting and Microsoft Sentinel data, but the available tables, retention, and schema depend on the data source and portal context.<\/p>\n
The current Microsoft SC-200<\/a> objectives include hunting with KQL. The durable skill is not memorizing dozens of operators. It is knowing how to turn a hypothesis into a scoped query, preserve useful entities, validate results, and decide whether the pattern should become a detection or remain an investigative hunt.<\/p>\n Start with a question that can be proven or disproven with available telemetry. \u201cFind suspicious activity\u201d is too broad. \u201cFind users who launched PowerShell from Office applications and then contacted a rare external domain\u201d gives you entities, event types, sequence, and likely tables.<\/p>\n A useful hypothesis identifies the actor or asset, the behavior, the time range, and the reason it is suspicious. It also defines what benign explanations might exist. That prevents the hunt from becoming an endless sequence of filters until something visually interesting appears.<\/p>\n After the query returns results, interpret them against the hypothesis. A hunt is not successful merely because rows were found. The result should either strengthen the suspicion, falsify the theory, or reveal a better question for the next query.<\/p>\n Microsoft Defender XDR advanced hunting exposes security-focused tables such as device, identity, email, cloud-app, and alert data depending on licensed products and onboarding. Microsoft Sentinel adds workspace data, including analytics-tier data and connected sources, when integrated into the Defender portal.<\/p>\n The same KQL language can query both environments, but table names and fields are not interchangeable. A device event table in advanced hunting is not the same thing as an arbitrary Log Analytics custom table. Before adapting a query from documentation or another tenant, inspect the schema and confirm the required columns exist.<\/p>\n Microsoft’s advanced hunting documentation notes that Defender XDR raw data is generally available for up to 30 days, while Sentinel analytics-tier data follows the retention configured for the workspace. Time-range assumptions therefore affect what a query can prove.<\/p>\n Large hunting datasets reward disciplined scoping. Start with the narrowest reasonable time range and apply selective filters early. A query that scans an entire table and only filters at the end wastes resources and makes iterative hunting slower.<\/p>\n Use This approach improves both performance and reasoning. When the query evolves, you can explain why each filter exists and what evidence would disappear if it were removed.<\/p>\n Use Raw events are essential for validation, but aggregation often reveals behavior that single records cannot. The For example, authentication hunting may summarize failures and successes by account and source IP. Network hunting may count unique destinations per process. Email hunting may group recipients or sender domains. Endpoint hunting may find rare process-command-line combinations.<\/p>\n Aggregation should not erase context. After identifying an outlier, pivot back to the underlying events. A count of 500 connections is only suspicious after you know which process created them, which destinations were involved, and whether the pattern is expected for that system.<\/p>\n Operators such as KQL An endpoint hunt may connect a process event to a network event through device and process identifiers. An identity hunt may connect sign-in behavior to user risk or audit activity through account identifiers. The join should answer a question that neither table can answer alone.<\/p>\n Project only the columns needed for the relationship and consider pre-filtering each side. After joining, check whether one-to-many relationships duplicated rows and distorted counts. Correlation is powerful, but every join introduces assumptions about identity, timing, and cardinality that the hunter must validate.<\/p>\n The Readable KQL matters because hunts often become shared team assets. A query that only its author can understand is difficult to validate and dangerous to convert into a detection. Use meaningful variable names, comments, and clearly separated stages so another analyst can see the hypothesis and transformation path.<\/p>\nWrite a hypothesis before writing syntax<\/h2>\n
Understand which schema you are querying<\/h2>\n
Filter early and keep the time window explicit<\/h2>\n
where<\/code> for time, entity, event type, action, or other discriminators. Keep timestamps visible until you no longer need them. If the hunt begins from an incident, alert, user, device, file hash, IP address, or URL, use that known entity to seed the first query rather than searching everything.<\/p>\nproject<\/code> and project-away<\/code> to control which columns move through later stages. Security tables can contain many fields, and carrying every column through joins and summaries makes a hunt slower and harder to read. Preserve the identifiers, timestamps, and evidence required for the next step, then return to the source table if a final lead needs full forensic detail.<\/p>\nSummarize behavior instead of reading raw rows forever<\/h2>\n
summarize<\/code> operator can count events, identify distinct devices or destinations, calculate first and last seen times, or group activity by account, process, IP address, or other entity.<\/p>\ndcount<\/code>, make_set<\/code>, bin<\/code>, arg_max<\/code>, and percentiles can reveal behavior without manually reading thousands of records. Use them to answer a concrete question: how many unique destinations did this process contact, what was the latest event per device, or which account sits far outside its peers? Aggregation should reduce the search space while preserving a path back to the source evidence.<\/p>\nJoin only when the relationship improves the hunt<\/h2>\n
join<\/code> can connect evidence across tables, but it is easy to create slow or misleading queries by joining large datasets without a clear entity key and time relationship. Decide what relationship you need before reaching for the operator.<\/p>\nUse let statements to make complex hunts readable<\/h2>\n
let<\/code> statement can name values, lists, or intermediate tabular expressions. It is especially useful when a hunt has a known set of indicators, a baseline population, or several query stages that would otherwise be repeated.<\/p>\n