Microsoft Sentinel UEBA and Behavioral Analytics – SC-200 Study Guide

Purpose of This Lesson

This lesson explains how to implement User and Entity Behavior Analytics, commonly called UEBA, in Microsoft Sentinel.

UEBA helps Microsoft Sentinel detect suspicious activity that may not match a simple rule-based detection. Instead of only looking for obvious indicators like repeated failed sign-ins, known malware, or specific attack signatures, UEBA builds behavioral baselines for users, devices, identities, and other entities. When activity deviates from the normal pattern, Sentinel can identify it as anomalous or risky.

For the SC-200: Microsoft Security Operations Analyst exam, UEBA matters because it connects several core SOC responsibilities:

• Detecting unusual user or entity behavior
• Investigating identity-based threats
• Reviewing anomalies and entity context
• Prioritizing risky activity
• Using Microsoft Sentinel analytics and KQL
• Understanding how Microsoft security data sources feed detection logic

In a real SOC, UEBA is useful for detecting compromised accounts, insider threats, suspicious sign-ins, impossible travel-style scenarios, abnormal application access, unusual privilege activity, and behavior that would otherwise be difficult to detect with static rules alone.

---

Key Concepts

What Is UEBA?

UEBA stands for User and Entity Behavior Analytics.

In Microsoft Sentinel, UEBA analyzes activity patterns for users, devices, and identities. It looks for deviations from expected behavior and helps surface anomalies that may indicate a security threat.

Traditional detection logic often asks:

Did this specific event happen?

UEBA asks a more contextual question:

Is this activity unusual for this user, device, identity, or entity?

That distinction is important. A sign-in from Poland may not be suspicious for every organization or every user. But if a specific user normally signs in from New York during business hours and suddenly signs in from Poland at 3:30 AM using a different device and accessing unfamiliar applications, that becomes much more suspicious.

---

Rule-Based Detection vs Behavioral Analytics

Rule-based detections are still important, but they usually depend on known patterns.

Examples of rule-based detections include:

• Multiple failed sign-in attempts
• Known malicious IP address
• Malware detected on an endpoint
• Suspicious PowerShell command
• Privilege escalation event
• Impossible travel alert
• Known phishing URL

Behavioral analytics adds another layer by evaluating whether the activity is abnormal compared to the entity’s baseline.

Detection Type	Focus	Example
Rule-based detection	Known pattern or condition	Alert when a user has 20 failed sign-ins in 10 minutes
Behavioral analytics	Deviation from normal behavior	Alert when a user signs in from a new country at an unusual time and accesses unfamiliar resources

For SC-200, remember that UEBA does not replace analytics rules, threat intelligence, Microsoft Defender XDR, or KQL hunting. It enriches detection and investigation by adding behavioral context.

---

What UEBA Looks At

UEBA builds context around entities such as:

• Users
• Devices
• Identities
• IP addresses
• Applications
• Cloud resources
• Sign-in locations
• Time-of-day activity
• Access patterns
• Privilege-related behavior

This helps Microsoft Sentinel identify behavior that is technically allowed but still suspicious.

For example, a successful sign-in may not be malicious by itself. But if the sign-in comes from a new geography, outside normal hours, from an unfamiliar device, and is followed by attempts to access Azure resources or elevate privileges, the risk level increases.

---

Example UEBA Scenario

A user normally behaves like this:

• Signs in from New York
• Uses Windows 11
• Accesses Microsoft Teams and SharePoint
• Works between 8:00 AM and 6:00 PM
• Uses the same managed corporate device

Then suddenly, Sentinel observes:

• A sign-in from Poland
• Activity at 3:30 AM
• Access to Azure resources
• A different or unfamiliar device
• Follow-up activity involving privilege escalation attempts

UEBA can evaluate this as anomalous because several parts of the activity differ from the user’s normal baseline.

This is exactly the kind of scenario Microsoft wants security analysts to understand for SC-200: the event may not be suspicious because of one single signal, but because multiple contextual signals combine into an abnormal behavior pattern.

---

Implementing UEBA in Microsoft Sentinel

