SC-200 Sentinel Incidents, Security Copilot, Multistage Attacks and Case Management

Once a Microsoft Sentinel workspace is onboarded to the Microsoft Defender portal, its incidents are triaged in the unified queue at Investigation & response > Incidents & alerts > Incidents, alongside Microsoft Defender XDR incidents. They open into the same attack story, incident graph and entity pages, enriched with Defender signals. The Microsoft Sentinel section of the Defender portal keeps tools such as workbooks, hunting and content management, but it has no separate incident queue.

The Azure portal experience is on a clock: Microsoft Learn states that after March 31, 2027 Microsoft Sentinel is no longer supported in the Azure portal, and customers are redirected to the Defender portal. New customers who have Owner or User Access Administrator rights have been onboarded to the Defender portal automatically since July 1, 2025; that date doesn't exempt older workspaces. A plan to keep working incidents in the Azure portal for years is therefore not viable — plan the move. Several features covered in this lesson, including case management, blast radius analysis and the Defender XDR correlation engine, exist only in the Defender portal.

What changes when you onboard

The title point already applies in the Azure portal as soon as the Microsoft Defender XDR connector is enabled: the connector turns off Microsoft incident creation rules for Defender XDR-integrated products (such as Defender for Identity) to avoid duplicate incidents, and Defender XDR then creates and names those incidents. Rewrite automation conditions to use something stable instead of the incident name; Microsoft recommends tags, and alert product names also stay constant. Turning the creation rules back on would only produce duplicate incidents for the same alerts. If you used incident creation rules for Microsoft products that aren't integrated into Defender XDR, replace them with scheduled analytics rules before onboarding.

With the Microsoft Defender XDR connector, Defender XDR incidents appear in the Sentinel incident queue in the Azure portal and stay synchronised both ways: status, owner and classification changed on either side update the other. Three behaviours are tested.

• The 150-alert limit. A Sentinel incident holds at most 150 alerts. A larger Defender XDR incident shows its alert count as 150+ in Sentinel, with a link to the parallel incident in the Defender portal, which is where the full alert list lives. The limit is fixed: the full set is only visible on the Defender side.
• Merges. When Defender XDR merges incidents, the Sentinel copies of the merged-away incidents are closed and tagged redirected.
• Classification mapping. The two products use different classification schemas, so values are transformed as they sync.

Sentinel's False Positive – Inaccurate alert logic has no Defender XDR counterpart: a Defender XDR classification never syncs into it. An analyst can still set it directly on the synced incident in Sentinel.

In the Azure portal, a Sentinel incident is investigated from its incident page: the Overview tab (incident timeline, Similar incidents, Top insights), the Entities tab, the Logs panel and the investigation graph. Each tool has its own window and prerequisites.

Because the graph is built from mapped entities, a rule without entity mappings produces incidents the graph can't draw, even when every other rule's incidents open normally.

Saving evidence from the Logs panel

Query results run in the Logs panel inside the incident page can be kept as bookmarks. Add bookmark to the current incident creates the bookmark and attaches it in one step, so it appears in the incident timeline. Plain Add bookmark creates an unattached bookmark that you would later add to an incident from the Bookmarks tab of the Hunting page.

In the Defender portal, the attack story's Go hunt action runs prebuilt advanced hunting queries for the entity you select, so you can widen an investigation without writing KQL, and Link to incident attaches the results you choose as evidence.

• All Activity — every event and alert associated with the entity.
• Related Alerts — only the alerts that involve the entity.
• All User anomalies — for user entities, the user's anomalies over the past 30 days. It appears only when Microsoft Sentinel User and Entity Behavior Analytics (UEBA) is enabled.

For alerts raised by Sentinel analytics rules, Run query reruns the rule's query to show the events behind that alert; it is narrower than All Activity.

Running a playbook on demand

To remediate a Sentinel incident from the Defender portal, open the incident and choose Run Playbook. The list shows playbooks built on the Microsoft Sentinel Incident trigger. Running a playbook manually on an alert isn't supported in the Defender portal, so an alert-trigger playbook can't be launched there; use an incident-trigger version.

Configuring automation rules and playbook permissions in depth belongs to the automation lesson of the first domain; here the skill is recognising why an on-demand run is blocked.

