This chapter covers User and Entity Behavior Analytics (UEBA) in Microsoft Sentinel, a critical capability for detecting anomalous behavior that may indicate security threats. UEBA uses machine learning to establish behavioral baselines and identify deviations, helping security analysts catch compromised accounts, insider threats, and advanced persistent threats. For the SC-200 exam, this topic appears in approximately 5-7% of questions, often in case studies or scenarios requiring identification of which analytics rule or feature to use. Mastering UEBA is essential for passing the exam and for real-world threat hunting.
Jump to a section
Think of UEBA as a bank fraud analyst who monitors every customer's daily banking behavior. The analyst learns each customer's normal pattern: typical transaction amounts, usual times of day, common locations, and regular recipients. This baseline is built over weeks of observation. One day, a customer who normally withdraws $200 from a local ATM at 2 PM suddenly attempts a $10,000 wire transfer to an unknown overseas account at 3 AM from a different country. The analyst flags this as anomalous, not because it matches a known fraud pattern, but because it deviates from the customer's personal baseline. The analyst then investigates further, checking if the customer's account was compromised or if the customer is under duress. Similarly, UEBA in Microsoft Sentinel builds behavioral profiles for users and entities (like devices, applications, and service principals) using machine learning. It continuously analyzes activities such as logon times, data access patterns, and network connections. When an activity deviates significantly from the learned baseline, UEBA generates an anomaly alert. The analyst does not rely on static rules; instead, the system adapts to each entity's unique behavior, reducing false positives for legitimate variations and catching subtle insider threats or compromised accounts that rule-based systems might miss.
What is UEBA and Why Does It Exist?
User and Entity Behavior Analytics (UEBA) is a security analytics technique that uses machine learning to model normal behavior of users, devices, applications, and other entities. Unlike traditional signature-based detection or static rule-based alerts, UEBA establishes a dynamic baseline for each entity and flags activities that fall outside that baseline. This approach is essential for detecting:
Compromised accounts (e.g., credential theft, lateral movement)
Insider threats (e.g., data exfiltration by a disgruntled employee)
Advanced persistent threats (APTs) that slowly escalate privileges
Anomalous service-to-service interactions (e.g., a service principal accessing unusual resources)
UEBA in Microsoft Sentinel is built on Azure Machine Learning models that are pre-trained by Microsoft but can be customized. It ingests data from multiple sources: Azure Active Directory (now Microsoft Entra ID) sign-in logs, audit logs, Office 365 activity logs, Azure activity logs, Windows Security Events, and third-party data sources via connectors.
How UEBA Works Internally
UEBA operates in three phases: Baseline Learning, Anomaly Detection, and Alert Generation.
Baseline Learning: When UEBA is enabled in Sentinel, it begins collecting historical data (up to 14 days by default) to establish a behavioral baseline for each entity. The baseline includes:
Time-based patterns: typical login times, days of the week, frequency of actions
Volume-based patterns: number of files accessed, emails sent, data transferred
Sequence-based patterns: typical order of operations (e.g., log in, then access a specific app)
Peer-group patterns: behavior compared to similar entities (e.g., same department, same role)
The machine learning models use algorithms like Isolation Forest, One-Class SVM, and time-series decomposition. These models are trained on the entity's own data as well as aggregate data from similar entities to detect both individual and group anomalies.
Anomaly Detection: After the baseline is established, Sentinel continuously evaluates incoming data against the baseline. Each activity receives a risk score based on:
Deviation magnitude: how far from the baseline (e.g., 3 standard deviations)
Anomaly type: new (never seen before), rare (seen infrequently), or surge (sudden increase)
Entity sensitivity: if the entity is a privileged user or high-value asset
Temporal decay: recent anomalies are weighted higher
Sentinel uses multiple anomaly detection models: - User anomaly models: detect unusual sign-in locations, impossible travel, unusual authentication methods, unusual Azure AD roles - Entity anomaly models: detect unusual behavior for devices (e.g., new process creation, unusual network connections), applications (e.g., unusual API calls), and service principals - Time series models: detect changes in volume over time (e.g., sudden spike in file deletions)
Alert Generation: When an anomaly is detected, Sentinel generates an Anomaly alert type. These alerts appear in the Sentinel portal under Incidents (if configured to create incidents) or as separate alerts. Each alert includes:
Entity name (user UPN, device ID, etc.)
Anomaly type (e.g., "Unusual sign-in location")
Risk score (0-100)
Description of the anomaly
Link to investigation playbook
By default, anomaly alerts do not automatically create incidents; they are meant for hunting and investigation. However, you can configure an analytics rule to create incidents from anomaly alerts with a custom severity.
Key Components, Values, Defaults, and Timers
Data retention for baseline: UEBA uses up to 14 days of historical data to build baselines. If data is older than 14 days, it is not used for baseline calculation. However, the models continuously update with new data.
Anomaly detection frequency: Sentinel evaluates data every hour for most anomaly types. Some models, like impossible travel, evaluate in near real-time (every 5 minutes).
Risk score thresholds: Anomalies with a risk score above 50 are considered high confidence. You can filter alerts by risk score in hunting queries.
Peer group size: For peer-group analysis, a peer group must have at least 5 members to be statistically significant. If fewer, the model uses global baselines.
Supported data sources: UEBA requires at least one of these connectors: Azure Active Directory (sign-in logs and audit logs), Office 365 (Exchange, SharePoint, Teams), Azure Activity, Windows Security Events (via AMA or MMA), or third-party via Common Event Format (CEF).
Anomaly model types: There are over 20 pre-built anomaly models. Key ones include:
- Unusual sign-in location - Impossible travel - Unusual authentication method (e.g., using FIDO2 when normally password) - Unusual Azure AD role assignment - Unusual number of sign-ins - Unusual file deletion (Office 365) - Unusual email forwarding - Unusual process creation (Windows) - Unusual network connection (Windows)
Configuration and Verification
To enable UEBA in Sentinel: 1. Navigate to Sentinel workspace -> Entity behavior 2. Click "Enable UEBA" (note: this requires at least one supported data connector) 3. Optionally, configure anomaly rules under Analytics -> Anomaly rule templates
To verify UEBA is working:
Use the hunting query "Anomalies" to see recent anomalies:
SecurityAlert
| where AlertName has "Anomaly"
| project TimeGenerated, AlertName, Entities, RiskScore
| order by TimeGenerated descCheck the IdentityInfo table which stores user profiles:
IdentityInfo
| where TimeGenerated > ago(7d)
| summarize count() by UserPrincipalNameUse the UEBA investigation experience: go to Entity behavior -> select a user -> view timeline of anomalies.
How UEBA Interacts with Related Technologies
Sentinel Analytics Rules: UEBA anomalies can feed into analytics rules via the "Anomaly" rule template. You can create custom rules that trigger incidents when specific anomaly types occur for specific entities.
Microsoft 365 Defender: UEBA data from Sentinel can be enriched with M365D alerts for a unified investigation experience.
Azure AD Identity Protection: Identity Protection also detects risky users and sign-ins, but UEBA in Sentinel provides more granular, entity-specific baselines across multiple data sources (not just Azure AD).
Sentinel Fusion: Fusion correlates multiple anomalies and alerts into high-fidelity incidents. UEBA anomalies are a key input for Fusion.
Hunting: UEBA anomalies are excellent starting points for proactive threat hunting. You can use the anomaly timeline to pivot to related logs.
Limitations and Considerations
UEBA requires a minimum of 7 days of data to establish baselines; 14 days is recommended.
It does not work on data that is not ingested into Sentinel (e.g., on-premises logs not connected).
Anomalies are not automatically incidents; you must configure rules to create incidents if needed.
The machine learning models are black-box; you cannot fine-tune them directly, but you can adjust the sensitivity via anomaly rule thresholds (low, medium, high).
Peer-group analysis may be less effective in small organizations (less than 10 users).
Enable UEBA in Sentinel
Navigate to the Microsoft Sentinel workspace in the Azure portal. Under the 'Threat management' section, select 'Entity behavior'. Click the 'Enable UEBA' button. This action activates the machine learning models and begins data ingestion for behavioral baselines. Note that UEBA requires at least one supported data connector (Azure AD, Office 365, Azure Activity, or Windows Security Events) to be enabled and collecting data. After enabling, Sentinel immediately starts collecting historical data (up to 14 days) to build baselines. You can verify enablement by checking the 'Status' field in the Entity behavior blade.
Configure Anomaly Rule Templates
Go to 'Analytics' in Sentinel and select the 'Anomaly rule templates' tab. You will see a list of pre-built anomaly detection rules, each corresponding to a specific UEBA model (e.g., 'Unusual sign-in location', 'Impossible travel'). By default, these rules are disabled. To enable a rule, select it and click 'Create rule'. In the wizard, you can set the severity (Low, Medium, High) and configure the incident creation behavior. You can also filter by entity type. For example, you might enable 'Unusual number of sign-ins' for all users but set a higher threshold for service accounts.
Review Anomaly Alerts
After enabling rules, anomalies will appear in the 'Incidents' or 'Alerts' blade depending on your configuration. To view raw anomalies without incident creation, use the hunting query: `SecurityAlert | where AlertName contains "Anomaly"`. Each anomaly includes fields like RiskScore, Entities, and Description. For example, an 'Impossible travel' anomaly will show two sign-ins from distant locations within a short time window. You can click on an anomaly to see the entity's behavioral timeline and related logs for investigation.
Investigate Using Entity Timeline
Select a user or device from the anomaly alert to open the Entity behavior page. Here you see a timeline of all activities (sign-ins, data access, etc.) with anomalies highlighted. You can filter by time range and activity type. Use this to determine if the anomaly is truly malicious. For instance, if a user's 'Unusual sign-in location' anomaly shows a sign-in from a known VPN endpoint, it might be benign. The timeline also shows peer-group comparisons and risk scores over time.
Create Custom Hunting Queries
For advanced threat hunting, use KQL to query the `IdentityInfo` and `BehaviorAnalytics` tables (if available). For example, to find users with high-risk anomalies in the last 24 hours: `BehaviorAnalytics | where TimeGenerated > ago(1d) | where RiskScore > 50 | project UserPrincipalName, RiskScore, ActionType`. You can also join with other tables like `SigninLogs` to correlate anomalies with actual sign-in details. This step is crucial for proactive detection beyond automated alerts.
Enterprise Scenario 1: Detecting Compromised Privileged Accounts
A global financial services firm with 50,000 employees enables UEBA in Sentinel to monitor their Azure AD and Office 365 environments. They configure anomaly rules for 'Unusual sign-in location' and 'Impossible travel' with medium severity. One day, an anomaly fires for a senior executive who normally logs in from New York. The anomaly shows a sign-in from a new IP in Eastern Europe at 3 AM, followed by a large number of file downloads from SharePoint. The security team investigates using the entity timeline and finds that the executive's account had recently changed password via a suspicious email. They immediately disable the account and initiate an incident response. Without UEBA, this credential theft might have gone undetected because the sign-in itself was successful and didn't match any known malicious IP. UEBA's baseline accurately flagged the geographic deviation and unusual data access pattern.
Enterprise Scenario 2: Insider Threat - Data Exfiltration
A technology company with 10,000 employees uses UEBA to monitor for insider threats. They enable anomaly rules for 'Unusual file deletion' and 'Unusual email forwarding'. An employee in the finance department, who normally accesses 50 files per day, suddenly accesses 500 files in one hour, including sensitive contract documents. UEBA generates an anomaly with a risk score of 85. The security team investigates and finds that the employee is copying files to a personal cloud storage service. They interview the employee, who admits to planning to leave the company with confidential data. UEBA caught the behavior because it deviated from the employee's personal baseline, not because the activity was inherently malicious. In a rule-based system, the volume increase might have been dismissed as a legitimate project need.
Performance and Misconfiguration Considerations
In large enterprises (100,000+ users), UEBA can generate hundreds of anomaly alerts per day. To avoid alert fatigue, organizations should:
Start with high-risk anomaly types only (e.g., impossible travel, unusual role assignment)
Use risk score thresholds (e.g., only alert on risk score > 70)
Exclude known good entities (e.g., service accounts, break-glass accounts) from anomaly detection
Integrate with Sentinel Fusion to correlate anomalies into incidents
Common misconfigurations include:
Enabling all anomaly rules without tuning, leading to noise
Not excluding VPN IP ranges, causing false positives for remote workers
Failing to enable UEBA for all data sources (e.g., only Azure AD but not Office 365)
Not updating baselines after major organizational changes (e.g., acquisition, new office locations)
To verify proper configuration, regularly review the 'Entity behavior' dashboard for coverage and check for entities with no baseline (often due to insufficient data).
SC-200 Exam Objectives for UEBA
The SC-200 exam tests UEBA under objective 2.2 Create and manage analytics rules in Microsoft Sentinel. Specifically, you should understand:
How to enable UEBA and configure anomaly rules
The difference between UEBA anomalies and scheduled analytics rules
How to interpret anomaly risk scores and severity
How to use UEBA for incident investigation and hunting
The data sources required for UEBA (Azure AD, Office 365, Azure Activity, Windows Security Events)
Common Wrong Answers and Traps
"UEBA automatically creates incidents for all anomalies" – Wrong. By default, anomalies do not create incidents. You must enable an anomaly rule template and configure incident creation. Many candidates assume anomalies are automatically incidents because other alert types are. Remember: anomalies are for hunting; incidents are for response.
"UEBA only works with Azure AD data" – Wrong. While Azure AD is a primary source, UEBA also uses Office 365, Azure Activity, and Windows Security Events. The exam may present a scenario where only Azure AD is connected and ask whether UEBA can detect file deletion anomalies – it cannot, because that requires Office 365 logs.
"Impossible travel detection requires only Azure AD sign-in logs" – Partially correct but incomplete. Impossible travel uses Azure AD sign-in logs, but it also requires the IP geolocation data that Sentinel enriches. If IP geolocation is not available (e.g., private IPs), impossible travel may not fire. The exam may test this edge case.
"UEBA can be customized with custom machine learning models" – Wrong. You cannot upload your own models. You can only use the pre-built models and adjust sensitivity via thresholds (low, medium, high). This is a common misconception.
Specific Numbers and Terms to Memorize
Default baseline period: 14 days
Minimum data for baseline: 7 days
Risk score range: 0-100
High confidence threshold: 50
Peer group minimum size: 5
Anomaly evaluation frequency: hourly (most models), every 5 minutes (impossible travel)
Supported anomaly types: over 20 (know the main ones: unusual sign-in location, impossible travel, unusual authentication method, unusual Azure AD role assignment, unusual file deletion, unusual email forwarding, unusual process creation)
Edge Cases and Exam Favorites
New user: A user created yesterday has no baseline. UEBA will not generate anomalies for them until at least 7 days of data are collected. The exam might ask what happens when a new user performs unusual activity – the answer is no anomaly until baseline is established.
Guest users: Guest users in Azure AD are also profiled. Anomalies for guest users can indicate compromised external accounts.
Service principals: UEBA also profiles service principals (applications). Anomalies like 'Unusual API call pattern' can detect compromised service principals.
Multiple anomalies for same entity: UEBA can generate multiple anomaly types for the same entity, which Fusion can correlate into a single high-severity incident.
How to Eliminate Wrong Answers
If a question asks which feature to use for detecting anomalous user behavior, eliminate options that:
Mention signature-based detection (e.g., "detects known malware")
Require custom code (e.g., "write a Python script")
Are not real features (e.g., "User Risk Policy" – this is Azure AD Identity Protection, not Sentinel UEBA)
Focus on network traffic only (e.g., "Network traffic analytics" – that's for flow logs, not user behavior)
Always look for keywords: "baseline", "machine learning", "anomaly", "user behavior", "entity behavior".
UEBA uses up to 14 days of historical data to build behavioral baselines; minimum 7 days needed.
UEBA supports over 20 anomaly models including impossible travel, unusual sign-in location, and unusual file deletion.
By default, UEBA anomalies do not create incidents; you must enable anomaly rule templates to generate incidents.
UEBA requires data from Azure AD, Office 365, Azure Activity, or Windows Security Events; other data sources are not directly supported.
Risk scores range from 0-100; scores above 50 are considered high confidence.
Peer-group analysis requires at least 5 members in a group to be statistically valid.
UEBA is a detection-only feature; it does not automatically block or remediate threats.
Impossible travel detection uses IP geolocation; if geolocation is unavailable, the model cannot detect impossible travel.
UEBA can profile not only users but also devices, applications, and service principals.
Fusion in Sentinel correlates multiple UEBA anomalies with other alerts to create high-fidelity incidents.
These come up on the exam all the time. Here's how to tell them apart.
UEBA in Sentinel
Analyzes behavior across multiple data sources (Azure AD, Office 365, Windows Events, Azure Activity).
Provides entity-level baselines for users, devices, applications, and service principals.
Generates anomaly alerts with risk scores (0-100) and supports custom hunting queries.
Requires manual configuration of anomaly rules to create incidents.
Integrates with Sentinel Fusion for correlation of multiple anomalies.
Azure AD Identity Protection
Analyzes only Azure AD sign-in and user risk (limited to Azure AD data).
Focuses on user risk and sign-in risk levels (low, medium, high).
Automatically creates risk events and can trigger Conditional Access policies for remediation.
Provides a risk policy that can block sign-ins or require MFA automatically.
Is part of Azure AD P2 license and is separate from Sentinel.
UEBA Anomaly Rules
Use machine learning to establish dynamic baselines per entity.
Detect deviations from normal behavior without predefined patterns.
Generate anomaly alerts with a risk score; do not automatically create incidents by default.
Cannot be customized with custom detection logic; only sensitivity thresholds can be adjusted.
Best for detecting unknown threats, insider threats, and compromised accounts.
Scheduled Analytics Rules
Use static KQL queries to match specific patterns (e.g., multiple failed logins).
Detect known attack patterns based on rules written by the analyst.
Create incidents automatically based on rule configuration (e.g., every time the query returns results).
Fully customizable: you write the KQL query, set frequency, and map entities.
Best for detecting known threats and compliance violations.
Mistake
UEBA requires a minimum of 30 days of data to establish baselines.
Correct
UEBA uses up to 14 days of historical data by default, with a minimum of 7 days to establish a baseline. You can adjust the baseline period in some configurations, but 30 days is not required.
Mistake
UEBA anomalies always create incidents automatically.
Correct
By default, anomaly alerts do NOT create incidents. You must enable an anomaly rule template and configure incident creation. This is a common trap on the exam.
Mistake
UEBA can detect anomalies for any data source connected to Sentinel.
Correct
UEBA only works with specific data sources: Azure AD, Office 365, Azure Activity, and Windows Security Events (via AMA/MMA). Third-party connectors like Syslog or CEF do not directly feed UEBA models unless they are mapped to these schemas.
Mistake
UEBA can be used to block malicious activity in real-time.
Correct
UEBA is a detection-only capability. It generates alerts but does not automatically block or remediate. You must integrate with other tools (e.g., Azure AD Conditional Access, Microsoft 365 Defender) for automated response.
Mistake
Impossible travel detection works even if IP geolocation is not available.
Correct
Impossible travel relies on IP geolocation to calculate distance between sign-ins. If geolocation data is missing (e.g., private IPs, unknown IPs), the model cannot calculate impossible travel and will not generate an anomaly.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
To enable UEBA, go to your Sentinel workspace in the Azure portal, under 'Threat management' select 'Entity behavior', and click 'Enable UEBA'. You must have at least one supported data connector (Azure AD, Office 365, Azure Activity, or Windows Security Events) already enabled and collecting data. After enabling, Sentinel uses up to 14 days of historical data to build baselines. You can verify enablement by checking the status in the Entity behavior blade.
UEBA supports Azure Active Directory (sign-in logs and audit logs), Office 365 (Exchange, SharePoint, Teams), Azure Activity logs, and Windows Security Events (via Azure Monitor Agent or legacy MMA). Third-party data sources like Syslog or CEF are not directly supported unless they are mapped to one of these schemas. For the exam, remember that UEBA cannot detect file deletion anomalies without Office 365 logs.
No, by default UEBA anomalies do not create incidents. You must configure an anomaly rule template under Analytics -> Anomaly rule templates. When you enable a template, you can choose to create incidents with a specified severity. If you do not enable any anomaly rule, anomalies will only appear in the hunting experience and in the SecurityAlert table.
UEBA in Sentinel analyzes behavior across multiple data sources (Azure AD, Office 365, Windows, Azure Activity) and provides entity-level baselines for users, devices, and applications. Azure AD Identity Protection focuses only on Azure AD sign-in and user risk, and can automatically enforce Conditional Access policies. UEBA is for detection and hunting; Identity Protection can automatically block or require MFA. Both can be used together for layered defense.
UEBA uses up to 14 days of historical data to build baselines. However, a minimum of 7 days of data is required for the models to be statistically significant. For new entities with less than 7 days of data, anomalies will not be generated. This is a common exam point: a new user will not trigger UEBA anomalies until at least 7 days have passed.
No, you cannot upload custom machine learning models. You can only adjust the sensitivity of pre-built anomaly models via thresholds (low, medium, high) and enable/disable specific anomaly types. Microsoft provides over 20 pre-built models. For the exam, know that customization is limited to rule configuration, not model training.
Impossible travel detection identifies two sign-ins from the same user that occur in geographically distant locations within a time window that makes physical travel impossible. For example, a sign-in from New York and another from London within 30 minutes. The model uses IP geolocation to determine locations. If geolocation data is missing (e.g., private IPs), impossible travel cannot be detected. This anomaly is evaluated every 5 minutes in near real-time.
You've just covered User and Entity Behaviour Analytics in Sentinel — now see how well it sticks with free SC-200 practice questions. Full explanations included, no account needed.
Done with this chapter?