9.8 User and Entity Behavior Analytics (UEBA)

User and Entity Behavior Analytics (UEBA)

Introduction

Analytics rules detect known threat patterns — “if failed logons exceed 20 from the same IP, alert.” UEBA detects unknown patterns — “this user’s behaviour today is significantly different from their established baseline.” A brute-force rule catches the attacker guessing passwords. UEBA catches the insider threat who gradually escalates access over weeks, or the compromised account that suddenly accesses resources it has never touched before.

UEBA builds behavioural baselines for users and entities by analysing historical data. When current behaviour deviates from the baseline beyond a configured threshold, an anomaly is generated. These anomalies feed into the investigation workflow — enriching incidents with behavioural context that static rules cannot provide.

Enabling and configuring UEBA

Navigate to Sentinel → Settings → Settings → User and Entity Behavior Analytics.

Step 1: Enable UEBA. Toggle UEBA to On.

Step 2: Select data sources. UEBA analyses data from: Entra ID sign-in logs (authentication behaviour), Azure Activity (cloud resource access), SecurityEvent (Windows logon behaviour), and Syslog (Linux authentication). Enable all data sources that are connected and ingesting data. UEBA cannot analyse data from connectors that are not enabled.

Step 3: Sync with Entra ID. Enable the Entra ID entity sync to populate user attributes (department, manager, job title, location) that UEBA uses for peer group analysis. Peer group analysis compares a user’s behaviour to others in the same department/role — deviations from peer behaviour are more meaningful than deviations from the entire organisation.

Step 4: Wait for baseline establishment. UEBA needs 14-21 days of data to build meaningful behavioural baselines. During this period, anomaly detection sensitivity is low. Do not expect accurate anomalies immediately after enabling UEBA.

How UEBA scores behaviour

UEBA generates two types of output.

Entity pages. For each user and entity, UEBA creates a page showing: the entity’s behavioural timeline, anomalies detected, investigation priority score, and peer group comparison. Navigate to Sentinel → Entity behavior → search for a user.

Investigation priority score. Each entity receives a numerical score (0-10) based on: the number of anomalies detected, the severity of those anomalies, the entity’s deviation from peer group behaviour, and whether the entity has been involved in recent incidents. High investigation priority scores indicate entities that warrant proactive investigation — even without a specific incident.

Anomaly types detected by UEBA:

Anomalous sign-in behaviour — sign-in from an unusual location, unusual time, unusual device, or unusual application. Different from Entra ID risk detection: UEBA uses the Sentinel baseline (which includes all data sources), while Entra ID uses only sign-in data.

Anomalous resource access — accessing a resource (file, application, database) that the user or peer group has never accessed before. Useful for detecting lateral movement and privilege escalation.

Anomalous data access volume — downloading, copying, or exporting significantly more data than the user’s baseline. Useful for detecting data exfiltration.

Anomalous administrative activity — performing administrative operations (user creation, permission changes, configuration modifications) at unusual rates or unusual times.

Using UEBA in investigation

UEBA data enriches incident investigation at two levels.

Level 1: Incident enrichment. When investigating an incident, check the UEBA entity page for the involved entities. If the compromised account has an investigation priority score of 8/10 with multiple anomalies in the preceding 48 hours, the incident is likely part of a larger compromise — not an isolated event. If the account has a score of 1/10 with no anomalies, the incident may be a false positive or an early-stage attack that has not yet generated behavioural deviation.

Level 2: Proactive hunting. Review entities with high investigation priority scores even without a specific incident trigger. Navigate to Entity behavior → sort by investigation priority. Entities with scores above 7 warrant a brief review: what anomalies were detected? Do they correlate with known threats? This is proactive threat discovery — finding compromises before analytics rules detect them.

1
2
3
4
5
6
7
8

// Find entities with high UEBA investigation priority
BehaviorAnalytics
| where TimeGenerated > ago(24h)
| where InvestigationPriority > 7
| summarize AnomalyCount = dcount(ActivityType),
    Anomalies = make_set(ActivityType, 10)
    by UserPrincipalName, InvestigationPriority
| order by InvestigationPriority desc

1
2
3
4
5
6
7
8

