This chapter covers User and Entity Behavior Analytics (UEBA) in Microsoft Sentinel, a critical topic for the Security Operations domain of the AZ-500 exam. You will learn how UEBA leverages machine learning to detect anomalies in user and entity behavior, helping identify compromised accounts and insider threats. Approximately 10-15% of exam questions in domain 4 (Security Operations) touch on UEBA, often in the context of configuring analytics rules and interpreting anomaly scores. Mastering UEBA is essential for passing the AZ-500 and for real-world cloud security operations.
Jump to a section
Imagine you manage a large hotel with thousands of guests. Each guest has a typical pattern: they leave their room by 9 AM, return by 6 PM, and order room service once a day. You hire a housekeeper who not only cleans rooms but also watches for anomalies. One day, the housekeeper notices that a guest who usually leaves at 9 AM hasn't left by noon. She checks the logs: the guest's key card wasn't used at the elevator, but the door was opened at 2 AM. She also sees that the guest's laptop is connected to the hotel Wi-Fi, but the guest is supposed to be out. This is suspicious. The housekeeper doesn't just react to a single event; she compares current behavior to a baseline—the guest's past patterns and the patterns of similar guests (e.g., business travelers). She uses multiple signals: time of day, location, device usage, and access logs. In Microsoft Sentinel, this is exactly what UEBA does. It builds a behavioral profile for each user and entity (like a guest profile), then scores deviations. A single failed login isn't alarming, but a failed login from a foreign IP at 3 AM, followed by a successful login and a download of 1000 files, triggers a high anomaly score. The housekeeper (UEBA) alerts the front desk (security team) before any real damage occurs. This is mechanistic: the hotel's key card system, Wi-Fi logs, and room service orders are data sources; the housekeeper's training (machine learning models) identifies patterns; and the alert is the anomaly score. Just as the housekeeper can't stop a theft alone but can notify security, UEBA doesn't block but informs analysts to act.
What is UEBA and Why Does It Exist?
User and Entity Behavior Analytics (UEBA) in Microsoft Sentinel is a behavioral analytics engine that identifies suspicious activities by establishing baselines of normal behavior for users, hosts, IP addresses, and applications. Traditional SIEM systems rely on static rules (e.g., alert if more than 10 failed logins). UEBA goes further: it learns what 'normal' looks like for each entity over time and flags deviations. This is crucial because attackers often operate within normal parameters—a single failed login from a new location might be ignored by static rules, but UEBA sees it as a deviation from the user's typical geolocation. UEBA is built into Microsoft Sentinel as part of the 'Entity Behavior' feature and is enabled by default when you onboard Sentinel. It uses machine learning models trained on Microsoft's vast threat intelligence and your own tenant data.
How UEBA Works Internally
UEBA operates through a multi-stage pipeline:
Data Ingestion: Sentinel ingests logs from various sources—Azure AD sign-in logs, Office 365 audit logs, Azure Activity logs, Windows Security Events, and custom logs. Each log record is parsed into a normalized schema called the 'Common Security Log' (CSL).
Entity Extraction: Entities (users, hosts, IPs, applications) are extracted from logs. For example, from a sign-in log, the user principal name, source IP, device ID, and application are extracted.
Baseline Creation: For each entity, Sentinel builds a behavioral baseline using a sliding window of typically 14 days (configurable). Baselines include: typical login times, geolocations, devices used, applications accessed, and data transfer volumes. For hosts, baselines include: typical processes running, network connections, and logon events.
Anomaly Scoring: Each new event is compared against the baseline. Multiple machine learning algorithms (e.g., Isolation Forest, Time Series Decomposition) assign an anomaly score from 0 to 10. A score above 3.5 is considered suspicious; above 7 is highly anomalous. The score is calculated based on: rarity of the behavior, number of deviations, and correlation with other anomalies.
Alert Generation: When the anomaly score exceeds a threshold (default 3.5), Sentinel generates an 'Anomalous Behavior' alert. These alerts appear in the 'Incidents' queue with a severity based on the score. Analysts can investigate using the entity's timeline and peer comparison.
Key Components, Values, Defaults, and Timers
Anomaly Score Range: 0 (normal) to 10 (highly anomalous). Default threshold for alerting is 3.5.
Baseline Window: Default 14 days of historical data. The first 14 days after enabling UEBA are a 'learning period' during which no anomalies are generated except for extreme outliers.
Data Sources: UEBA supports: Azure AD (sign-in logs, audit logs), Office 365 (Exchange, SharePoint, Teams), Azure Activity, Windows Security Events (4624, 4625, 4648), and custom logs through the 'CommonSecurityLog' schema.
Entity Types: User accounts, Azure AD applications, Azure resources, IP addresses, and hosts.
Retention: Behavioral baselines are stored for up to 30 days. Historical anomalies are retained as per your workspace retention (default 90 days).
Anomaly Types: UEBA detects: impossible travel (logins from distant locations in short time), unusual geolocation, unfamiliar sign-in properties, anomalous token usage, and data exfiltration patterns.
Configuration and Verification Commands
UEBA is enabled by default in Sentinel. To verify:
In the Azure portal, navigate to 'Sentinel' > 'Your workspace' > 'Entity behavior' under 'Threat management'. If UEBA is enabled, you'll see a list of entities with their anomaly scores.
To configure anomaly thresholds or disable UEBA, use the 'Settings' > 'UEBA' blade. You can adjust the anomaly score threshold (default 3.5) per workspace.
To query anomaly data via KQL:
SecurityAlert
| where AlertName contains "UEBA"
| project TimeGenerated, AlertName, Severity, EntitiesTo check baseline status for a specific user:
BehaviorAnalytics
| where UserPrincipalName == "user@domain.com"
| summarize arg_max(TimeGenerated, *) by UserPrincipalName
| project UserPrincipalName, BaselineTimeRange, AnomalyScoreInteraction with Related Technologies
UEBA integrates with: - Azure AD Identity Protection: UEBA can ingest risk signals from Identity Protection (e.g., leaked credentials, unfamiliar sign-in properties) and correlate them with behavioral anomalies. - Microsoft Defender for Cloud Apps: UEBA uses app-level anomalies (e.g., unusual file downloads from cloud apps) to enrich user profiles. - Azure ATP (now part of Microsoft Defender for Identity): On-premises Active Directory anomalies (e.g., anomalous logons, Kerberos attacks) are fed into Sentinel and used by UEBA. - Custom Analytics Rules: You can create custom detection rules that reference UEBA anomaly scores. For example:
BehaviorAnalytics
| where AnomalyScore > 7
| join kind=inner (SecurityEvent | where EventID == 4625) on AccountThis rule alerts when a high UEBA score coincides with a failed logon.
Exam-Relevant Details
UEBA is not a replacement for analytics rules; it complements them. The exam may test that UEBA uses machine learning, not static signatures.
The default learning period is 14 days. During this time, only extreme anomalies (score > 9) generate alerts.
UEBA supports peer comparison: it compares a user's behavior to users in the same role or department. If a finance user suddenly accesses HR files, the anomaly score increases because that action is rare among peers.
Impossible travel detection: UEBA calculates the time difference between two logins and the geographical distance. If the distance divided by time exceeds typical travel speed (e.g., 500 mph), it flags as impossible travel. The default threshold is a speed of 500 mph or greater.
Unfamiliar sign-in properties: UEBA learns the typical IP ranges, user agents, and devices for each user. A login from a new IP outside the baseline triggers an anomaly.
Data exfiltration: UEBA monitors data transfer volumes. A user who typically uploads 10 MB/day suddenly uploading 1 GB triggers a high anomaly score.
Common Misconfigurations
Disabling UEBA: Some admins disable UEBA to reduce noise, but this removes behavioral detection. Instead, adjust the anomaly score threshold.
Ignoring the learning period: Alerts during the first 14 days may be unreliable. Plan to review alerts after the learning period.
Not enabling required data sources: UEBA requires Azure AD sign-in logs and Office 365 audit logs. Without these, user behavior analytics is limited.
Performance Considerations
UEBA is a background process that runs on the Sentinel backend. It does not consume KQL query resources. However, storing behavioral data increases workspace size. For a tenant with 10,000 users, expect approximately 1-2 GB per month in additional storage. There is no separate cost for UEBA; it is included in the Sentinel pricing (pay-as-you-go for data ingestion).
Enable UEBA in Sentinel Workspace
UEBA is enabled by default in Microsoft Sentinel workspaces created after June 2021. For older workspaces, you may need to enable it manually. In the Azure portal, navigate to your Sentinel workspace, select 'Entity behavior' under 'Threat management', and click 'Enable UEBA'. This action activates the machine learning models that will start building baselines from existing log data. The first 14 days are a learning period; no anomaly alerts (except extreme outliers) are generated. During this period, Sentinel ingests logs from connected data sources like Azure AD, Office 365, and Windows Security Events. The baseline is built per entity (user, host, IP, etc.) using a sliding window of the last 14 days of data. Once the learning period ends, anomaly detection begins.
Ingest and Normalize Log Data
UEBA relies on normalized log data. Sentinel ingests logs from various sources and converts them into the CommonSecurityLog schema. For example, Azure AD sign-in logs are mapped to fields like UserPrincipalName, IPAddress, DeviceId, and AppDisplayName. Office 365 audit logs provide details on file access, email activity, and Teams interactions. Windows Security Events (e.g., 4624 for successful logon, 4625 for failed logon) are parsed to extract Account, LogonType, and ProcessName. This normalization ensures that UEBA's machine learning models can process data consistently across sources. The ingestion is continuous; new log entries are processed within minutes. If a data source is disconnected, UEBA stops updating baselines for those entities, but historical baselines remain.
Build Behavioral Baselines per Entity
For each user, host, IP, and application, UEBA builds a behavioral baseline using a 14-day sliding window. The baseline includes statistical profiles such as typical login times (e.g., 9 AM to 5 PM), common geolocations (e.g., city or country), frequently used devices (e.g., device IDs), and typical data transfer volumes (e.g., 10 MB/day for a user). For hosts, baselines include typical processes (e.g., explorer.exe, svchost.exe), network connections (e.g., outbound to specific IPs), and logon events. The baseline is updated continuously as new data arrives. If a user's behavior changes (e.g., they start working from a new office), the baseline gradually adapts over 14 days. UEBA also performs peer group analysis: users in the same Azure AD group or department are compared to create a group baseline. This helps detect when an individual deviates from their peers.
Score New Events for Anomalies
Each new event is compared against the entity's baseline using multiple machine learning algorithms. For example, if a user logs in from a new country, the 'unusual geolocation' algorithm calculates a score based on how far the new location is from the baseline. The 'impossible travel' algorithm checks if the time between two logins is insufficient to travel the distance. The 'unfamiliar sign-in properties' algorithm compares the user agent and device ID. Each algorithm outputs a subscore from 0 to 10. The overall anomaly score is a weighted combination of these subscores, with higher weight given to rare behaviors. The default threshold for generating an alert is 3.5. Scores between 3.5 and 7 generate a 'Medium' severity alert; scores above 7 generate 'High' severity. The scoring is real-time; as soon as the event is ingested, the score is calculated and stored in the BehaviorAnalytics table.
Generate and Investigate Anomaly Alerts
When the anomaly score exceeds the threshold, Sentinel creates an 'Anomalous Behavior' alert. This alert appears in the Incidents queue with a severity based on the score. The alert includes details: entity name, anomaly type (e.g., 'Unusual geolocation'), score, and links to the entity's timeline. Analysts can investigate by opening the entity page, which shows a historical view of all behaviors and anomaly scores. The page also provides peer comparison (e.g., 'This user logged in from a country where 95% of peers have never logged in'). Analysts can take actions like resetting the user's password, disabling the account, or creating a custom analytics rule to monitor similar behavior. The alert can be closed as 'True Positive', 'False Positive', or 'Benign Positive'. If marked as false positive, Sentinel learns from this feedback and may reduce future scores for similar events.
Enterprise Scenario 1: Detecting Compromised Accounts in a Global Organization
A multinational company with 50,000 employees uses Microsoft Sentinel with UEBA to detect account compromise. An attacker phishes a finance manager and steals their credentials. The attacker logs in from a foreign IP at 2 AM local time (3 PM attacker's time). UEBA immediately flags this as an anomaly: the user never logs in from that country, and the time is outside the user's typical 8 AM-6 PM window. The anomaly score is 8.5. The security team receives a high-severity alert. They investigate the entity timeline and see that the login was followed by a download of 500 MB from SharePoint (the user typically downloads 10 MB). The team disables the account within 10 minutes, preventing data exfiltration. In production, this requires proper configuration of data sources: Azure AD sign-in logs (free tier), Office 365 audit logs (requires E5 license), and Windows Security Events (requires Azure Arc or MMA agent). Performance considerations: for 50,000 users, UEBA consumes about 2 GB/month in storage. The learning period should be planned during a quiet period to avoid false positives from legitimate changes (e.g., new office opening).
Enterprise Scenario 2: Insider Threat Detection in a Research Lab
A research lab with 200 users uses UEBA to detect insider threats. A scientist begins exfiltrating research data by uploading large files to a personal cloud storage account. UEBA detects an anomaly: the user's data upload volume increased from 100 MB/day to 5 GB/day. The 'unusual data transfer' algorithm scores 9.2. Additionally, the user is accessing files outside their usual scope (e.g., accessing a project folder they never accessed before). The alert triggers an investigation. The lab's policy is to alert HR before taking action. They find the scientist is leaving the company and had signed a non-compete. The data exfiltration is stopped. In this scenario, custom logs from the cloud storage gateway (e.g., using CommonSecurityLog) are essential. Without them, UEBA would not see the upload. Also, the lab configures a custom analytics rule that triggers when the anomaly score exceeds 8 and the user is in the 'Research' group. This reduces false positives from admins who might legitimately transfer large files.
Common Misconfigurations and Pitfalls
Not enabling Office 365 audit logs: Without these, UEBA misses file access and email anomalies. Many organizations only enable Azure AD logs, leaving a gap.
Ignoring the learning period: Deploying UEBA and immediately expecting accurate alerts leads to frustration. Plan a 14-day quiet period.
Setting threshold too low: Default 3.5 may generate many alerts in large environments. Some security teams raise it to 5 to reduce noise, but risk missing subtle attacks.
Not integrating with incident response: UEBA alerts alone are not enough; they must feed into a playbook that automates response (e.g., disable account, notify admin).
Exactly What AZ-500 Tests on UEBA
The AZ-500 exam objective 4.2 specifically covers 'Implement threat protection' and includes UEBA under 'Configure and manage Microsoft Sentinel'. Exam questions focus on: - Understanding what UEBA does: It detects anomalies using machine learning, not static rules. It builds baselines of normal behavior. - Knowing the default learning period: 14 days. - Recognizing data sources: Azure AD, Office 365, Windows Security Events, and custom logs via CommonSecurityLog. - Interpreting anomaly scores: Threshold 3.5 for alerts; scores 0-10. - Differentiating UEBA from other Sentinel features: UEBA is not the same as 'Fusion' (which correlates multiple alerts) or 'Analytics rules' (which are KQL-based).
Common Wrong Answers and Why Candidates Choose Them
Wrong answer: 'UEBA requires manual baseline configuration.' Candidates assume baselines must be defined manually, but UEBA automatically builds them from historical data. The correct answer is that baselines are built automatically over 14 days.
Wrong answer: 'UEBA can detect malware signatures.' UEBA does not use signatures; it uses behavioral anomalies. Candidates confuse UEBA with antivirus or endpoint detection.
Wrong answer: 'UEBA is disabled by default and must be enabled via PowerShell.' In fact, UEBA is enabled by default for new workspaces. It can be disabled via the portal, not necessarily PowerShell.
Wrong answer: 'UEBA only works with Azure AD logs.' While Azure AD is primary, UEBA also ingests Office 365, Windows Security Events, and custom logs.
Specific Numbers and Terms That Appear on the Exam
14 days: Learning period and baseline window.
3.5: Default anomaly score threshold for alerting.
0-10: Anomaly score range.
Impossible travel: Detection based on speed > 500 mph.
Peer comparison: UEBA compares users to similar users.
BehaviorAnalytics: The KQL table storing anomaly data.
Edge Cases and Exceptions
New users: For a new user with no baseline, UEBA cannot detect anomalies until 14 days of data accumulate. During this period, no alerts are generated (except extreme outliers).
Disconnected data sources: If a data source is disconnected, UEBA stops updating baselines for those entities but retains historical data.
Guest users: UEBA processes guest users from Azure AD B2B, but baselines may be thin if they have limited activity.
Service accounts: UEBA treats service accounts (e.g., app registrations) as entities, but their behavior is often scripted, so anomalies may be less meaningful.
How to Eliminate Wrong Answers
If an answer mentions 'static rules' or 'signatures', it is wrong for UEBA.
If an answer says 'requires manual tuning', it is wrong; UEBA is automated.
If an answer says 'works immediately', it is wrong; there is a 14-day learning period.
If an answer says 'only for users', it is wrong; UEBA covers users, hosts, IPs, and applications.
UEBA in Microsoft Sentinel uses machine learning to detect behavioral anomalies by building baselines over a 14-day sliding window.
Default anomaly score threshold for alerting is 3.5 (range 0-10).
UEBA supports users, hosts, IP addresses, and applications as entities.
Required data sources: Azure AD sign-in logs, Office 365 audit logs, Windows Security Events, and custom logs.
Impossible travel detection flags logins where speed > 500 mph.
UEBA includes peer comparison to reduce false positives.
The first 14 days after enabling UEBA are a learning period with minimal alerts.
UEBA is enabled by default in new Sentinel workspaces.
UEBA is not a replacement for analytics rules; it complements them.
Common anomaly types: unusual geolocation, unfamiliar sign-in properties, impossible travel, anomalous token usage, data exfiltration.
These come up on the exam all the time. Here's how to tell them apart.
UEBA (User and Entity Behavior Analytics)
Uses machine learning to automatically build baselines
Detects unknown anomalies without predefined rules
Requires 14-day learning period
Anomaly score range 0-10, threshold 3.5
Lower false positive rate for novel attacks
Analytics Rules (KQL-based)
Uses manually written KQL queries to match specific patterns
Detects known threats based on predefined conditions
Works immediately after creation
Generates alerts based on query results (e.g., count > 5)
Higher false positive rate if not tuned
Mistake
UEBA requires manual configuration of baselines for each user.
Correct
UEBA automatically builds baselines using machine learning on historical data over a 14-day sliding window. No manual configuration is needed.
Mistake
UEBA can detect zero-day malware by matching signatures.
Correct
UEBA does not use signatures; it detects behavioral anomalies. Zero-day malware may be detected if it causes unusual behavior (e.g., unusual process execution).
Mistake
UEBA generates alerts immediately after enabling it.
Correct
UEBA has a 14-day learning period during which no alerts are generated (except extreme outliers). Alerts start after the baseline is established.
Mistake
UEBA only works with Azure AD sign-in logs.
Correct
UEBA ingests data from multiple sources: Azure AD, Office 365, Windows Security Events, and custom logs via CommonSecurityLog.
Mistake
UEBA is a separate paid add-on for Sentinel.
Correct
UEBA is included in Microsoft Sentinel at no extra cost. You only pay for data ingestion and storage.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The default learning period is 14 days. During this time, UEBA builds baselines of normal behavior for each entity. No anomaly alerts are generated except for extreme outliers (score > 9). After 14 days, anomaly detection begins with the default threshold of 3.5.
UEBA is enabled by default for workspaces created after June 2021. To verify, go to your Sentinel workspace, under 'Threat management' select 'Entity behavior', and click 'Enable UEBA' if not already enabled. You can also adjust the anomaly score threshold here.
UEBA ingests data from Azure AD (sign-in and audit logs), Office 365 (Exchange, SharePoint, Teams), Windows Security Events (e.g., 4624, 4625), and custom logs via CommonSecurityLog. Without Azure AD logs, user behavior analytics is severely limited.
Yes, UEBA can detect data exfiltration by monitoring unusual increases in data transfer volumes. For example, if a user typically uploads 10 MB/day and suddenly uploads 1 GB, UEBA will flag this as an anomaly with a high score.
UEBA focuses on behavioral anomalies of individual entities, using machine learning to detect deviations from baselines. Fusion correlates multiple alerts from different sources to detect multi-stage attacks. UEBA generates 'Anomalous Behavior' alerts; Fusion generates 'Fusion' incidents.
Use the BehaviorAnalytics table: `BehaviorAnalytics | where AnomalyScore > 3.5 | project TimeGenerated, UserPrincipalName, AnomalyScore, AnomalyType`. This returns all anomalies above the threshold.
Yes, UEBA processes guest users (B2B collaboration) as entities. However, their baselines may be less accurate if they have limited activity in the tenant.
You've just covered UEBA in Microsoft Sentinel — now see how well it sticks with free AZ-500 practice questions. Full explanations included, no account needed.
Done with this chapter?