Purpose of This Lesson

Anomaly detection in Microsoft Sentinel helps identify behavior that deviates from an expected baseline, such as an unusual number of failed sign-ins. The key exam and operational distinction is that built-in anomaly records are not automatically alerts or incidents. Analysts normally correlate anomaly data with other signals before creating a detection or response workflow.

This lesson also shows how to create a custom near-real-time (NRT) analytics rule with KQL to detect activity that exceeds a defined threshold.

Key Concepts

Sentinel anomaly analytics

Microsoft Sentinel provides anomaly-focused analytics entries under Analytics > Anomalies. These rules can use data received through configured data connectors and may include UEBA-oriented detections such as:

• Anomalous password resets
• Anomalous code execution
• Domain reputation anomalies
• Other behavior that differs from an established pattern

An anomaly is stored in the Sentinel workspace’s Anomalies table. By itself, it does not generate an alert or incident. This makes anomaly data useful as a signal for correlation, threat detection, and investigation rather than as a complete response object.

Custom anomaly-style detection with KQL

A custom detection can use KQL to establish a simple baseline and identify activity above a multiplier of that baseline. The example in this lesson:

1. Defines a normal failed-login baseline.
2. Defines a threshold multiplier.
3. Searches Windows security events for failed logons.
4. Groups failures by account and one-hour time windows.
5. Filters groups whose count exceeds the calculated threshold.
6. Projects the time, account, count, and an anomaly indicator.

The lesson creates this as an NRT query rule. This is different from merely viewing or enabling a built-in anomaly rule: an analytics rule is configured to evaluate query results and can be configured with alert, entity mapping, incident, and automation settings.

Important terminology distinction

• Anomaly record: A behavior signal written to the Anomalies table; no alert or incident is generated directly.
• Analytics rule: A configured Sentinel detection that evaluates data and can create alerts or incidents according to its settings.
• NRT analytics rule: A query-based analytics rule intended to evaluate data with near-real-time timing.
• UEBA: User and entity behavior analytics that provides behavioral context and anomaly signals for users, accounts, hosts, and other entities.

Microsoft Security Operations Context

Anomaly detection is most effective as part of a layered SOC workflow:

1. Ingest data through the appropriate Sentinel data connectors.
2. Detect unusual behavior with built-in anomaly analytics, UEBA signals, or custom KQL.
3. Correlate signals with identity, endpoint, network, and cloud evidence.
4. Generate an incident when the evidence supports a security investigation.
5. Enrich and triage using entities, tactics, techniques, custom details, and related alerts.
6. Automate carefully with automation rules or playbooks when the action is safe and repeatable.

For example, a high number of failed logons may be caused by password spraying, a misconfigured service, a user repeatedly entering an old password, or a legitimate administrative activity. The count alone is not sufficient evidence of compromise. Account type, source, target, geography, endpoint, and successful sign-ins should be considered before escalation or automated containment.

Exam-Relevant Takeaways

• Built-in Sentinel anomaly entries are stored in the Anomalies table.
• Built-in anomalies do not automatically create alerts or incidents.
• Anomaly data is intended to be correlated with other signals to build stronger detections.
• A custom NRT query rule can use KQL to identify activity that exceeds a baseline.
• Windows failed logons use Security Event ID 4625.
• summarize ... by AccountName, bin(TimeGenerated, 1h) groups failed-logon counts by account and one-hour intervals.
• Entity mapping, custom details, alert settings, incident settings, and automation can be configured when creating the analytics rule.
• A query that runs successfully is not necessarily a useful detection. Validate its data source, time window, threshold, output fields, and expected alert behavior.

Tool / Feature Decision Guide

Requirement	Appropriate feature	Why
Inspect behavior deviations already provided by Sentinel	Analytics > Anomalies	Provides built-in anomaly rules and their configuration details.
Store and use anomaly signals for correlation	Anomalies table	Anomaly records can be queried alongside other workspace data.
Create alerts or incidents from a custom threshold	Query-based analytics rule, such as NRT	The rule evaluates KQL results and can be configured for alert and incident creation.
Add users, accounts, hosts, or other investigation context	Entity mapping	Makes query results usable as incident entities.
Add investigation-specific values to an alert	Custom details	Carries selected fields into the alert or incident context.
Trigger a repeatable response after detection	Automation rules or playbooks	Applies response logic after the relevant alert or incident conditions are met.

