Investigating and Remediating Defender XDR Alerts for SC-200: Office 365, Purview, Defender for Cloud, Cloud Apps, Entra ID and Defender for Identity

In Microsoft Defender for Office 365 you remediate delivered malicious email from Threat Explorer (Plan 2) or Real-time detections (Plan 1), choosing an action that decides where the message ends up and who can still recover it. Real-time detections shows detections at delivery time only; Threat Explorer has everything Real-time detections has and adds post-delivery activity (for example who clicked a link) plus the All email and Campaigns views and more filters and actions.

Move to inbox is the reverse action, for messages that turn out to be false positives.

Approval. An analyst who holds the Search and Purge role can act directly. An analyst without it, or one whose policy requires sign-off, uses add to remediation: the selected messages go into a remediation that waits on the Action center Pending tab, where someone with Search and Purge approves it; it then moves to the History tab.

Automated investigation and response (AIR)

AIR is a Defender for Office 365 Plan 2 capability. Investigations start from the default alert policies in the Threat management category whose Automated investigation value is Yes, for example the policy for user-reported phishing, post-delivery removal of malware or phishing by zero-hour auto purge (ZAP), clicks on URLs that turn malicious, and signs of a compromised user. Two behaviours matter:

• If a default alert policy is disabled or replaced by a custom copy, AIR is no longer triggered for it. The custom policy still raises alerts, but it cannot start investigations, so the fix is to re-enable the default policy.
• Built-in alert tuning rules (for example auto-resolving alerts for user-reported messages) suppress alerts without stopping AIR. If the investigation finds malicious or suspicious activity, the alert is reactivated, so threats still surface.

Remediation actions proposed by AIR can be approved inside the investigation, the incident or the Action center. The Action center Pending tab is the one queue that lists both AIR actions and manual remediations submitted from Threat Explorer.

Admin submissions send a message, URL or file to Microsoft for analysis and can create an allow or block entry in the Tenant Allow/Block List in the same step. The entry type and its expiry depend on the direction of the mistake and on which protection made the verdict.

Two details decide many scenarios. Only Never expire keeps a block in place until someone removes it, and a domain block covers every message from the domain while a URL block covers only the links. A false-positive submission does not automatically override impersonation protection, so a recurring impersonation false positive needs the anti-phishing policy change. Anti-spam allowed-domain lists, mail flow rules that set SCL -1 and Outlook Safe Senders bypass filtering without sending anything to Microsoft and without lapsing on their own, which is why submissions are preferred for false positives.

A compromised mailbox is fully cleaned up only when the attacker's access paths are removed as well as the password: sessions, app passwords, MFA methods, forwarding and inbox rules. Microsoft's response steps are:

1. Reset the password (or disable the account while you investigate) and require MFA.
2. Revoke sign-in sessions, which invalidates refresh tokens issued before the reset; otherwise existing tokens keep working.
3. Have the user delete and recreate app passwords, which a password reset doesn't revoke, and review registered MFA methods for one the attacker added.
4. Remove attacker forwarding and inbox rules.
5. If the account was restricted from sending, unblock it once it is secure.

Finding redirection. Hidden inbox rules don't appear in Outlook or in Get-InboxRule without the switch, so check with Exchange Online PowerShell:

Get-InboxRule -Mailbox jason -IncludeHidden | fl
Get-Mailbox -Identity jason | fl Forwarding*,DeliverToMailboxAndForward

ForwardingAddress forwards to an internal recipient and ForwardingSmtpAddress to any SMTP address. When both are set, mail is forwarded only to the ForwardingAddress recipient; DeliverToMailboxAndForward set to True also keeps a copy in the mailbox. An attacker's external address set alongside an internal forward still has to be cleared, because it takes effect as soon as the internal forward is removed.

Restricted senders. A mailbox that exceeds the service sending limits or the outbound spam policy limits can still receive mail but can't send; it is listed on the Restricted entities page and its messages bounce with 550 5.1.8 Access denied, bad outbound sender. After securing the account, an admin selects Unblock on that page or runs Remove-BlockedSenderAddress in Exchange Online PowerShell.

Automatic attack disruption is Defender XDR's high-confidence containment of attacks such as business email compromise (BEC) and adversary-in-the-middle (AiTM) phishing, and analysts recognise its work by the Attack Disruption tag on an incident. Configuring it, its exclusions and undoing actions in the Action center belong to the automation lesson for task 1.1; this topic is about investigating what it did.

• Incident queue: an Attack Disruption tag beside each incident where it acted, so filtering on the tag lists every containment to review.
• Incident page: the tag, a yellow banner describing the action taken, and the contained assets marked in the incident graph.
• API: (attack disruption) is appended to the titles of high-confidence incidents that are likely to be disrupted. It is a signal for API consumers, not the portal's record of a containment.

Identity actions include disable user, revoke session and suspend user. Where disable user runs depends on where the account lives:

So a hybrid user disabled in Entra ID but still enabled in Active Directory points to missing sensors on the domain controllers, because sensors on other server roles don't perform remediation.

Microsoft Purview data loss prevention (DLP) and Insider Risk Management alerts can be triaged in the Microsoft Defender portal alongside security alerts, but each needs its own permissions and has its own rules for how it appears.

DLP alerts