// Investigate a specific user's behavioral timeline
BehaviorAnalytics
| where TimeGenerated > ago(7d)
| where UserPrincipalName == "j.morrison@northgateeng.com"
| project TimeGenerated, ActivityType, ActionType,
    SourceIPAddress, DevicesInsight, ActivityInsights,
    InvestigationPriority, UsersInsight
| order by TimeGenerated desc

UEBA and anomaly rules: the relationship

Anomaly rules (subsection 9.3) are the detection layer that feeds UEBA. UEBA provides the behavioural baselines. Anomaly rules evaluate current behaviour against those baselines and generate anomaly records in the Anomalies table.

The flow: Data → UEBA baseline engine → Anomaly rules evaluate against baselines → Anomaly records generated → Investigation priority score updated → Entity page enriched.

Peer group analysis

UEBA’s peer group comparison is one of its most powerful features. It compares a user’s behaviour not just to their own baseline, but to the baseline of similar users — same department, same role, same location.

Why peer groups matter: A finance department user who accesses 100 Excel files per day is normal for finance but anomalous for engineering. Without peer groups, UEBA cannot distinguish between “normal for this role” and “normal for this person.” The peer group baseline catches the compromised engineering account that suddenly behaves like a finance user — accessing financial systems it has never touched.

Peer group data sources: UEBA builds peer groups from Entra ID attributes synced during configuration: department, job title, office location, and manager hierarchy. The richer your Entra ID directory data, the more accurate the peer groups.

Peer group anomaly in investigation: When reviewing a UEBA entity page, the UsersInsight field shows peer group deviations. “User accessed 5x more SharePoint sites than peer group average” is a stronger signal than “User accessed 5x more SharePoint sites than personal baseline” — because the personal baseline may simply be low due to a new role, while the peer group baseline reflects normal behaviour for that role.

UEBA for insider threat detection

UEBA is particularly effective for insider threat scenarios where traditional rule-based detection struggles.

Scenario 1: Data exfiltration by departing employee. An employee who has submitted their resignation begins downloading large volumes of files from SharePoint — gradually increasing over 2 weeks. No single day triggers a threshold-based rule, but UEBA detects the sustained deviation from the employee’s baseline download volume.

Watchlist integration for insider threat. Create a watchlist called “DepartingEmployees” with columns: UserPrincipalName, LastDay, Department, AccessLevel. Populate from HR data. Cross-reference with UEBA anomalies:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

let DepartingUsers = _GetWatchlist('DepartingEmployees')
| project UPN = SearchKey,
    LastDay = todatetime(Properties.LastDay),
    AccessLevel = tostring(Properties.AccessLevel);
BehaviorAnalytics
| where TimeGenerated > ago(7d)
| where ActivityInsights has "AboveBaseline"
| join kind=inner DepartingUsers
    on $left.UserPrincipalName == $right.UPN
| where TimeGenerated < LastDay  // Activity before their last day
| summarize
    AnomalyCount = count(),
    AnomalyTypes = make_set(ActivityType, 10),
    AvgPriority = avg(InvestigationPriority)
    by UserPrincipalName, LastDay, AccessLevel
| where AnomalyCount > 3 or AvgPriority > 5
| order by AvgPriority desc

This creates a high-fidelity insider threat detection: users who are both on the departing employees list AND exhibiting above-baseline behaviour. The combination dramatically reduces false positives compared to either signal alone.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

// Find users with sustained above-baseline file access
BehaviorAnalytics
| where TimeGenerated > ago(7d)
| where ActivityType == "FileAccess" or ActivityType == "FileDownload"
| where ActivityInsights has "AboveBaseline"
| summarize
    AnomalyDays = dcount(bin(TimeGenerated, 1d)),
    TotalActivities = count()
    by UserPrincipalName, InvestigationPriority
| where AnomalyDays > 3  // Above baseline for 3+ days
| order by InvestigationPriority desc

Cross-reference with HR data (if available via a watchlist): is this user on a departing employees list?

Scenario 2: Compromised service account. A service account that normally runs automated tasks begins performing interactive operations — browsing SharePoint, accessing mailboxes, and signing in from a new IP. Service accounts have very predictable baselines, so deviations are highly significant.

