What Is UEBA?

Microsoft Sentinel's BehaviorAnalytics table stores an integer called InvestigationPriority, scored 0 to 10, where 0 is benign and 10 is highly anomalous. That integer is the whole promise and the whole problem of UEBA in one field.

User and Entity Behavior Analytics answers a question a detection rule cannot phrase. A rule asks whether an event matches a pattern: does this command line contain -enc, did this account authenticate to ADMIN$. UEBA asks whether an event matches this account's own history. Nothing in svc_backup reading 40,000 files is malicious in isolation. It is only interesting because svc_backup has read 40,000 files at 02:00 every night for a year and read them at 14:00 today from a workstation subnet.

What a baseline is actually built from

A baseline is not one model. It is a set of per-feature counters, each with its own lookback window, keyed by entity.

Sentinel makes this visible. Its ActivityInsights enrichments each declare a baseline length in days. FirstTimeUserConnectedFromCountry uses a 90 day lookback. CountryUncommonlyConnectedFromByUser uses 10 days. Same entity, same feature family, two different windows, because "never before" and "rare lately" are different questions.

When a vendor says "machine learning", the mechanics underneath are usually less exotic than the word implies. For each entity and each feature, the engine keeps a frequency distribution over a window, then scores a new observation by how far into the tail it falls. Clustering or a gradient-boosted model may sit on top. The features are still counts, histograms and set-membership tests.

Peer groups

An account with no history has no baseline. The workaround is to score it against accounts that look like it: same OU, same manager, same security groups, same job title from HR.

Entra ID Protection's atypical travel detection ignores "locations regularly used by other users in the organization" when deciding whether travel is impossible. That is peer-group suppression, and it is why a whole office relocating to a conference city produces fewer alerts than one user doing it.

Peer groups fail where org structure lies. A contractor in the same OU as full-time staff, a shared admin account used by four people, and a helpdesk group whose members have wildly different daily volumes all produce peers that are not peers.

The window length problem

Pick the window and you pick your failure mode.

• Short window (7 to 14 days). Cheap to compute, adapts fast to role changes, and blind to anything monthly. A quarter-close finance job or a monthly patch run never appears in a 10 day baseline, so it is anomalous every single time it runs.

• Long window (90 days and up). Sees seasonality, and takes three months to forget a compromise. A promotion or a team transfer generates alerts for weeks after the change is legitimate.

No single window is correct for both. The practical answer is per-feature windows plus an explicit re-baseline hook when HR data says an account changed roles.

What actually gets scored

Five feature families cover most of what shipping UEBA products compute.

1. Volume. Events per entity per window against its own distribution. File reads, mail sends, 4769 service ticket requests, API calls.

2. Timing. Hour-of-day and day-of-week histograms. Weak on its own, strong when the account is a service account with a cron-shaped profile.

3. Location. Source IP, ASN, country, device, browser, tenant IP subnet. Entra's unfamiliar sign-in properties detection uses exactly that property set.

4. Resource novelty. First contact between an entity and an object. First time this user opened this share, this mailbox, this bucket, this admin cmdlet.

5. Sequence. Order of operations. Enumerate, read, stage, archive, upload. Sequence is the most useful family and the least commonly implemented, because it needs correlated events rather than counters.

Four shapes and the telemetry each needs

Impossible travel. Two authentications from geographically distant locations, closer together in time than travel allows. Entra ID Protection ships two separate detections here: atypical travel, calculated offline with riskEventType unlikelyTravel, and impossible travel with riskEventType mcasImpossibleTravel, which originates in Defender for Cloud Apps. Telemetry needed is sign-in logs with a source IP and a reliable geolocation. This false-positives on VPNs because the egress IP, not the user, decides the country. A split-tunnel client that sends Exchange traffic direct and SharePoint traffic through a concentrator in Frankfurt will produce two countries for one person sitting still. Mobile carrier CGNAT that geolocates to the carrier's core site does the same. Microsoft documents that the atypical travel algorithm suppresses known VPNs, with an initial learning period of the earliest of 14 days or 10 logins per user.

First-time access to a sensitive share. Telemetry is Windows event ID 5145 (a network share object was checked to see whether the client can be granted desired access), which carries ShareName and RelativeTargetName, or 4663 where a SACL is set on the directory. Both require audit policy that is off by default, and 5145 is one of the highest-volume events on a file server. This one is cheap to reason about and expensive to collect.

A service account behaving interactively. Telemetry is 4624 with LogonType. A service account's baseline is LogonType 3 and 5. An operator or an attacker with the credential produces 2, 10 or 11. We wrote this one as a deterministic rule rather than a score, because the baseline is known in advance and does not need learning:

