The first time you enable a new feature in Sentinel, you usually get one of two outcomes: either nothing happens for hours, or you get a firehose and everyone panics. The UEBA Behaviors layer is different. It’s quiet at first, then it starts giving you something SOC teams rarely get for free: structure.
This post is the “how” part: onboarding, what to validate, what to watch in production, and a handful of KQL queries you can copy straight into hunting.
1) Prereqs and onboarding checklist
Enable it
You enable the Behaviors layer here:
System → Settings → Microsoft Sentinel → Your Sentinel Workspace → Entitiy behavior analytics → Configure UEBA → New! Behaviors layer
Preview limitation to keep in mind: one workspace per tenant.
Feed it the right telemetry
Behaviors don’t appear out of thin air. They’re generated from the raw sources you already ingest. In preview, Microsoft focuses heavily on multi-cloud and common third-party sources. That means the usual suspects matter:
- AWS CloudTrail
- GCP audit logs
- CommonSecurityLog (common for vendors like Palo Alto, CyberArk integrations via CEF, etc.)
Your first validation step is boring, but critical: confirm those sources actually land in the workspace you enable.
Quick sanity checks:
// AWS CloudTrail presence
AWSCloudTrail
| where TimeGenerated > ago(24h)
| summarize Events=count(), SampleOperations=make_set(EventName, 10)
// GCP audit logs presence
GCPAuditLogs
| where TimeGenerated > ago(24h)
| summarize Events=count(), SampleMethods=make_set(methodName, 10)
// CommonSecurityLog presence
CommonSecurityLog
| where TimeGenerated > ago(24h)
| summarize Events=count(), Vendors=make_set(DeviceVendor, 10)
If these tables are empty or near-empty, stop here. Fix ingestion first. Behaviors are only as good as the telemetry behind them.
2) Know what you’re looking at: behaviors are not alerts
A behavior is a neutral summary of activity. It can describe normal operations or suspicious sequences. Treat it like a well-written incident note generated from telemetry, not like a confirmed detection.
That mindset avoids two common mistakes:
- Analysts treat behaviors as “true positives” and escalate too fast.
- Teams ignore them because “it didn’t trigger an alert.”
Behaviors are best used as:
- investigation accelerators
- correlation glue across sources
- hunting pivots
- building blocks for your own detections
3) Where the data lives
You’ll work mainly with two tables:
- BehaviorInfo: the behavior itself (summary, timing, classification, mapping)
- BehaviorEntities: the entities involved (user, IP, resource, host, etc.) and their roles
So your “first day” workflow should be: list behaviors, then pivot into entities, then drill into raw logs if needed.
4) First checks after enabling: did it actually start?
Start simple: do behaviors exist?
BehaviorInfo
| where TimeGenerated > ago(24h)
| summarize Behaviors=count(), FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated)
If you get zero results after you’ve confirmed ingestion, wait for the system’s evaluation windows to close. Some behaviors appear near-real time, others materialize when a time window completes. If you still see nothing after a day of real telemetry, something’s off in ingestion scope or workspace selection.
5) What to look out for in production
Cost and ingestion
Behaviors are stored in Log Analytics and count toward ingestion. There’s no separate license fee, but there is data volume. Track it early so you don’t get surprised.
A rough way to watch behavior record volume:
union isfuzzy=true BehaviorInfo, BehaviorEntities
| where TimeGenerated > ago(7d)
| summarize Records=count() by bin(TimeGenerated, 1d), Type=$table
| order by TimeGenerated desc
If your team runs close to capacity limits, this is where you decide whether you enable preview on a “lab” workspace first.
Workspace choice
Because preview is one workspace per tenant, pick the workspace that:
- already ingests your richest multi-cloud and third-party telemetry
- represents your real operational risk
- has analysts actively hunting (otherwise the feature will just sit there)
Expectations management
Behaviors are designed to reduce correlation pain, not to replace your detections. The best early win is usually: speed up investigations for noisy incidents by giving analysts a coherent timeline.
6) Practical KQL: queries you’ll actually use
A) “Show me the most recent behaviors”
BehaviorInfo
| where TimeGenerated > ago(24h)
| project TimeGenerated, BehaviorId, Description, Severity, MitreTactics, MitreTechniques
| order by TimeGenerated desc
| take 50
B) “What entities are typically involved?”
BehaviorEntities
| where TimeGenerated > ago(24h)
| summarize Behaviors=count() by EntityType, Role
| order by Behaviors desc
This gives you a feel for what the layer is surfacing in your environment: users, IPs, cloud resources, service principals, etc.
C) “Pivot from a behavior to the involved entities”
let behaviorId = toscalar(
BehaviorInfo
| where TimeGenerated > ago(24h)
| order by TimeGenerated desc
| project BehaviorId
| take 1
);
BehaviorEntities
| where BehaviorId == behaviorId
| project TimeGenerated, BehaviorId, EntityType, EntityName, Role, AdditionalData
| order by TimeGenerated asc
D) “Find behaviors mapped to a specific MITRE tactic”
Example: Credential Access.
BehaviorInfo
| where TimeGenerated > ago(7d)
| where MitreTactics has "Credential Access"
| project TimeGenerated, Description, Severity, MitreTactics, MitreTechniques, BehaviorId
| order by TimeGenerated desc
E) “Spot multi-step sequences that deserve a closer look”
You can’t rely on one vendor’s fields here, so lean into the behavior abstraction:
BehaviorInfo
| where TimeGenerated > ago(7d)
| where Description has_any ("created", "new", "used", "privileged", "admin", "role")
| project TimeGenerated, Severity, Description, BehaviorId
| order by TimeGenerated desc
This is intentionally blunt, but it’s a great analyst-friendly starting point during the first week.
F) “Build your first detection: high-risk behavior + sensitive entity”
The idea: if a behavior involves a privileged identity, you might want an analytic rule.
Assuming you have a watchlist or table of privileged accounts, for example PrivilegedIdentities with a column AccountName:
let Privileged = materialize(PrivilegedIdentities | project AccountName);
BehaviorEntities
| where TimeGenerated > ago(24h)
| where EntityType in ("Account", "User", "ServicePrincipal")
| join kind=inner (Privileged) on $left.EntityName == $right.AccountName
| join kind=inner (
BehaviorInfo
| where TimeGenerated > ago(24h)
| project BehaviorId, Description, Severity, MitreTactics, MitreTechniques
) on BehaviorId
| project TimeGenerated, EntityName, Role, Severity, MitreTactics, Description, BehaviorId
| order by TimeGenerated desc
That’s the sort of rule that is easy to explain to leadership and easy to tune for the SOC.
7) Suggested “week 1” rollout plan
If you want this to land well internally, do it like this:
- Enable in the right workspace
- Validate ingestion (AWS/GCP/CommonSecurityLog)
- Measure volume for 7 days
- Run hunts using behaviors
- Pick 2–3 high-value scenarios
- suspicious key creation and use
- privileged API activity sequences
- unusual access patterns against sensitive resources
- Promote one scenario into an analytic rule
- Write a short SOC playbook
- what a behavior means
- how to pivot into entities
- when to escalate
- how to confirm in raw logs
Closing
The Behaviors layer is not another dashboard toy. It’s an abstraction that finally respects how SOC work actually happens: you don’t investigate single log lines, you investigate narratives.
Enable it, validate your data sources, and then do what good SOC teams do: turn new context into repeatable detections and better response.
Find part 1 here: When Logs Start Telling Stories: UEBA Behaviors in Microsoft Sentinel – M365, Azure and Security
And the Microsoft documentation here: Translate raw security logs to behavioral insights using UEBA behaviors in Microsoft Sentinel (Preview) | Microsoft Learn
Be First to Comment