# Microsoft Sentinel KQL & Analytics Rules — Hunting, Detections, MITRE Mapping & UEBA Source: https://ai.techclick.in/blog_microsoft_sentinel_kql_analytics Markdown: https://ai.techclick.in/blog_microsoft_sentinel_kql_analytics.md Publisher: Techclick Infosec Pvt Ltd A clear, interactive guide to detection and hunting in Microsoft Sentinel (2026): KQL basics for security queries (where, project, summarize, join, parse, bin), the four analytics rule types (scheduled, NRT, Microsoft security, anomaly/ML), how a rule turns matches into alerts and incidents, entity mapping, MITRE ATT&CK tactics, watchlists, hunting queries, bookmarks and UEBA. Microsoft Sentinel KQL & Analytics Rules — Hunting, Detections, MITRE Mapping & UEBA student learning map A visual study map for Microsoft Sentinel KQL & Analytics Rules — Hunting, Detections, MITRE Mapping & UEBA showing learning path, evidence, traps, and practice sequence. TECHCLICK STUDY MAP Microsoft Sentinel KQL & Analytics Rules —... Microsoft · learn the flow, prove with evidence, avoid unsafe shortcuts 1. Start 🎯 By the end you will be able to 2. Understand Pick where you want to start 3. Prove ① KQL basics — the language you... 4. Practice ② Analytics rule types — turning a... How to use this page First build the mental model, then connect the concept to a realistic production decision. Finish by testing yourself. Techclick Infosec Pvt Ltd | ai.techclick.in | Training Contact: WhatsApp +91 92772 29456 Content-specific feature visual for this lesson: use it as the 60-second map before reading the full detail. Most learners think… Most people think 'Sentinel detection' means downloading a pile of ready-made rules and switching them on. That gets you noise, not security — and it falls apart the moment an interviewer asks you to write a detection. Real detection is a skill stack : KQL is the language you query logs with, an analytics rule is the schedule + threshold that turns a query into alerts , entity mapping and MITRE ATT&CK turn those alerts into an investigable incident , and hunting plus UEBA catch what no rule wrote yet. Understand that chain and you can build a detection, tune it, and explain scheduled vs NRT without blinking. ## ① KQL basics — the language you detect with Every Sentinel detection starts as a KQL query against a table of logs (for example SigninLogs or SecurityEvent ). KQL reads top-to-bottom and you chain steps with the pipe | . Six operators cover most security work. where filters rows; project picks columns; summarize aggregates (count failures per user); and join correlates two tables (sign-ins with risky IPs). ### Two more you will use daily parse pulls fields out of a messy string column, and bin() rounds timestamps into buckets so you can count events per 5-minute or 1-hour window. A classic brute-force detection is just: filter to failed sign-ins, summarize the count by user and bin(TimeGenerated, 1h), then where that count > 10. That single query is a detection waiting for a rule. Figure 1 — A KQL detection, step by step Most security detections are a short pipeline: filter, pick columns, aggregate, then threshold. - A KQL detection, step by step Table SigninLogs etc. where filter rows summarize count by user/bin where count > threshold Result suspicious rows Most security detections are a short pipeline: filter, pick columns, aggregate, then threshold. Filter early, project late Put your where clauses as high in the pipeline as possible so KQL throws away rows before doing expensive work, and use project (or summarize) to keep only the columns you actually need. A tight query is both faster and cheaper — Sentinel bills on data scanned. Quick check · Q1 of 10 · Apply You want failed sign-ins counted per user per hour. Which KQL fragment fits? a) where Result == 'Success' b) project User, Time only c) summarize count() by User, bin(TimeGenerated, 1h) d) join the table to itself Correct: c. summarize aggregates rows; bin(TimeGenerated, 1h) buckets the timestamp into one-hour windows, so you get a count of failures per user per hour — the backbone of a brute-force detection. 👉 So far: KQL detection = table | where (filter) | summarize count() by user, bin(time) | where count > threshold. Add project to trim columns, join to correlate, parse to extract fields. ## ② Analytics rule types — turning a query into detections A query only detects when it lives inside an analytics rule . Sentinel has four main types. A Scheduled rule is by far the most common: it runs your KQL on a timer (interval and lookback are both configurable from 5 minutes to 14 days ) and raises an alert when results pass a threshold. A NRT (near-real-time) rule is a limited scheduled rule hard-coded to run every minute for the fastest detection, with a short two-minute delay; it always alerts (no threshold) and is capped at 50 enabled rules . ### The other two Microsoft security rules don't run KQL — they turn alerts from Microsoft Defender products into Sentinel incidents automatically. Anomaly / ML rules use machine learning to baseline behaviour and flag outliers; anomaly rules write to the Anomalies table rather than raising their own alerts, so you use them as enrichment. The interview line: scheduled = flexible timer with a threshold; NRT = every minute, always fires, fewer features. Figure 2 — Scheduled vs NRT analytics rules Same wizard, different engine: scheduled gives flexibility, NRT gives speed. Scheduled vs NRT analytics rules Scheduled rule Runs on a timer (5 min–14 days) Configurable threshold Full feature set Up to 512 enabled rules NRT rule Runs every minute Always alerts (no threshold) Two-minute delay, fewer options Max 50 enabled rules Same wizard, different engine: scheduled gives flexibility, NRT gives speed. Figure 3 — The four analytics rule types Sentinel's main rule types, from KQL-driven detections to ML baselines. The four analytics rule types Scheduled KQL on a timer with a threshold NRT KQL every minute, always fires Microsoft security Defender alerts to incidents Anomaly / ML baseline behaviour, flag outliers Sentinel's main rule types, from KQL-driven detections to ML baselines. 🔎 summarize tap to flip The aggregation workhorse — count(), dcount(), make_list() grouped by columns and bin(time). Most detections end in a summarize + where threshold. ⏱️ Scheduled rule tap to flip KQL on a configurable timer (5 min–14 days) with a result threshold. The default, full-featured detection type — up to 512 enabled. ⚡ NRT rule tap to flip A scheduled rule pinned to run every minute with a two-minute delay. Always fires, fewer features, capped at 50 — use for time-critical detections. 🧩 Entity mapping tap to flip Maps query columns (user, host, IP) to Sentinel entities so alerts correlate across rules and build an investigation graph. Up to 10 per rule. 'Just turn on every rule template' Importing every analytics template and enabling it is how SOCs drown. Enable rules that match your data sources, start broad ones in a low-severity/monitoring posture, tune the threshold and entity mapping, then raise severity. An untuned rule with no aggregation is a false-positive machine. Quick check · Q2 of 10 · Understand What best describes an NRT rule versus a scheduled rule? a) NRT runs every minute and always alerts; scheduled runs on a configurable timer with a threshold b) NRT is slower but more flexible c) They are identical, just named differently d) NRT only works on Defender alerts Correct: a. NRT rules are hard-coded to run once a minute for speed and always raise an alert (no threshold), with fewer features. Scheduled rules run on a configurable 5-minute-to-14-day timer and fire only when results pass a threshold. 👉 So far: Four rule types: Scheduled (KQL on a 5-min–14-day timer with a threshold), NRT (every minute, always fires, max 50), Microsoft security (Defender alerts to incidents), Anomaly/ML (baseline + outliers, writes to Anomalies). ## ③ From match to incident — alerts, entities and MITRE When a rule's query returns matching rows, the rule raises an alert . Two enrichment steps decide whether that alert is useful. Entity mapping ties query columns to recognised entities — Account, Host, IP, URL, File hash — so the same user or IP can be correlated across different rules and data sources . You can map up to 10 entities per rule, each with up to three identifiers; stronger identifiers give better correlation. You also tag the rule with MITRE ATT&CK tactics and techniques, which flow into the incident and onto the coverage matrix so you can see gaps. Finally, alert grouping rolls related alerts into a single incident — the unit the SOC actually investigates. One tuned rule should produce one clear incident, not fifty duplicate alerts. Figure 4 — One alert, enriched every way Entity mapping and MITRE tags turn a raw match into an investigable, measurable incident. One alert, enriched every way Alert from a rule match Account entity Host entity IP entity MITRE tactic Incident group Custom details Entity mapping and MITRE tags turn a raw match into an investigable, measurable incident. Read the entities, not your gut Never close a Sentinel incident on a hunch. The incident shows the mapped entities (who, which host, which IP), the MITRE tactic, and the custom details from the query. That single read usually tells you if it is a true positive — no guessing required. ### ▶ Watch a brute-force attempt become a tuned incident How one KQL detection runs end-to-end. Press Play for the healthy path, then Break it to see the classic failure. ① Ingest Failed sign-in events stream into the SigninLogs table from Microsoft Entra ID. ▼ ② Query A scheduled rule runs KQL: summarize count() by Account, bin(TimeGenerated, 1h), where count > 10. ▼ ③ Alert + map The threshold is passed; the rule raises an alert and maps Account and IP entities plus the MITRE Credential Access tactic. ▼ ④ Incident Alert grouping rolls related alerts into one incident; the analyst sees the user, source IP and tactic on the graph. Press Play to step through the healthy detection path. Then press Break it . ▶ Play Next ▶ ⚠ Break it ↺ Reset Quick check · Q3 of 10 · Analyze Why does mapping a username column to the Account entity matter? a) It makes the query run faster b) It lets Sentinel correlate that user across rules/sources and build the incident graph c) It is required for KQL to compile d) It encrypts the username Correct: b. Entity mapping puts the user into the alert's entities field, so Sentinel can correlate the same Account across different rules and data sources and present an investigable incident graph. It is enrichment, not a query optimisation. 👉 So far: A match raises an alert; entity mapping (up to 10) and MITRE tags enrich it; alert grouping rolls related alerts into one investigable incident. Correlation comes from entities, not luck. ## ④ Hunting & UEBA — catching what no rule wrote Rules catch the known; hunting catches the suspected. The Hunting page ships KQL hunting queries grouped by MITRE tactic; you run them, sort by result spikes, and when a row looks bad you save it as a bookmark — it preserves the query, the row, your notes, and inherits the query's entity and MITRE mappings. Promote a serious bookmark straight to an incident. ### Watchlists and UEBA Watchlists are reference data (VIP accounts, terminated employees, known-bad IPs) you join into queries to enrich detections or suppress noise. UEBA (User and Entity Behavior Analytics) baselines normal behaviour per user and host and surfaces anomalies and rich entity pages; the 2026 UEBA behaviours layer even summarises raw logs into plain-language, MITRE-mapped behaviours. Together they turn a pile of logs into a story an analyst can read. Figure 5 — Hunting loop — hypothesis to incident Hunting is a repeatable loop: form a hypothesis, query, bookmark, and escalate when it is real. Hunting loop — hypothesis to incident Hypothesis from MITRE / UEBA Hunt query KQL over logs Bookmark save + annotate Escalate promote to incident Hunting is a repeatable loop: form a hypothesis, query, bookmark, and escalate when it is real. Vikram, a SOC analyst at a Pune fintech, faces this A new scheduled rule for failed logins fires hundreds of near-identical alerts an hour and the SOC queue is unusable. Likely cause The KQL has no aggregation — it alerts on every single failed-logon row — and no entity mapping, so alerts never group. Diagnosis Open the rule: the query is just a where filter with no summarize, the threshold is 0, and Account/IP are not mapped, so each event becomes its own alert. Sentinel ▸ Configuration ▸ Analytics ▸ (rule) ▸ Set rule logic Fix Rewrite to summarize count() by Account, bin(TimeGenerated, 1h); set the threshold to >10; map Account and IP entities; enable alert grouping so related alerts roll into one incident. Verify Re-run: instead of hundreds of alerts you get one incident per noisy account, with the user and source IP visible on the graph. Quick check · Q4 of 10 · Apply During a hunt you spot a suspicious sign-in row and want to keep it for the investigation. What do you do? a) Delete the log b) Turn it into an NRT rule immediately c) Email the raw row to the SOC d) Add a bookmark, then escalate it to an incident if it is serious Correct: d. Bookmarks preserve the query, the row, your notes and the entity/MITRE mappings. If the finding is severe enough you promote the bookmark to an incident and investigate it like any other. 👉 So far: Hunting queries (grouped by MITRE) + bookmarks find what no rule wrote; watchlists enrich/suppress; UEBA baselines behaviour and the 2026 behaviours layer narrates raw logs in plain language. ### 🤖 Ask the AI Tutor Tap any question — instant, scoped to this lesson. No login, no waiting. What are the core KQL operators for a security detection? What is the difference between a scheduled rule and an NRT rule? What do Microsoft security and anomaly rules do? How does a query match become an incident? What are hunting queries and bookmarks for? What do watchlists and UEBA add to detection? Pre-curated from vendor docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in. ## 📝 Wrap-up assessment — six more You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end. Q5 · Remember Which KQL operator selects, renames or computes the columns to keep? a) where b) project c) summarize d) join Correct: b. project chooses, renames, drops or computes columns. where filters rows, summarize aggregates, and join merges two tables on matching keys. Q6 · Understand An anomaly analytics rule primarily… a) Runs KQL every minute and always alerts b) Turns Defender alerts into incidents c) Baselines behaviour with ML and records outliers in the Anomalies table instead of raising its own alerts d) Blocks the user automatically Correct: c. Anomaly rules use machine learning to set a baseline and flag deviations. They don't raise their own alerts; they write detected anomalies to the Anomalies table, which you use to enrich and tune detections. Q7 · Apply You need detection on a critical log source as fast as possible, accepting fewer configuration options. Which rule type? a) A scheduled rule with a 14-day lookback b) A Microsoft security rule c) An NRT (near-real-time) rule d) An anomaly rule Correct: c. NRT rules run every minute with a two-minute delay for the fastest detection, at the cost of fewer features and a 50-rule cap. Scheduled rules are more flexible but slower; the other two are not KQL-on-a-fast-timer detections. Q8 · Analyze Why can the same compromised account be tracked across several different rules and data sources? a) Because every rule shares one query b) Because the data is unencrypted c) It cannot — each rule is isolated d) Because entity mapping puts that Account into each alert, so Sentinel correlates it across rules and sources Correct: d. Entity mapping adds recognised entities (like Account or IP) to each alert. Sentinel correlates those entities across different rules and data sources, which is what builds the investigation graph and rich entity context. Q9 · Evaluate What is the best reason to tag analytics rules with MITRE ATT&CK tactics and techniques? a) It carries tactics into incidents and onto the coverage matrix so you can see and close detection gaps b) It makes KQL run faster c) It is required for the rule to save d) It hides the rule from other analysts Correct: a. MITRE tags flow into incidents and into the MITRE coverage matrix, letting you measure which tactics and techniques you actually detect and where your gaps are. It is about coverage and investigation, not performance. Q10 · Evaluate A broad new scheduled rule is flooding the SOC with duplicate alerts. Best first fix? a) Disable all detection b) Delete the underlying logs c) Convert it to a Microsoft security rule d) Add aggregation (summarize + threshold), map entities, and enable alert grouping so one attack becomes one incident Correct: d. The flood comes from a query with no aggregation and no grouping. Summarize to a count with a sensible threshold, map entities so alerts correlate, and turn on alert grouping — now related alerts collapse into a single investigable incident. Submit all answers Try again Lesson complete — saved to your profile. Almost! You need 70% (7 of 10) — re-read the path that tripped you up and tap "Try again". ### 🧠 In your own words Type one line: why is Sentinel detection called 'KQL plus rules' rather than 'a list of alerts'? Then compare with the expert version. Compare with expert answer Expert version: Because the detection logic is a KQL query you author and tune, and the analytics rule is what gives that query a schedule, a threshold and an output. The query finds suspicious rows; the rule (scheduled or NRT) turns matches into alerts; entity mapping and MITRE tags enrich them; and alert grouping rolls them into one incident the SOC investigates. You don't ship a static list of alerts — you write detections, map their entities, measure coverage on the MITRE matrix, and back them with hunting and UEBA for everything the rules miss. ### 🗣 Teach a friend Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary. Generate my one-liner 📩 Quiz me on this in 7 days. Opt in and we'll email 3 micro-questions on Microsoft Sentinel at Day 1, Day 7 and Day 30 — spaced repetition is how this sticks. Un-tick any time. ### 📖 Glossary KQL (Kusto Query Language) The read-only query language for Sentinel logs; you pipe operators (where, project, summarize, join, parse, bin) to filter and aggregate data. summarize The KQL aggregation operator — count(), dcount(), make_list() grouped by columns and bin(time) — that turns raw rows into detections. Scheduled rule An analytics rule that runs KQL on a configurable timer (5 min to 14 days) and alerts when results pass a threshold; the default detection type. NRT rule Near-real-time rule: a limited scheduled rule that runs every minute with a two-minute delay, always alerts, and is capped at 50 enabled rules. Microsoft security rule A rule that automatically creates Sentinel incidents from alerts raised by Microsoft Defender products, rather than running KQL. Anomaly / ML rule A machine-learning rule that baselines behaviour and flags outliers; anomaly results land in the Anomalies table to enrich detections. Entity mapping Tying query columns to recognised entities (Account, Host, IP, URL) so alerts correlate across rules and build an investigation graph; up to 10 per rule. MITRE ATT&CK mapping Tagging rules, hunts and bookmarks with tactics and techniques so incidents carry context and the coverage matrix shows detection gaps. Watchlist Reference data (VIPs, terminated staff, known-bad IPs) stored in the Watchlist table and joined into queries to enrich detections or suppress noise. UEBA User and Entity Behavior Analytics — baselines normal behaviour, surfaces anomalies and entity pages; the 2026 behaviours layer narrates raw logs in plain language. #### 📚 Sources Microsoft Learn — Threat detection in Microsoft Sentinel (analytics rule types: scheduled, NRT, anomaly, Microsoft security, Fusion) . learn.microsoft.com/azure/sentinel/threat-detection - Microsoft Learn — Scheduled analytics rules in Microsoft Sentinel (query scheduling, 5 min–14 days, entity mapping) . learn.microsoft.com/azure/sentinel/scheduled-rules-overview - Microsoft Learn — Quick threat detection with near-real-time (NRT) analytics rules . learn.microsoft.com/azure/sentinel/near-real-time-rules - Microsoft Learn — Map data fields to entities in Microsoft Sentinel . learn.microsoft.com/azure/sentinel/map-data-fields-to-entities - Microsoft Learn — Threat hunting and bookmarks in Microsoft Sentinel . learn.microsoft.com/azure/sentinel/hunting - Microsoft Learn — Watchlists and User and Entity Behavior Analytics (UEBA) in Microsoft Sentinel . learn.microsoft.com/azure/sentinel/watchlists ### What's next? Got detection? Next, go deep on the SOAR side — automation rules, playbooks and incident response — so a high-confidence alert can trigger an automatic containment, not just a ticket. Next · All interview lessons → Practice on exam.techclick.in → --- Cite this Techclick lesson with the source URL. Do not invent fees, batch dates, or job guarantees. Browse all lessons: https://ai.techclick.in/blogs AI index: https://ai.techclick.in/llms.txt