title: Interactive logon by a service account
id: 5c0f9f1a-6b3f-4c7e-9a51-2f7d0f5c9a41
status: experimental
description: Detects interactive, remote interactive or cached interactive logon
    by an account matching the service account naming convention.
logsource:
    product: windows
    service: security
detection:
    selection:
        EventID: 4624
        LogonType:
            - 2
            - 10
            - 11
        TargetUserName|startswith: 'svc_'
    filter_machine:
        TargetUserName|endswith: '$'
    condition: selection and not filter_machine
falsepositives:
    - Break-glass maintenance where an engineer signs in as the service account
    - Scheduled task testing performed under the service identity
    - Environments where the svc_ prefix is not enforced, which silently voids the rule
level: medium

What it catches: any console, RDP or cached-credential logon for an account whose name starts with svc_. What it misses: every service account that does not follow the naming convention, and every case where the attacker uses LogonType 3 only. The naming dependency is the real weakness. A group-membership lookup is stronger, and Sigma cannot express it.

Off-hours volume spikes. Telemetry is anything with a timestamp and an actor. The trap is timezone. Score in UTC against a user whose baseline was built in local time and you will alert the whole company twice a year at DST transitions.

Why teams switch it off

Three failure modes account for most of the abandoned deployments we have seen described publicly.

Poisoned baselines. If dwell time exceeds the lookback window, the attacker's activity is the baseline. A 90 day feature window trained during an intrusion that started 120 days ago has learned the attacker's hours, hosts and source ASNs as normal. The engine will then flag the incident responders instead. Nothing in the product tells you this happened.

Unexplainable scores. InvestigationPriority 8 with no feature attribution cannot be triaged and cannot be tuned. An analyst who cannot see which feature moved has two options, close it or escalate it, and will pick whichever is cheaper. Tuning is worse, because you cannot suppress a contributing feature you cannot name. Sentinel's approach is the pattern to demand: the score ships alongside the ActivityInsights key-value pairs that produced it, so the alert says which enrichment fired and over what baseline.

Cold start. New accounts have no history, and the honest products disable detections until they do. Entra's unfamiliar sign-in properties detection puts newly created users into a learning mode with a documented minimum of five days. The detail that matters for hunting: Microsoft states a user can go back into learning mode after a long period of inactivity. Dormant accounts are exactly what attackers reuse, and they come back with that detection turned off.

Where the output belongs

UEBA is a hunting input and a risk multiplier. It is a poor standalone alert source.

As a hunting input, the score narrows the field. Start a hunt from the top of the anomaly distribution and work down, rather than starting from a hypothesis and querying everything:

BehaviorAnalytics
| where TimeGenerated > ago(7d)
| where InvestigationPriority >= 8
| extend NewCountry = tostring(ActivityInsights.FirstTimeUserConnectedFromCountry)
| where NewCountry == "True"
| project TimeGenerated, UserPrincipalName, ActivityType, ActionType,
          SourceIPAddress, SourceIPLocation, InvestigationPriority, ActivityInsights

As a risk multiplier, join the score to a deterministic detection and use it to set severity, not to fire. A 4624 LogonType 10 to a domain controller is worth looking at. The same event for an account carrying a 9 goes to the top of the queue. The deterministic rule stays accountable for the true positive, and the score only decides the order. That division is why detection rules and behavioral scoring are complements rather than competitors, and why the identity rules in the catalog stay deterministic even where a behavioral signal exists for the same activity.

ATT&CK techniques these shapes touch

Summary

UEBA scores deviation from an entity's own history using per-feature counters over per-feature windows, not a single model. The failure modes are structural rather than accidental: a baseline is only as clean as the period it trained on, a score without feature attribution cannot be triaged or tuned, and every new or dormant account starts blind. Treat the output as a ranking signal over deterministic detections and it earns its licence cost. Treat it as an alert source and it will fill a queue with numbers nobody can explain.

Collect these before turning any of it on:

Windows Security
  4624  Logon (LogonType, TargetUserName, IpAddress, WorkstationName)
  4625  Failed logon
  4768  Kerberos TGT requested
  4769  Kerberos service ticket requested
  5140  Network share object accessed
  5145  Network share object access check (ShareName, RelativeTargetName)
  4663  Object access attempt (requires SACL)

Microsoft Entra ID
  SigninLogs                    IPAddress, Location, AppDisplayName, ClientAppUsed
  AADNonInteractiveUserSignInLogs
  AuditLogs

Microsoft Sentinel UEBA
  BehaviorAnalytics             InvestigationPriority, ActivityInsights,
                                UsersInsights, DevicesInsights
  IdentityInfo