UEBA can be enabled from the Microsoft Defender portal experience for Microsoft Sentinel.

General navigation flow:

1. Go to security.microsoft.com
2. Open System
3. Go to Settings
4. Select Microsoft Sentinel
5. Choose the appropriate Sentinel workspace
6. Open Entity behavioral analytics
7. Select Configure UEBA
8. Enable UEBA
9. Sync Sentinel with a supported directory service
10. Select relevant data sources
11. Connect the configuration

The exact portal wording may change over time, but the core concept is that UEBA is enabled at the Microsoft Sentinel workspace level and depends on identity and activity data being available.

---

Permissions Required to Enable UEBA

The lesson highlights that only certain privileged roles can enable or disable UEBA.

Relevant roles include:

• Global Administrator
• Security Administrator

This is exam-relevant because Microsoft often tests role-based access and administrative boundaries. If a user cannot enable UEBA, the issue may not be technical configuration. It may be a permissions problem.

---

Directory Services Used by UEBA

UEBA requires Sentinel to synchronize with a directory service.

Common directory sources include:

• Microsoft Entra ID, formerly Azure Active Directory
• On-premises Active Directory, when integrated or synchronized into the Microsoft identity environment

For most cloud-first Microsoft environments, Microsoft Entra ID is the main identity source.

In hybrid environments, on-premises Active Directory activity may also be important because identity compromise often spans both cloud and traditional domain infrastructure.

---

Data Sources for Behavioral Analytics

UEBA becomes useful when Sentinel has the right data to analyze.

Examples of relevant data sources include:

• Microsoft Entra ID sign-in logs
• Microsoft Entra ID audit logs
• Azure Activity logs
• Microsoft Defender data
• Endpoint telemetry
• Identity-related logs
• Cloud activity logs

The important SC-200 concept is this:

Microsoft Sentinel can only analyze behavior based on the data it receives.

If a data connector is not enabled, Sentinel may not have the visibility needed to detect or investigate certain behavior.

---

Anomaly Rules in Microsoft Sentinel

After UEBA is enabled, Microsoft Sentinel provides anomaly-related detection content.

In Microsoft Sentinel, these can be reviewed under:

Microsoft Sentinel → Configuration → Analytics → Anomalies

Anomaly rules help detect unusual behavior based on Microsoft’s built-in analytics. Many anomaly templates are available and may already be enabled.

Examples of anomaly detections may include:

• Anomalous sign-in behavior
• Suspicious access patterns
• Unusual entity activity
• User behavior that deviates from normal baseline
• Activity associated with credential theft or misuse

These anomaly detections can be enabled, disabled, reviewed, or used as part of investigation workflows.

---

The Anomalies Table

The lesson notes that anomaly output can be queried in the Microsoft Sentinel workspace using KQL.

The relevant table for these anomaly results is commonly referenced as the Anomalies table.

This matters because a SOC analyst may need to:

• Review recent anomalies
• Filter anomalies by severity
• Search anomalies for a specific user or entity
• Correlate anomalies with incidents, sign-ins, audit logs, or other telemetry
• Use anomaly data during hunting or investigation

---

Microsoft Security Operations Context

How UEBA Fits into a SOC Workflow

UEBA is most useful when an analyst needs context beyond a single alert.

A basic alert might say:

User signed in successfully.

UEBA helps answer:

• Is this location normal for the user?
• Is this time of day normal?
• Is this device familiar?
• Is the application access expected?
• Is the user attempting something unusual after sign-in?
• Has this user recently shown other risky behavior?
• Are other entities involved?

This helps the analyst determine whether an alert is likely a false positive, a compromised identity, insider activity, or part of a larger attack.

---

Triage Workflow Using UEBA

A SOC analyst might use UEBA during triage like this:

1. Review the incident or alert
   • Start with the incident in Microsoft Sentinel or Microsoft Defender XDR.
   • Identify the affected user, device, IP address, or application.
2. Review entity context
   • Check the user entity, device entity, IP address, and related activity.
   • Look for unfamiliar locations, devices, applications, or access patterns.
3. Check behavioral anomalies
   • Review UEBA/anomaly insights.
   • Look for unusual sign-in time, new geography, abnormal resource access, or privilege-related activity.
