5.2 Investigation, UEBA & Threat Intelligence

Investigating Beyond a Single Alert

Real investigations require context that no single alert carries. SC-200 expects you to know the three context engines Microsoft Sentinel provides: UEBA for behavioral anomalies, entity pages for a consolidated object view, and threat intelligence for known-bad correlation. Workbooks then visualize all of it.

User and Entity Behavior Analytics (UEBA)

User and Entity Behavior Analytics (UEBA) is a Sentinel feature that machine-learns a behavioral baseline for each user, host, and IP from connected data sources (sign-in logs, audit logs, security events). It then scores deviations from that baseline.

Key facts the exam tests:

• UEBA must be enabled in Sentinel settings and bound to specific data sources before it produces insights.
• UEBA does not generate its own incidents by default. It writes enrichment to the BehaviorAnalytics table and surfaces an investigation priority score and insights (for example, "first time user signed in from this country").
• You operationalize UEBA by writing analytics rules or hunting queries against BehaviorAnalytics, or by reading its insights on the entity page.

Entity Pages

An entity page is a dedicated, timeline-driven profile for a single Account, Host, IP, or Azure resource. From any alert, incident, or graph node you can drill into the entity page to see, in one place:

• All alerts and incidents involving the entity
• A behavioral timeline of activities
• UEBA insights and the investigation priority score
• Threat intelligence matches on the entity (for IPs/URLs)

Entity pages are the fastest way to answer "is this account compromised?" because they aggregate cross-source signal without writing a query. Watching for the time picker and the insights pane on an entity page is a common active-screen scenario.

flowchart TD
  A[Incident] --> B[Entities tab]
  B --> C[Open Account entity page]
  C --> D[Alerts + incidents history]
  C --> E[Activity timeline]
  C --> F[UEBA insights + priority score]
  C --> G[TI matches]

Threat Intelligence in Microsoft Sentinel

Threat intelligence (TI) is curated data about known adversary infrastructure and tooling — malicious IPs, domains, URLs, and file hashes — expressed as indicators of compromise (IOCs). Sentinel ingests TI and correlates it against your logs to raise high-fidelity detections.

TI Ingestion Paths

Ingested indicators land in the ThreatIntelligenceIndicator table and appear in the Threat Intelligence blade where you can search, tag, and add indicators manually.

TI Matching

Ingesting indicators does nothing on its own — you must match them against telemetry:

• The built-in Microsoft Threat Intelligence Analytics rule (a Microsoft security rule) and the TI map scheduled rule templates correlate ThreatIntelligenceIndicator against logs such as CommonSecurityLog, DnsEvents, and SigninLogs.
• A match creates an alert/incident enriched with the matched indicator, so the analyst immediately sees why it is malicious and the TI source.

Exam trap: "Indicators are ingested but no incidents fire." The missing step is almost always an analytics rule that matches TI against logs — ingestion and matching are separate.

Workbooks for Investigation

Workbooks are interactive, KQL-backed dashboards in Sentinel. For investigation they:

• Visualize incident volume, MITRE ATT&CK coverage, and analyst workload
• Track TI ingestion freshness and indicator match rates
• Let an analyst pivot interactively (parameters, drill-down) without writing KQL each time

Workbooks are visualization and monitoring, not detection. If a scenario needs an alert, the answer is an analytics rule; if it needs a visual investigation view or coverage report, the answer is a workbook.