TTechclick ⚡ XP 0% All lessons
Microsoft · Cloud SIEM · SentinelInteractive · L1 / L2 / L3

Microsoft Sentinel KQL & Analytics Rules — Hunting, Detections, MITRE Mapping & UEBA

Microsoft Sentinel detection is one skill stack: write KQL to find suspicious activity, wrap that query in an analytics rule so it fires alerts, let those alerts roll up into incidents enriched with entities and MITRE tactics, and hunt for what no rule caught yet. This lesson takes you from a blank query window to a working detection — and lets you explain scheduled vs NRT rules in an interview.

📅 2026-06-19 · ⏱ 17 min · 5 infographics · live detection demo · 🏷 10-Q assessment + AI Tutor inline

⚡ Quick Answer

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.

🎯 By the end you will be able to

Read as:

Pick where you want to start

1

KQL basics

where, project, summarize, join, parse, bin.

 2

Rule types

Scheduled, NRT, Microsoft security, anomaly/ML.

 3

Match to incident

Alerts, entities, MITRE, grouping.

 4

Hunting & UEBA

Hunting queries, bookmarks, watchlists, UEBA.

🧠 Warm-up — 3 questions, no score

Just notice which ones make you pause. We answer all three inside the lesson.

1. Which KQL operator groups rows and counts or aggregates them?

Answered in KQL basics.

2. Which rule type runs about once a minute for fast detection?

Answered in Rule types.

3. What does mapping a username field to an Account entity buy you?

Answered in Match to incident.

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 stepTableSigninLogs etc.wherefilter rowssummarizecount by user/binwherecount > thresholdResultsuspicious 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?

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 rulesScheduled ruleRuns on a timer (5 min–14 days)Configurable thresholdFull feature setUp to 512 enabled rulesNRT ruleRuns every minuteAlways alerts (no threshold)Two-minute delay, fewer optionsMax 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 typesScheduledKQL on a timer with a thresholdNRTKQL every minute, always firesMicrosoft securityDefender alerts to incidentsAnomaly / MLbaseline 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?

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 wayAlertfrom a rule matchAccount entityHost entityIP entityMITRE tacticIncident groupCustom 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.

① IngestFailed sign-in events stream into the SigninLogs table from Microsoft Entra ID.
▼
② QueryA scheduled rule runs KQL: summarize count() by Account, bin(TimeGenerated, 1h), where count > 10.
▼
③ Alert + mapThe threshold is passed; the rule raises an alert and maps Account and IP entities plus the MITRE Credential Access tactic.
▼
④ IncidentAlert 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.
Quick check · Q3 of 10 · Analyze

Why does mapping a username column to the Account entity matter?

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 incidentHypothesisfrom MITRE / UEBAHunt queryKQL over logsBookmarksave + annotateEscalatepromote 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?

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.

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?

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…

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?

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?

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?

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?

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.
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.

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.

📖 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

  1. Microsoft Learn — Threat detection in Microsoft Sentinel (analytics rule types: scheduled, NRT, anomaly, Microsoft security, Fusion). learn.microsoft.com/azure/sentinel/threat-detection
  2. Microsoft Learn — Scheduled analytics rules in Microsoft Sentinel (query scheduling, 5 min–14 days, entity mapping). learn.microsoft.com/azure/sentinel/scheduled-rules-overview
  3. Microsoft Learn — Quick threat detection with near-real-time (NRT) analytics rules. learn.microsoft.com/azure/sentinel/near-real-time-rules
  4. Microsoft Learn — Map data fields to entities in Microsoft Sentinel. learn.microsoft.com/azure/sentinel/map-data-fields-to-entities
  5. Microsoft Learn — Threat hunting and bookmarks in Microsoft Sentinel. learn.microsoft.com/azure/sentinel/hunting
  6. 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 →