4. Determine scope
   • Search for additional activity by the same user, source IP, device, or application.
   • Look across sign-in logs, audit logs, Azure Activity, and related tables.
5. Contain or escalate
   • Disable account, revoke sessions, require password reset, isolate endpoint, or escalate to identity/cloud teams depending on the evidence.
6. Document findings
   • Record what was abnormal, what entities were involved, what evidence supported the conclusion, and what response action was taken.
7. Improve detection
   • Tune analytics rules, create hunting queries, add automation, or adjust data connectors if visibility gaps are found.

---

UEBA and Identity-Based Threats

UEBA is especially useful for identity-focused security operations.

Common identity-based threats include:

• Compromised user accounts
• Credential theft
• Suspicious sign-ins
• Privilege escalation
• Unusual application access
• Insider threats
• Abnormal administrative activity
• Lateral movement using valid credentials

Attackers often use legitimate credentials after compromise. That means their activity may not immediately look malicious to a simple rule. Behavioral analytics helps identify when the activity is abnormal for that specific identity.

---

UEBA and Insider Threat Detection

Insider threats can be difficult to detect because the user may already have legitimate access.

UEBA helps by identifying activity that is unusual for that user or role, such as:

• Accessing resources they normally do not use
• Logging in at unusual hours
• Accessing sensitive systems from unfamiliar locations
• Performing administrative actions outside their normal pattern
• Attempting privilege changes
• Using unusual applications or services

UEBA does not automatically prove malicious intent. It provides investigation leads that analysts must validate.

---

UEBA and False Positive Reduction

UEBA can help reduce false positives because it adds context.

For example, a sign-in from a foreign country may be normal for a traveling executive but highly abnormal for a local-only employee. Behavioral analytics helps evaluate activity against the entity’s own baseline rather than treating every event the same way.

However, UEBA does not eliminate false positives. Analysts still need to validate:

• Whether the user was traveling
• Whether the device was expected
• Whether the application access was legitimate
• Whether the activity aligns with business context
• Whether other indicators confirm compromise

---

Exam-Relevant Takeaways

For SC-200, remember the following:

• UEBA stands for User and Entity Behavior Analytics.
• UEBA detects suspicious activity by comparing current behavior against normal behavior.
• UEBA is useful for detecting compromised accounts, insider threats, unusual sign-ins, and abnormal access patterns.
• Microsoft Sentinel needs connected data sources before it can analyze behavior effectively.
• UEBA depends heavily on identity and activity logs, especially Microsoft Entra ID logs.
• Microsoft Entra ID was formerly called Azure Active Directory.
• UEBA can use cloud identity data and, in hybrid environments, on-premises Active Directory context.
• Enabling UEBA requires privileged permissions, such as Global Administrator or Security Administrator.
• Anomaly detections can be reviewed in Microsoft Sentinel under Analytics → Anomalies.
• Anomaly results can be queried with KQL.
• UEBA is not the same as a scheduled analytics rule, but anomaly findings can support incident detection and investigation.
• UEBA improves investigation quality by enriching entities with behavioral context.
• A suspicious event is often suspicious because of context, not because of one isolated signal.

---

Tool / Feature Decision Guide

Scenario	Best Microsoft Security Tool or Feature	Why
Detect unusual user behavior compared to normal activity	Microsoft Sentinel UEBA	UEBA builds behavioral baselines and identifies deviations
Investigate sign-ins from unfamiliar locations	Microsoft Sentinel with Entra ID sign-in logs	Sign-in logs provide identity activity needed for investigation
Review built-in anomaly detections	Microsoft Sentinel Analytics → Anomalies	Anomaly templates identify suspicious behavioral patterns
Query anomaly results during investigation	KQL against the Anomalies table	Allows analysts to filter and correlate anomaly findings
Detect a known malicious IP address	Analytics rule or threat intelligence matching	Known indicators are better suited for rule or TI-based detection
Investigate a user, device, or IP involved in an alert	Entity investigation in Microsoft Sentinel or Defender XDR	Entities provide context and relationship mapping
Respond to suspicious identity behavior	Microsoft Entra ID and Microsoft Defender XDR response actions	Actions may include disabling account, resetting password, or revoking sessions
Detect endpoint compromise	Microsoft Defender for Endpoint	Endpoint telemetry and response actions are handled by Defender for Endpoint
Correlate security data from many sources	Microsoft Sentinel	Sentinel is the SIEM/SOAR platform for cross-source detection and investigation
Investigate incidents across Microsoft Defender workloads	Microsoft Defender XDR	Defender XDR correlates incidents across endpoint, identity, email, and cloud apps

