1.5. Kusto Query Language Foundations
💡 First Principle: Every Microsoft security data store, from Defender XDR advanced hunting to Sentinel workspaces and the data lake, answers questions written in Kusto Query Language (KQL). KQL is built for exploring large volumes of log data quickly: data flows through a pipeline of operators, each one narrowing, reshaping, or aggregating what the previous one produced. Learn to think in pipelines and you can read and write the queries behind detections, investigations, and hunts.
Why care: KQL is not only a hunting skill. Custom detection rules and Sentinel analytics rules are KQL queries. Workbooks are KQL queries rendered as charts. Summary rules and KQL jobs run KQL in the background. Hotspot items often show a partial query and ask you to pick the operator or table that completes it. A fifth of the exam is threat hunting, and KQL threads through the other four-fifths too.
The mental model is an assembly line. Raw rows enter at one end; each station (operator) does one job: discard rows that don't qualify, add a calculated column, keep only certain columns, or group and count. What leaves the last station is your answer. The order of stations matters, because each one only sees what the previous station passed along.
⚠️ Common Misconception: "KQL is SQL, so clause order doesn't matter." KQL executes left to right through the pipe, so filtering early makes everything after it faster, and an operator placed after a summarize sees only the summarized columns. A second trap: assuming string operators all behave alike. == is case-sensitive, =~ is case-insensitive, and has (whole-term match) behaves differently from contains (substring match).