From 12 October 2026 a built-in alert tuning rule, Set-As-Behavior - Data Loss Prevention (DLP) Alerts, is enabled by default. It turns DLP signals into behaviors instead of alerts, so they no longer create alerts or incidents in Defender XDR but stay huntable in the BehaviorInfo and BehaviorEntities tables. To get DLP signals back as alerts, disable that rule under Settings > Microsoft Defender XDR > Alert tuning. While the rule is on it overrides the alert settings in the DLP policy itself.

The read-only, DLP-only combination is View-Only DLP Compliance Management. For a DLP alert on a SharePoint Online or OneDrive file, the alert offers in-place actions: apply a retention label, apply a sensitivity label, unshare, delete, download and withdraw feedback. Unshare ends oversharing while the owner keeps the file; delete removes it.

Insider risk alerts

Viewing and managing Insider Risk Management alerts in Defender needs a Microsoft Entra role (Security Operator or Security Reader) plus membership of a Purview insider risk role group: Insider Risk Management, Insider Risk Management Analysts or Insider Risk Management Investigators. The least-privileged pairing is Security Reader with Insider Risk Management Analysts; Security Operator and the full Insider Risk Management role group grant more than viewing and triaging alerts needs. Status changes sync between the portals (within about 30 minutes):

In advanced hunting, AlertInfo and AlertEvidence hold the alerts and their entities, DataSecurityBehaviors holds insights into potentially suspicious user behaviour, and DataSecurityEvents holds the enriched events for user activities that violate Purview policies, such as a file uploaded to a personal cloud drive.

A Microsoft Defender for Cloud alert is worked from its Take action tab, which has five sections that each do one job.

Setting an alert's status to Dismissed closes that one alert; benign activity that recurs (an approved scanner, say) calls for a suppression rule. Likewise, Trigger logic app handles one alert now, while workflow automation runs a logic app for future alerts that match a trigger.

Defender for Cloud in Defender XDR

With the Defender XDR integration on, Defender for Cloud alerts and incidents from all subscriptions appear in the Defender portal, with three rules to remember:

• Informational alerts are not integrated; they are reviewed in Defender for Cloud only.
• Status changes for Defender for Cloud alerts sync both ways, so resolving one in either portal resolves it in the other.
• Defender for Endpoint alerts on cloud resources appear in both portals, but their statuses are not synchronized, so they must be closed in each.

To narrow the Defender portal's alert queue to one Azure subscription, filter on the alert subscription ID.

Microsoft Defender for Cloud Apps remediates risky users with governance actions, and each action changes something different: access, sessions or risk.

The actions combine: Require user to sign in again plus Confirm user compromised ends the attacker's sessions now and sends the user through the risk policy at next sign-in without blocking the account. To keep a synced user blocked, disable the account in Active Directory, for example with Defender for Identity's Disable action, which syncs to Entra ID.

Tuning anomaly detection policies

• Scope: change All users and groups to Specific users and groups, then Include or Exclude. An excluded user never triggers that policy, even inside an included group, so one frequent traveller can be excluded from Activity from infrequent country/region without turning the policy off.
• Impossible travel sensitivity: the slider sets how many suppressions apply (Low applies the most, High keeps only system suppressions). Travel between IP addresses that are both considered safe, for example tagged Corporate, is trusted unless the slider is on High.
• Learning period: anomaly policies build a baseline of users, devices, locations and activities; during the initial seven-day learning period not all anomaly alerts are raised.

Microsoft Entra ID Protection remediates a compromised identity either automatically, through risk-based Conditional Access policies, or manually from the Risky users page. The manual options are:

Editing risk-based policies is a separate task whose least privileged role is Security Administrator. When compromise is confirmed and no policy has remediated it, Microsoft's follow-ups are to request a password change, block the user if you suspect the attacker can reset the password or do MFA for the user, revoke refresh tokens, and disable compromised devices. If the attacker registered their own authenticator, a self-service secure password change would let the attacker remediate the risk, so block and revoke instead.

Hybrid users. An on-premises password change (for example Ctrl+Alt+Del on a hybrid-joined device) clears user risk only when password hash synchronization is in place and the opt-in setting Allow on-premises password change to reset user risk is turned on in the Identity Protection settings.

Microsoft Defender for Identity remediation actions are taken from an identity's page in the Defender portal, and which ones apply depends on where the account lives.

For an account that exists only in Active Directory, Revoke session and Mark as compromised don't apply. Force password change is unsafe when the attacker knows the current password, because whoever signs in next sets the new one; Disable stops sign-in at once. For a hybrid identity, check which directories each action reaches: blocking sign-in and ending existing cloud sessions are separate actions.

How the actions run. Only sensors installed on domain controllers perform Active Directory remediation, and they act with the domain controller's local system account. Under Manage action accounts, the option Automatically use the sensor's local system account is required when any sensor is v3.x; with a separately configured action account the actions fail.

Triaging a Defender for Identity alert means classifying it (true positive, benign true positive or false positive), applying the alert-specific remediation, and tuning recurring benign alerts with the tool that matches the alert's format.

Classic versus Defender format. Defender for Identity alerts appear in two formats, shown by the alert's Detection source. Classic detections are tuned with Excluded entities under System > Settings > Identities (per detection, or global). Exclusions there no longer apply to detections that moved to the Defender XDR detection engine; for those, create a Microsoft Defender alert tuning rule. Classifying each alert records a verdict but suppresses nothing.

When an alert traces back to a gap in sensor coverage, closing the gap is the durable fix: it classifies the alert as a benign true positive and restores detection, where suppressing the source would hide future attacks too.