---

KQL Notes

The transcript mentions that anomaly data can be queried using KQL.

For the SC-200 exam, you do not need to memorize every possible query, but you should understand how KQL helps analysts search, filter, and investigate security data in Microsoft Sentinel.

Example: Review Recent Anomalies

Anomalies
| where TimeGenerated > ago(24h)
| project TimeGenerated, AnomalyName, Description, Tactics, Techniques, Entities
| order by TimeGenerated desc

What This Query Does

Query Part	Purpose
Anomalies	Searches the anomaly results table
where TimeGenerated > ago(24h)	Limits results to the last 24 hours
project	Displays only the columns most useful for review
order by TimeGenerated desc	Shows the newest anomalies first

Example: Search for Anomalies Related to a User

Anomalies
| where TimeGenerated > ago(7d)
| where Entities has "user@domain.com"
| project TimeGenerated, AnomalyName, Description, Entities
| order by TimeGenerated desc

Investigation Use

This type of query helps an analyst determine whether a specific user has been associated with recent anomalous activity.

In a real investigation, this could be used alongside:

• Sign-in logs
• Audit logs
• Azure Activity logs
• Defender XDR incident evidence
• Entity pages
• Identity risk signals

KQL Concepts to Remember

KQL Concept	Why It Matters
where	Filters data to reduce noise
ago()	Searches within a recent time window
project	Selects useful columns for investigation
order by	Sorts results, often by newest events first
has	Searches for a value inside text or dynamic fields
Tables	Sentinel stores different types of logs in different tables

For SC-200, focus on understanding what a query is trying to find and how filters narrow the results.

---

Common Exam Traps

Confusing UEBA with Basic Analytics Rules

UEBA detects deviations from normal behavior. A scheduled analytics rule usually runs a defined KQL query on a schedule to detect specific patterns.

Both can contribute to detection, but they are not the same thing.

---

Forgetting That Sentinel Depends on Data Connectors

UEBA cannot analyze data that Sentinel does not receive.

If the scenario says sign-in logs or audit logs are not connected, the best answer may involve enabling the correct data connector first.

---

Confusing Microsoft Entra ID with Azure AD

Microsoft Entra ID is the current name for Azure Active Directory.

Exam questions may still reference Azure AD in older terminology, labs, screenshots, or legacy portal text.

---

Assuming One Anomaly Equals Confirmed Compromise

An anomaly is not automatic proof of malicious activity.

A user signing in from a new location could mean:

• The account is compromised
• The user is traveling
• A VPN is involved
• A conditional access change occurred
• A new device or app is being used legitimately

The analyst must investigate and validate.

---

Choosing a Response Action Too Early

For identity anomalies, avoid jumping straight to broad tenant-wide actions unless the scope supports it.

A better investigation sequence is usually:

1. Review the alert or anomaly
2. Inspect entities
3. Check related logs
4. Determine scope
5. Take targeted containment action
6. Document and escalate as needed

---

Confusing Microsoft Defender XDR and Microsoft Sentinel

Microsoft Defender XDR is focused on correlated incidents across Microsoft Defender workloads.

Microsoft Sentinel is the SIEM/SOAR platform that collects data from Microsoft and non-Microsoft sources, supports KQL analytics, hunting, workbooks, automation, and broader log correlation.

For UEBA in this lesson, the key platform is Microsoft Sentinel.

---

Real-World SOC Analyst Notes

UEBA Is Best Used as Context, Not a Standalone Verdict