Scenario 3: Privilege escalation reconnaissance. A user begins querying Active Directory for group memberships and admin accounts — behaviour typical of an attacker enumerating the environment before escalating. UEBA detects this through the IdentityQueryEvents data (if Defender for Identity is deployed) as anomalous directory query behaviour.

Entity page walkthrough

The UEBA entity page is the central investigation surface for understanding an entity’s behaviour.

Accessing entity pages: Sentinel → Entity behavior → search for a user (by UPN or display name). Alternatively, click an entity in an incident’s investigation graph to navigate directly to the entity page.

Entity page sections:

Timeline — chronological display of the entity’s activities across all data sources. Shows sign-ins, file access, administrative actions, and any anomalies detected. Filter by time range and activity type.

Insights — key behavioural metrics: total sign-in locations in the last 30 days, most used applications, typical active hours, peer group comparison. These establish the “normal” that anomalies deviate from.

Anomalies — list of all anomaly detections for this entity, with timestamps, descriptions, and confidence scores. Sort by score to see the most significant anomalies first.

Related incidents — all Sentinel incidents involving this entity, regardless of which analytics rule generated them. This cross-incident view reveals patterns: an entity appearing in 5 incidents over 2 weeks suggests a sustained compromise, not isolated events.

Investigation priority score — the aggregate score (0-10) with the contributing factors broken down. A score of 8/10 might be composed of: 3 points from anomalous sign-in location, 2 points from first-time resource access, 2 points from above-baseline data access, and 1 point from involvement in a recent incident.

Advanced UEBA hunting queries

These queries extract maximum value from UEBA data for proactive hunting.

Find users with multiple anomaly types in 48 hours. A single anomaly may be noise. Multiple different anomaly types for the same user within a short window is a strong compromise indicator.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

BehaviorAnalytics
| where TimeGenerated > ago(48h)
| where InvestigationPriority > 3
| summarize
    AnomalyTypes = dcount(ActivityType),
    AnomalyList = make_set(ActivityType, 10),
    MaxPriority = max(InvestigationPriority),
    AnomalyCount = count()
    by UserPrincipalName
| where AnomalyTypes > 2  // Multiple different anomaly types
| order by MaxPriority desc

A user with AnomalyTypes = 4 (anomalous location + first-time app + above-baseline data access + unusual time) has a very high probability of being compromised — investigate immediately.

Identify entities whose priority score spiked recently. Detect entities that were previously low-risk but have suddenly become high-risk.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

let RecentScores = BehaviorAnalytics
| where TimeGenerated > ago(24h)
| summarize CurrentMaxPriority = max(InvestigationPriority) by UserPrincipalName;
let HistoricalScores = BehaviorAnalytics
| where TimeGenerated between(ago(30d) .. ago(24h))
| summarize HistoricalMaxPriority = max(InvestigationPriority) by UserPrincipalName;
RecentScores
| join kind=inner HistoricalScores on UserPrincipalName
| where CurrentMaxPriority > HistoricalMaxPriority + 3
| extend ScoreIncrease = CurrentMaxPriority - HistoricalMaxPriority
| project UserPrincipalName, CurrentMaxPriority, HistoricalMaxPriority, ScoreIncrease
| order by ScoreIncrease desc

A score increase of 3+ points in 24 hours indicates a significant behavioural change — either a compromised account or a major legitimate change (new role, new project).

Service account anomaly detection. Service accounts should have nearly zero behavioural variance. Any anomaly is highly suspicious.

1
2
3
4
5
6
7
8

let ServiceAccounts = _GetWatchlist('ServiceAccounts') | project UPN = SearchKey;
BehaviorAnalytics
| where TimeGenerated > ago(7d)
| where UserPrincipalName in (ServiceAccounts)
| where InvestigationPriority > 1  // Any anomaly is significant for service accounts
| project TimeGenerated, UserPrincipalName, ActivityType,
    ActivityInsights, SourceIPAddress, InvestigationPriority
| order by InvestigationPriority desc

Peer group outlier detection. Find users who are extreme outliers compared to their peer group.

