What is UEBA?

A detection rule asks whether an event matches a pattern someone wrote down. UEBA asks whether the event is normal for this account. Only the second question helps when an attacker signs in with a real password to a real account, because nothing in the event itself is malicious. Microsoft's description of the feature in Sentinel sums up the category well: it builds "dynamic behavioral profiles for users, hosts, IP addresses, applications, and other entities" and compares current activity against them to find compromised accounts, insider attacks and lateral movement.

What a baseline is made of

Three comparisons do most of the work, and Sentinel exposes each one as its own flag:

• The user against their own history. Has this account connected from this country before, used this ISP, opened this app, touched this resource?
• The user against their peers. Sentinel builds peer groups from security group membership, mailing lists and similar associations, keeps the top 20 peers per user in the UserPeerAnalytics table, and weights them with TF-IDF so a small team counts for more than an all-staff list.
• The user against the whole tenant. Is this the first time anyone in the organization has connected from that country or run that action?

A single first-time flag is weak evidence. A country that is new for the user, that none of their peers connect from, reached through an ISP nobody in the tenant has used, is much stronger.

UEBA only sees what you feed it. In Sentinel the inputs include Entra ID sign-in and audit logs, Azure Activity, Windows security events 4624, 4625, 4648, 4672 and 4688, Defender XDR device logons, AWS CloudTrail, GCP audit logs, Okta, and firewall, VPN and proxy events from Check Point, Fortinet and Zscaler sent as CEF. If your VPN comes from another vendor, UEBA has no VPN-specific baseline unless the VPN authenticates through Entra ID.

Reading the BehaviorAnalytics table

UEBA writes its output to the BehaviorAnalytics table. Each row is one activity, such as a sign-in or an Azure operation. It carries the raw facts (UserPrincipalName, ActivityType, ActionType, SourceIPAddress, SourceIPLocation, SourceDevice, DestinationDevice) and four columns with the analytics:

The flags in ActivityInsights do not all look back the same distance. Sentinel compiles the baseline each time it is used, with a fixed lookback per flag:

Those windows explain a lot of noise. "Uncommon for this user" looks back only 10 days, so after two weeks of leave there is almost nothing in the window to compare against. The country flag looks back 90 days, so someone who visits the same client every four months gets a first-time flag on every trip.

InvestigationPriority is one of two scores. The Anomalies table has an AnomalyScore from 0 to 1, produced in batch by a machine learning model that looks across many events. Microsoft's example of the difference: a user's first Azure operation scores high on investigation priority, because it is a first, and low on anomaly score, because occasional first-time Azure actions are common. Sort single events by the 0-10 score; look for patterns over time with the anomaly score.

Identity context lives in IdentityInfo, synchronized from Entra ID and, through Defender for Identity, from on-premises Active Directory. Sentinel resynchronizes it in full every 14 days and picks up profile changes within 15 to 30 minutes, and the default retention is 30 days. Department, job title, group membership and Entra roles come from there when you need to know whether the access makes sense for that person. Microsoft suggests waiting about a week after enabling UEBA before looking for insights.

A triage query

This query pulls the last day of activity with an investigation priority of 5 or more and puts the flags an analyst reads first into their own columns. The threshold of 5 is a starting point for this example, not a Microsoft recommendation. Microsoft's own hunting queries in the UEBA Essentials solution filter on InvestigationPriority > 0 and then on specific flags.

// UEBA triage: last 24 hours, priority 5 or more, key flags as columns
BehaviorAnalytics
| where TimeGenerated > ago(1d)
| where InvestigationPriority >= 5
| extend NewCountry = ActivityInsights.FirstTimeUserConnectedFromCountry == True,
    PeersRareCountry = ActivityInsights.CountryUncommonlyConnectedFromAmongPeers == True,
    NewISP = ActivityInsights.FirstTimeUserConnectedViaISP == True,
    NewDevice = ActivityInsights.FirstTimeUserConnectedFromDevice == True,
    Dormant = UsersInsights.IsDormantAccount == True,
    TIType = tostring(DevicesInsights.ThreatIntelIndicatorType)