Behavioral analytics is powerful, but it should be treated as investigation context. Analysts should correlate UEBA findings with other evidence before declaring an incident.

Useful supporting evidence may include:

• Successful and failed sign-ins
• MFA prompts
• Conditional Access results
• Device compliance state
• Endpoint alerts
• Azure Activity operations
• Privilege changes
• Mailbox access
• Data downloads
• Defender XDR incident evidence

---

Alert Fatigue Still Matters

UEBA can reduce some false positives, but it can also produce noise if analysts do not tune and review anomaly rules.

In production, SOC teams should periodically review:

• Which anomalies are useful
• Which anomalies are noisy
• Which detections should be disabled
• Which detections should feed incidents
• Which anomalies require automation
• Which detections need business context

---

Identity Context Is Critical

Identity is often the control plane for Microsoft cloud environments. A compromised identity can lead to:

• Mailbox access
• SharePoint and OneDrive data exposure
• Azure resource manipulation
• Privilege escalation
• Persistence through app registrations or role assignments
• Lateral movement across cloud services

UEBA helps analysts spot when identity behavior does not align with the expected baseline.

---

Coordinate With the Right Teams

Depending on the anomaly, the SOC may need to coordinate with:

• Identity team
• Endpoint team
• Cloud infrastructure team
• Microsoft 365 administrators
• Messaging/email security team
• Governance, risk, and compliance teams
• HR or legal for insider threat scenarios

For example, if UEBA flags suspicious privilege escalation attempts in Azure, the SOC may need help from the cloud engineering or identity team to validate permissions and determine whether role assignments were legitimate.

---

Automation Safety

UEBA can support automation, but response actions should be carefully scoped.

Safe automation examples:

• Create an incident
• Add tags
• Assign severity
• Notify SOC channel
• Enrich incident with entity details
• Run a playbook to collect context

Higher-risk automation examples:

• Disable user accounts
• Revoke sessions
• Block IP addresses
• Isolate devices
• Modify Conditional Access behavior

These actions may be appropriate, but they should be tested and controlled because they can affect business operations.

---

Cost and Data Retention Considerations

Microsoft Sentinel costs are often tied to data ingestion and retention. UEBA is only valuable when the right data is connected, but collecting more data can increase cost.

SOC teams should balance:

• Required visibility
• Detection value
• Retention needs
• Compliance requirements
• Investigation requirements
• Cost impact

For SC-200, remember that data connectors and log availability directly affect what Sentinel can detect and investigate.

---

Quick Reference Summary

• UEBA means User and Entity Behavior Analytics.
• UEBA detects abnormal behavior by comparing current activity to historical baselines.
• It helps find suspicious behavior that static rules may miss.
• Useful for compromised accounts, insider threats, unusual sign-ins, and abnormal access patterns.
• UEBA can consider location, time, device, application, identity, and access behavior.
• Microsoft Sentinel must have the right data connectors enabled.
• Microsoft Entra ID sign-in and audit logs are important for identity-based analytics.
• UEBA is configured at the Sentinel workspace level.
• Enabling UEBA requires appropriate admin permissions.
• Built-in anomaly detections can be reviewed under Sentinel Analytics → Anomalies.
• Anomaly results can be queried with KQL.
• An anomaly is a lead for investigation, not automatic proof of compromise.
• In a SOC workflow, UEBA helps with triage, entity review, scoping, containment, and detection improvement.

---

Flashcards

Q: What does UEBA stand for?
A: User and Entity Behavior Analytics.

Q: What is the main purpose of UEBA in Microsoft Sentinel?
A: To detect unusual or risky behavior by comparing current activity against normal baselines for users, devices, identities, and other entities.

Q: Why can UEBA detect threats that simple rule-based alerts might miss?
A: Because it looks for abnormal behavior patterns rather than only known bad events or static conditions.

Q: What is an example of UEBA detecting suspicious behavior?
A: A user who normally signs in from New York during business hours suddenly signs in from another country at 3:30 AM and accesses unfamiliar Azure resources.

Q: Which Microsoft product is the main SIEM/SOAR platform where UEBA is implemented?
A: Microsoft Sentinel.

