Article • November 1, 2026 • 5 minute read

Microsoft Sentinel - Kusto Query Language Fundamentals

Every investigation in Microsoft Sentinel eventually comes down to a query, and a blank query window feels slow when leaders want answers within minutes. This article shows how analysts read and write Kusto Query Language: start from the right table, filter rows, pick columns, summarize results, and adapt a saved query so a security team can answer fast under pressure.

Summary

Kusto Query Language, or KQL, is how analysts ask Microsoft Sentinel questions. A query starts with a table and passes its rows through a chain of operators that each shape what comes next. This article covers how to read that chain, the three moves of filtering, projecting, and summarizing, the habits that keep queries fast, and where to run them.

A Question Under Pressure

We will use A.M Finances Group as our business example. On a Tuesday afternoon, the security manager asked the analyst on shift one question: is anyone hammering our loan officers' accounts today, and did anyone get in? The sign-in table held 4.2 million rows. The answer was in there. The trouble was reaching it before a leadership briefing that started in twenty minutes.

Microsoft Sentinel stores its logs in tables, and Kusto Query Language is how an analyst reads them. A good query does not need to be clever. It needs to be a clear question, asked in the right order, against the right table.

*Figure 1. One table, three moves: filter the rows, pick the columns, summarize the groups.*

Read the Pipeline

A KQL query starts with a table name, then passes the rows through a series of steps, and each step begins with a pipe character. Microsoft puts it plainly: each operator transforms the data in order, so the order of the operators matters. Place the operator that picks the top results ahead of the one that filters, and you get a different answer.

The analyst began with the sign-in table, kept only the last day, kept only the failures, counted failures for each account and address, and asked for the top five. Five short steps, read from top to bottom, turned millions of rows into five. Reading a saved query works the same way. Find the table, then follow the pipes one step at a time. Comment lines that start with two slashes explain the intent, which is why they belong in any query you save and share.

Filter, Project, Summarize

Three operators do most of the work. The where operator filters, keeping only the rows that match a condition. The project operator picks columns, so the results show only what you need. The summarize operator groups rows and combines each group into a single row, such as a count of failed sign-ins for each account. A few helpers sit around them: take returns a small sample, sort and top rank the rows, and extend adds a calculated column.

Time filters use the ago function, which counts back from now. At A.M Finances Group, keeping the last day and the failed sign-ins cut 4.2 million rows to a few thousand. Summarizing by account and address then collapsed those into a short ranked list. Three accounts, all failing from one address, sat at the top.

Keep It Fast

A few habits keep queries quick and results trustworthy. Microsoft's guidance is to apply the time filter first, because Kusto indexes datetime columns and can skip data it does not need to read. Put the where operator right after the table, and project only the columns you need. Prefer the has operator to contains when you are matching a whole term, because has does not search for substrings. Look in a specific column rather than searching every column with a wildcard.

Two more habits prevent surprises. When a table is unfamiliar, put take at the start of the query to preview a small sample, then remove it once the logic is right. And remember that table and column names are case sensitive, so SigninLogs is not the same name as signinlogs. Time filters also run in UTC, whatever time zone your portal displays. A tidy query is easier for the next analyst to read and reuse.

Adapt It, Then Run It

Analysts rarely write from a blank page. Once the first query had found three accounts failing from one address, the analyst adapted it in three edits. The filter changed from failures to successes, a second filter named the suspicious address, and a project step replaced the summary so the results listed who signed in and to which app. One account had signed in after the failures. It went to the incident queue with the query attached.

In the Microsoft Defender portal, you run KQL in advanced hunting, under Investigation and response, then Hunting. Once a Sentinel workspace is connected, its tables appear after the Defender tables in the schema pane. Sentinel tables use the TimeGenerated column and Defender tables use Timestamp, so check which one a table has. Security Copilot can draft KQL from plain language, and you should review that query before you run it. Plan around one date: after March 31, 2027, Microsoft Sentinel is supported only in the Defender portal.

Conclusion

KQL turns a long table into a short answer. Start from the table, filter early, project what you need, and summarize into groups. Read every query as a pipeline, keep it fast with a time filter first, and adapt saved queries instead of starting over. A.M Finances Group went from 4.2 million rows to three attacked accounts and one that got in, with minutes to spare.