1
2
3
4
5
6

BehaviorAnalytics
| where TimeGenerated > ago(24h)
| where UsersInsight has "PeerGroupOutlier" or UsersInsight has "SignificantDeviation"
| project TimeGenerated, UserPrincipalName, ActivityType,
    UsersInsight, InvestigationPriority
| order by InvestigationPriority desc

UEBA operational playbook

Integrate UEBA checks into standard operational procedures.

During incident triage (every incident): Check the primary entity’s investigation priority score. If score > 5, add a comment: “UEBA priority: [score]/10. Recent anomalies: [list].” This context accelerates the analyst’s assessment of whether the incident is likely a true positive.

Weekly UEBA hunting session (1 hour). Run the multi-anomaly-type query above. For each entity with 3+ anomaly types: review the entity page, check for related incidents, and determine whether investigation is warranted. Document findings in hunting bookmarks.

After UEBA-assisted investigation (feedback loop). When UEBA data contributes to identifying a true positive (the priority score helped the analyst prioritise correctly) or a false positive (the anomaly was legitimate), document this. Over time, this feedback helps you calibrate: which UEBA anomaly types are most predictive of real threats in your environment, and at what priority score threshold should you always investigate?

UEBA data retention and performance

UEBA data is stored in the BehaviorAnalytics and Anomalies tables. These tables follow the workspace retention settings (Module 7.5). For effective behavioural comparison, retain at least 90 days of UEBA data — this allows the system to compare current behaviour against a meaningful historical baseline.

Performance impact: UEBA processing runs in the background and does not directly affect analytics rule execution or query performance. However, UEBA increases the total data volume in the workspace (the BehaviorAnalytics table can generate significant volume in large environments). Monitor this table’s contribution to daily ingestion with the Usage query from Module 8.10.

UEBA limitations

Not all anomalies are threats. A user who changes roles, starts a new project, or returns from holiday will exhibit “anomalous” behaviour that is entirely legitimate. UEBA detects deviations — it cannot distinguish between malicious and benign deviations. The analyst must interpret the context.

Baseline quality depends on data quality. If Entra ID attributes are incomplete (many users without department or job title), peer group analysis is ineffective. If data connectors have gaps (periods without data), baselines are inaccurate.

New employees have no baseline. Users who joined the organisation less than 14-21 days ago have insufficient history for meaningful anomaly detection. UEBA effectively does not cover them until baselines are established.

UEBA is probabilistic, not deterministic. A high investigation priority score indicates unusual behaviour, not confirmed malice. Treat UEBA output as a signal that warrants investigation — not as evidence of compromise.

Integrating UEBA into the SOC workflow

Shift-start UEBA review. Add a step to the shift-start routine: check the top 5 entities by investigation priority. If any score exceeds 7, perform a brief (10-minute) review of their anomalies and recent activity.

Incident enrichment SOP. For every High-severity incident, check the involved entities’ UEBA pages. Document the investigation priority score and any anomalies in the incident notes. If UEBA shows the entity was behaving anomalously before the alert fired, the incident is likely a genuine compromise — escalate accordingly.

UEBA-driven hunting. Dedicate 1 hour per week to reviewing UEBA anomalies that did not generate analytics rule incidents. These are the threats that bypass rule-based detection — exactly the kind of activity that proactive hunting (Module 10) is designed to find.

You can create scheduled analytics rules that query the Anomalies or BehaviorAnalytics tables to create incidents from UEBA detections:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

// Create incidents for users with anomalous first-time resource access
// combined with unusual sign-in location
BehaviorAnalytics
| where TimeGenerated > ago(1h)
| where ActivityType == "ResourceAccessed"
| where ActivityInsights has "FirstTimeResource"
| where UsersInsight has "AnomalousLocation"
| project TimeGenerated, UserPrincipalName, SourceIPAddress,
    ActivityInsights, UsersInsight, InvestigationPriority
| where InvestigationPriority > 5

This rule creates incidents when a user accesses a resource for the first time AND is signing in from an anomalous location — a strong indicator of compromised credentials being used by an attacker unfamiliar with the victim’s normal access patterns.

Knowledge check