Do not choose a built-in anomaly record alone when the requirement explicitly says to create an incident. Anomaly data must be correlated or processed by a detection that produces the required alerting outcome.

KQL Notes

The lesson’s example uses the SecurityEvent table and Windows event ID 4625 to find failed logons. A simplified, readable form is:

let baseline = 5;
let threshold = 3;
SecurityEvent
| where EventID == 4625
| summarize FailedLogins = count() by AccountName, bin(TimeGenerated, 1h)
| where FailedLogins > baseline * threshold
| project TimeGenerated, AccountName, FailedLogins,
          Anomaly = FailedLogins > baseline * threshold

This logic treats more than 5 × 3 failed logons for an account in a one-hour bucket as anomalous. The values are illustrative detection parameters, not universal security standards.

Important implementation considerations:

• Confirm that the workspace is receiving the expected SecurityEvent data before relying on the rule.
• Make sure the field names match the table schema in the target environment.
• A one-hour bin() groups events into fixed time buckets; it does not itself represent a continuously sliding one-hour window.
• A baseline and multiplier should be tuned to the environment. A single threshold for every account can create noise.
• Test the query against representative data, including both normal and suspicious activity, before enabling automated response.

Common Exam Traps

• Trap: Assuming every anomaly creates an incident. Correction: Anomaly records are written to the Anomalies table and do not directly create alerts or incidents.
• Trap: Confusing the Anomalies experience with an NRT analytics rule. Correction: The former exposes anomaly signals; the latter is a configurable query-based detection that can be set up for alerting and incident workflows.
• Trap: Treating a successful KQL validation as proof that the detection works. Correction: The query may be syntactically valid but return no data, use an incorrect schema, or produce excessive false positives.
• Trap: Assuming a failed-logon count proves password spraying. Correction: Investigate source IPs, accounts, time patterns, successful authentication, and related identity or endpoint signals.
• Trap: Forgetting entity mapping and custom details. Correction: These settings affect how useful the resulting alert or incident is for investigation.

Real-World SOC Analyst Notes

• Tune for alert fatigue: Start with historical data and identify normal service-account and administrator behavior before choosing a threshold.
• Preserve evidence: Retain the original event context, source information, timestamps, and related authentication activity when escalating an anomaly.
• Use corroboration: Combine failed-logon anomalies with successful logons, unfamiliar locations, risky sign-ins, endpoint alerts, or identity changes.
• Treat automation as a change-controlled action: An automatic account disablement or containment action can affect an entire business process if the rule is too broad.
• Document the baseline: Record why the threshold and time window were selected, who approved them, and when they should be reviewed.
• Check permissions and scope: Creating or modifying analytics rules, automation, and playbooks requires appropriate Sentinel and Azure permissions. Changes can affect the whole workspace.
• Monitor cost and retention: Query frequency, ingested data volume, and retention affect operational cost and the amount of historical evidence available for validation.

Quick Reference Summary

• Sentinel anomaly rules identify unusual behavior and write results to the Anomalies table.
• Anomaly records alone do not create alerts or incidents.
• Correlate anomalies with other signals or use a query-based analytics rule to build an actionable detection.
• NRT rules can evaluate KQL queries with near-real-time timing.
• Event ID 4625 represents a failed Windows logon.
• summarize and bin() can count events by account and time interval.
• Configure entity mapping, custom details, incident settings, and automation to make detections operationally useful.
• Validate data availability and tune thresholds before enabling automated response.

Flashcards

Q: Where are Microsoft Sentinel anomaly results stored, and what do they produce by default?
A: They are stored in the Anomalies table. They do not directly generate alerts or incidents.