| project TimeGenerated, UserPrincipalName, ActivityType, ActionType, SourceIPAddress,
    SourceIPLocation, InvestigationPriority, NewCountry, PeersRareCountry, NewISP,
    NewDevice, Dormant, TIType, SourceRecordId
| order by InvestigationPriority desc, TimeGenerated desc

For a sign-in, SourceRecordId joins back to the raw event in SigninLogs on _ItemId, the same join Microsoft uses in its Anomalous Geo Location Logon hunting query. The raw event gives you the app, the MFA result and the Conditional Access outcome. The query follows Microsoft's documented schema and the syntax of its published hunting queries; SOCSimulator has not run it against a live tenant.

One row, field by field

Simulated example generated by SOCSimulator Research. The user, the ISP and the address (from the 203.0.113.0/24 documentation range) are invented; the field names are Microsoft's.

{"TimeGenerated":"2026-10-21T06:42:18Z","UserPrincipalName":"j.ramos@corp.example","ActivityType":"LogOn","ActionType":"Sign-in","SourceIPAddress":"203.0.113.47","SourceIPLocation":"Romania","InvestigationPriority":7,"UsersInsights":{"AccountDisplayName":"Julia Ramos","IsDormantAccount":"False","IsNewAccount":"False","BlastRadius":"Medium"},"DevicesInsights":{"ISP":"Example Hosting SRL","OperatingSystem":"Windows 10","UserAgentFamily":"Chrome","ThreatIntelIndicatorType":"Proxy"},"ActivityInsights":{"FirstTimeUserConnectedFromCountry":"True","CountryUncommonlyConnectedFromAmongPeers":"True","FirstTimeUserConnectedViaISP":"True","ISPUncommonlyUsedAmongPeers":"True","FirstTimeUserConnectedFromDevice":"False","BrowserUncommonlyUsedByUser":"False"}}

Read it in this order:

1. Priority 7. High enough to look at today. It says the sign-in deviates from her baseline, not that it is malicious.
2. Country and ISP. Her first sign-in from Romania in 90 days, a country her peers rarely connect from, through an ISP she has not used in 30 days. Microsoft's walkthrough of an anomalous sign-in lists these same flags among its evidence fields.
3. Device and browser. FirstTimeUserConnectedFromDevice is False and the browser is her usual one. Either she is on her own laptop on an unfamiliar network, or someone has copied enough of her setup to look like her.
4. Threat intel. The IP carries a proxy indicator. A commercial VPN produces the same tag.
5. Blast radius Medium. If the account is compromised, the damage goes beyond one mailbox.

Then join to SigninLogs and check three things: whether MFA was satisfied and by which method, which app she signed into, and what the account did in the next hour.

False positive when she is travelling (HR or the travel system confirms it), when a company or consumer VPN changed her egress point, or when her peers started connecting from the same place too. Microsoft's guidance for impossible travel follows the same path: confirm with the user, check on the user entity page whether the location is among her commonly known locations, then run the Anomalous Geo Location Logon hunting query to see whether her peers connect from there as well.

Escalate when MFA was satisfied by a method registered minutes earlier, when the sign-in is followed by a new inbox rule or a first-time admin action (FirstTimeUserPerformedAction), when the device flag turns True, or when she is badged into the office while "she" signs in from Romania.

Where UEBA fits

UEBA does not replace detection rules. A rule that fires on a known ransomware command line is faster and more precise than waiting for a behavioral score. UEBA covers what rules cannot express: valid credentials used from the wrong place, an insider reading shares their role never needed, a dormant account waking up. In Sentinel it needs no separate license and costs nothing extra, although the tables it creates are billed as ordinary Log Analytics storage. Insider threat cases and impossible travel triage are where you will use it most, and in both you treat the score as a reason to look and the raw sign-in and audit logs as the evidence.