Security Copilot embedded in the Defender portal gives analysts targeted skills inside the incident page: an incident summary, guided responses, script and file analysis, device and identity summaries, and an incident report. Choosing the right one is the usual exam decision.

Controlling incident summaries

Summaries consume Security Compute Units. Under Copilot in Defender settings > Preferences > Incident Summary generation, choose Auto-generate — either Always, or by Incident severity with a minimum level — or Generate on demand. With a severity minimum, incidents below it get no automatic summary, but an analyst can still generate one on request. Copilot also saves generated summaries for a week: when an incident hasn't changed significantly, its cached summary is shown again automatically and at no cost, regardless of the generation setting.

Guided responses

Guided response cards are generated per incident, but each action button is enabled by the signed-in user's unified RBAC permissions; a greyed-out action is limited by that analyst's permissions. Cards also offer context: View similar incidents (machine-learning matches), View similar emails for phishing incidents (opens advanced hunting with a generated KQL query you can run or edit) and contacting the user in Microsoft Teams.

The incident summary explains the attack; the incident report documents the response. Use the summary while triaging and the report for post-incident reviews and leadership write-ups.

The report is built from recorded actions and analyst comments, so two habits make it complete: classify and resolve the incident before generating it (an unresolved incident may show only some actions) and write decisions as comments in the Defender or Sentinel activity log. Live response commands, public API actions and custom detection actions aren't yet included, so running remediation in live response doesn't add to the report.

Beyond on-request skills, Defender includes agentic AI: Defender Chat, which plans steps with you, and Security Copilot agents that triage or detect on their own.

Defender Chat (preview)

Defender Chat is the Copilot chat in the Defender portal. It is aware of the page you're on, and for multi-step work it proposes a step-by-step plan that you Approve or Reject before it acts. Its last ten conversations are stored locally in your browser: they aren't synced to other devices or shared with colleagues. To hand a Copilot write-up to another shift, generate the incident report and Post to activity log instead of relying on the chat history.

Phishing Triage Agent and Security Alert Triage Agent

• What it does: when an alert in scope is created (for phishing, a user-reported message), the agent assigns the alert to itself, adds an Agent tag and analyses it. A false alarm is classified False Positive and resolved; a real threat is classified True Positive and the incident stays open for an analyst. Each verdict comes with a natural-language rationale and a view of the agent's activity.
• Identity: a Security Administrator sets the agent up. Create a new agent identity (recommended) creates a Microsoft Entra Agent ID and lets you pick or create a role with only the permissions the agent needs. Connect an existing user account makes the agent inherit that user's access, needs a long expiration and is not compatible with PIM or Temporary Access Pass — so it conflicts with any policy that privileged users activate roles through PIM.
• Teaching it: when you change the agent's classification, the reason you type is saved on the feedback management page for auditing only. The agent learns only if you select Use this feedback to teach the agent, evaluate the lesson and save it to the agent's memory. Lessons can concern either verdict; rejecting feedback needs the Security Administrator role.

Dynamic Threat Detection Agent

The Dynamic Threat Detection Agent is an always-on backend service: it needs no setup, correlates Defender and Sentinel signals to find threats that rule-based detections missed, and raises alerts in the normal queues with Security Copilot as the detection source, an explanation, mapped MITRE ATT&CK techniques and remediation steps. To review what it has found, filter the alert queue on the Security Copilot detection source.

A multistage attack is a chain of individually weak signals — a risky sign-in, then a mass download, then persistence — that only reads as an attack once correlated across products. Who does the correlating depends on where Sentinel runs.

• Azure portal: Fusion. The built-in Advanced multistage attack detection rule uses machine learning to correlate low-fidelity alerts and anomalies from multiple products into high-fidelity incidents, without you writing rules. Anomaly rules and Microsoft service alerts feed it, and so can your scheduled analytics rules — but only if they carry MITRE ATT&CK tactics (kill-chain information) and entity mappings. Those two properties are what make a scheduled rule's alerts usable by Fusion. Fusion incidents land in the SecurityIncident table like any other.
• Defender portal: the Defender XDR correlation engine. After onboarding, Fusion is disabled and the correlation engine correlates Sentinel and Defender alerts into multistage incidents. Nothing needs re-creating.

Scoping a multi-domain attack with KQL