Q: What identity service is commonly used with Sentinel UEBA?
A: Microsoft Entra ID, formerly Azure Active Directory.

Q: What permissions may be required to enable UEBA?
A: Global Administrator or Security Administrator.

Q: Where can anomaly rules be reviewed in Microsoft Sentinel?
A: Microsoft Sentinel → Configuration → Analytics → Anomalies.

Q: Why are data connectors important for UEBA?
A: Sentinel can only analyze behavior based on the data it receives.

Q: Is an anomaly automatically proof of compromise?
A: No. An anomaly is a signal that requires investigation and correlation with other evidence.

Q: What KQL table can be used to query anomaly results mentioned in the lesson?
A: The Anomalies table.

Q: What is the difference between UEBA and a scheduled analytics rule?
A: UEBA identifies deviations from behavioral baselines, while scheduled analytics rules run defined KQL logic on a schedule.

Q: Why is UEBA useful for insider threat detection?
A: It can identify unusual activity by users who may already have legitimate access.

Q: What should an analyst do after seeing a suspicious UEBA anomaly?
A: Review the involved entities, check related logs, determine scope, validate the behavior, and take appropriate response action.

Q: What is a common SC-200 trap related to UEBA?
A: Treating an anomaly as confirmed compromise without investigating context and supporting evidence.

---

Practice Questions

Question 1:

A user normally signs in from New York during business hours and accesses SharePoint and Teams. Microsoft Sentinel detects a sign-in from Poland at 3:30 AM from an unfamiliar device, followed by attempts to access Azure resources. Which Sentinel capability is best suited to identify this type of abnormal pattern?

A. Watchlists
B. UEBA
C. Microsoft Defender for Office 365 Safe Attachments
D. Azure Policy

Correct Answer:
B. UEBA

Explanation:
UEBA detects unusual behavior by comparing current activity against normal baselines for users, devices, and identities. The scenario includes abnormal geography, time, device, and application access.

---

Question 2:

You want Microsoft Sentinel to identify suspicious behavior based on Microsoft Entra ID sign-in activity. What must be true for Sentinel to analyze that activity?

A. Microsoft Defender for Endpoint must be disabled
B. The relevant data connector must be enabled
C. The user must be a Global Administrator
D. All alerts must be manually created

Correct Answer:
B. The relevant data connector must be enabled

Explanation:
Sentinel depends on connected data sources. If sign-in logs are not being ingested, Sentinel cannot use that data for analytics, hunting, or investigation.

---

Question 3:

A SOC analyst sees a Microsoft Sentinel anomaly involving a user signing in from a new location. What should the analyst do first?

A. Immediately delete the user account
B. Disable all Conditional Access policies
C. Review entity context and related sign-in activity
D. Ignore the anomaly because anomalies are always false positives

Correct Answer:
C. Review entity context and related sign-in activity

Explanation:
An anomaly is an investigation lead, not automatic proof of compromise. The analyst should review the user entity, sign-in details, device, location, and related activity before choosing a response.

---

Question 4:

Which KQL query pattern is most appropriate for reviewing recent anomaly results in Microsoft Sentinel?

A. Query the Anomalies table and filter by TimeGenerated
B. Query only the SecurityAlert table and ignore entities
C. Query AzureActivity without a time filter
D. Use a watchlist instead of querying logs

Correct Answer:
A. Query the Anomalies table and filter by TimeGenerated

Explanation:
The Anomalies table can be used to review anomaly findings. Filtering by TimeGenerated reduces noise and focuses the investigation on recent activity.

---

Question 5:

Which statement best describes the difference between UEBA and traditional rule-based detection?

A. UEBA only detects malware, while rules only detect identity threats
B. UEBA detects behavior that deviates from a baseline, while rules detect defined conditions or patterns
C. UEBA replaces all analytics rules in Microsoft Sentinel
D. UEBA only works with Microsoft Defender for Office 365

Correct Answer:
B. UEBA detects behavior that deviates from a baseline, while rules detect defined conditions or patterns

Explanation:
UEBA is behavior-based and context-aware. Traditional analytics rules usually rely on specific event patterns, thresholds, or KQL conditions.