Q: A requirement says to correlate unusual behavior with other signals before creating a detection. Which Sentinel capability should you use?
A: Use the anomaly data as an input for correlation with identity, endpoint, or other workspace signals. The anomaly record is a signal, not by itself an incident.

Q: When should you use a custom NRT analytics rule instead of only reviewing the Anomalies page?
A: Use an NRT rule when you need a KQL-based condition to produce an actionable alert or incident and optionally trigger configured automation.

Q: Which Windows Security event ID represents a failed logon in the lesson’s example?
A: Event ID 4625 represents a failed logon.

Q: What does bin(TimeGenerated, 1h) accomplish in the failed-logon query?
A: It groups events into one-hour time buckets so counts can be calculated for each account and hourly interval.

Q: In the example, how is a failed-logon anomaly threshold calculated?
A: The query compares the hourly failed-logon count with baseline * threshold; with values of 5 and 3, the comparison is against 15.

Q: Why is a syntactically valid KQL query not enough to approve an analytics rule?
A: It may have no matching data, incorrect field assumptions, an unsuitable threshold, or a high false-positive rate. Detection behavior must be tested with representative data.

Q: When should entity mapping be configured for a custom analytics rule?
A: Configure it when query results contain users, accounts, hosts, or other entities that analysts need to investigate in an incident.

Q: What is the difference between an anomaly record and an incident?
A: An anomaly record describes unusual behavior in the Anomalies table. An incident is an actionable investigation object created through alert and incident workflows.

Q: Why should a failed-logon threshold not automatically be treated as password spraying?
A: Failed logons can result from user error, stale credentials, or misconfigured services. Source distribution, account targeting, successful logons, and related signals are needed for classification.

Q: What is the operational risk of enabling automation immediately on a broad anomaly rule?
A: False positives could trigger disruptive actions, such as account or endpoint changes, across legitimate users or services. Test, scope, approve, and monitor automation first.

Q: What information can custom details add to an analytics alert?
A: They can carry useful query output fields into the alert or incident so analysts retain investigation context beyond the default fields.

Practice Questions

Question 1

A Sentinel analyst sees a built-in UEBA anomaly in the Anomalies experience and wants to know why no incident was created. What is the best explanation?

A. UEBA anomalies are visible only to Microsoft Defender XDR.

B. Anomalies are stored as signals and do not directly generate alerts or incidents.

C. The data connector must be disabled before incidents can be created.

D. NRT rules cannot use anomaly data.

Correct answer: B

The anomaly is written to the Anomalies table. It must be correlated with other signals or used by an appropriate detection workflow to produce an actionable alert or incident.

Question 2

A SOC team needs to detect accounts with more than 15 failed Windows logons in a one-hour interval and create an actionable detection. Which approach best fits the requirement?

A. View the built-in anomaly list without creating a rule.

B. Create a custom query-based NRT analytics rule using Security Event ID 4625 and an hourly aggregation.

C. Create a workbook and configure a chart threshold.

D. Add a watchlist containing all user accounts.

Correct answer: B

A query-based NRT analytics rule can aggregate failed-logon events, compare the count with the threshold, and be configured for alert, incident, entity, and automation settings.

Question 3

A query uses SecurityEvent and returns no results, although administrators confirm that failed logons occurred. What should the analyst check first?

A. Whether the workbook theme is enabled.

B. Whether the relevant security-event data is being ingested into the workspace and the schema fields match.

C. Whether every anomaly has already been closed.

D. Whether the account is present in a watchlist.

Correct answer: B

A valid query depends on the expected data source and schema being available. Data connectors, table availability, field names, and query time range should be verified before changing the detection logic.

Question 4

A proposed rule flags a service account whenever it exceeds the same failed-logon threshold used for human users. What is the most appropriate SOC action?

A. Enable automatic account disablement immediately.

B. Delete all service-account events from the workspace.

C. Review historical behavior and tune or scope the rule to reduce expected service-account noise.

D. Disable all Windows security event ingestion.

Correct answer: C

Service accounts often have different normal behavior. Historical analysis and rule scoping help reduce false positives before escalation or automated response is introduced.