To find every alert involving one user, device or file across Defender for Endpoint, Defender for Office 365, Defender for Identity, Defender for Cloud Apps and onboarded Sentinel workspaces, start from AlertEvidence: it holds the entities of each alert (for example AccountUpn, DeviceName) plus ServiceSource, the product that raised it. AlertInfo has titles, categories and severity but no entity columns; join the two on AlertId when you need both.

let suspect = "dana.reyes@fabrikam.example";
AlertInfo
| where Timestamp > ago(14d)
| join kind=inner (
    AlertEvidence
    | where AccountUpn =~ suspect
    | distinct AlertId, ServiceSource
  ) on AlertId
| project Timestamp, ServiceSource, Title, Severity, Category
| order by Timestamp asc

Lateral movement is traced from logon records — which accounts signed in where, from which machine — and its potential reach is shown by blast radius analysis in the incident graph.

Reading DeviceLogonEvents

Each row is recorded on the device that was logged on to (DeviceName). For remote logons, RemoteDeviceName and RemoteIP name the machine the logon came from. So to see where an attacker went from a compromised host, filter other devices' logons on RemoteDeviceName equal to that host; filtering DeviceName on it shows logons into it. InitiatingProcessRemoteSessionDeviceName is a different thing: the device an RDP session came from when a process ran inside that session.

For example, to list the hosts reached from file server FS-03 during the past day, look at logons recorded on other devices whose source was FS-03:

DeviceLogonEvents
| where Timestamp > ago(24h)
| where RemoteDeviceName =~ "fs-03"
| where ActionType == "LogonSuccess"
| project Timestamp, DeviceName, AccountDomain, AccountName, LogonType, RemoteIP
| order by Timestamp asc

Blast radius analysis

In the Defender portal's incident graph you can play the attack over time and select View blast radius on a node to see possible propagation paths from it to predefined critical targets; it replaces attack path analysis in the incident graph.

• Prerequisites: the tenant is onboarded to the Microsoft Sentinel data lake, and the analyst has Exposure management (read) or higher.
• Targets: paths lead to critical assets. If a server isn't classified as critical, paths to it may not show, so the graph under-represents the risk.
• Scope: the graph shows only nodes and edges inside the viewer's RBAC scope; paths with out-of-scope parts are hidden, so two analysts can see different results.
• Display: the top eight rated paths are shown, with the full list available; hop limits depend on the environment type (cloud, on-premises or hybrid), not on the viewer.

Defender for Endpoint device actions such as isolation and live response are covered in the Defender for Endpoint lesson.

Microsoft Defender case management tracks security operations work as cases in the Defender portal — with owners, tasks, comments, attachments, custom fields and SLA timers — and is available only in the Defender portal, so a Sentinel-only Azure portal tenant must onboard first.

Generic cases replace Microsoft Defender Threat Intelligence projects, which are deprecated: link indicators to a case from the case or from the indicator's Intel management page. Their unified RBAC permissions sit in the Security operations group: Security data basics (read) to view generic cases and Alerts (manage) to create and manage them. Incident cases use the same permissions and scoping as the legacy incident experience: Security Data Read to view them and Security Data Manage to view and manage them. They can also carry a Copilot summary.

Merge or move

• Merge when whole cases describe the same attack. One case ID is retained, case data is consolidated into it, and the other IDs are removed (the redirected tag is a different mechanism: it marks Defender XDR incident merges as seen in Sentinel). Incident cases with a resolved status can't be merged: reopen first.
• Move an alert when one alert was correlated into the wrong case or belongs to another active investigation. Every alert must belong to an incident case, so you move it rather than remove it.

Case templates, statuses and SLA policies

Case management settings define custom fields, custom statuses and SLA policies. Custom statuses are added under the New, Open or Closed lifecycle category, which decides how the case is treated (a waiting state still being worked goes under Open); default statuses can't be deleted. An SLA policy has start, end and pause criteria, timers (time to acknowledge, time to resolve) that can differ by severity, and an optional at-risk threshold — without one, the At Risk state never appears.

A status in which the timer should stop and later resume is a pause criterion, not an end criterion. SLA emails come from an automation rule with the Case updated trigger and an SLA Policies condition of Status changed to the chosen timer state (for example At Risk); the case assignee is notified as well.