---
title: Microsoft Defender XDR Incident External Alerts
description: Generates a detection alert for each Microsoft Defender XDR incident written to the configured indices. Microsoft Defender emits multiple update events...
url: https://www.elastic.co/elastic/docs-builder/docs/3655/reference/security/prebuilt-rules/rules/promotions/m365_defender_incident_external_alerts
products:
  - Elastic Security
---

# Microsoft Defender XDR Incident External Alerts
Generates a detection alert for each Microsoft Defender XDR incident written to the configured indices. Microsoft
Defender emits multiple update events for the same incident as its member alerts and status evolve, all sharing a stable
incident identifier. This rule suppresses those update events so that a single, continuous Elastic alert is maintained
per Defender incident rather than a new alert per update. Enabling this rule allows you to immediately begin
investigating Microsoft Defender XDR incidents in the app.
**Rule type**: query
**Rule indices**:
- logs-m365_defender.incident-*

**Rule Severity**: medium
**Risk Score**: 47
**Runs every**: 1m
**Searches indices from**: `now-2m`
**Maximum alerts per execution**: 1000
**References**:
- [[https://docs.elastic.co/en/integrations/m365_defender](https://docs.elastic.co/en/integrations/m365_defender)](https://docs.elastic.co/en/integrations/m365_defender)

**Tags**:
- Data Source: Microsoft Defender XDR
- Use Case: Threat Detection
- Resources: Investigation Guide
- Promotion: External Alerts

**Version**: 1
**Rule authors**:
- Elastic

**Rule license**: Elastic License v2

## Setup


### Microsoft Defender XDR Incident Integration

This rule is designed to capture incident events generated by the Microsoft Defender XDR integration and promote them as Elastic detection alerts.
To capture Microsoft Defender XDR incidents, install and configure the Microsoft Defender XDR integration to ingest incident events into the `logs-m365_defender.incident-*` index pattern.

### Alert suppression and the Defender update lifecycle

Microsoft Defender writes multiple update events per incident during its lifecycle, all sharing the same stable identifier (`m365_defender.incident.id`, copied to `event.id`). This rule suppresses on that identifier so updates accumulate into one Elastic alert. Note the following alert suppression semantics:
- Suppression applies going forward from when the suppressing alert is created; it does not retroactively merge alerts created before the rule was enabled.
- Updates are aggregated into the existing alert only while that alert is open and within the suppression window. If an analyst closes the suppressing alert, a later Defender update will open a new Elastic alert.
- The suppression window (default 1 day) is tunable. Size it to your environment's typical Defender incident lifecycle; extending it keeps a single alert open longer but delays new-alert creation for late updates.


### Avoiding duplicate alerts

To avoid double-counting, enable either this incident-level rule or the Microsoft Defender XDR Alert External Alerts rule (alert-level), not both: a Defender incident's child alerts appear in both data streams. Incident-level (this rule) produces the least noise (one Elastic alert per Defender incident) and is the recommended default; alert-level provides finer-grained, per-alert triage.

### Additional notes

For information on troubleshooting the maximum alerts warning please refer to this [guide](https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts).

## Investigation guide


## Triage and analysis


### Investigating Microsoft Defender XDR Incident External Alerts

Microsoft Defender XDR correlates related alerts across endpoints, identities, email, and applications into a single incident, providing the full attack story in one place. The incident data stream (`logs-m365_defender.incident-*`) carries these pre-correlated incidents. This rule promotes each Defender incident into an Elastic detection alert so analysts can investigate the correlated story without leaving the app.
Microsoft Defender emits several update events for the same incident as member alerts are added and status, classification, and evidence evolve. Every update shares the same stable Defender incident identifier (`m365_defender.incident.id`, which the integration also copies into `event.id`). The rule groups on that identifier so subsequent updates accumulate into the existing Elastic alert rather than creating duplicates.
The member alerts that make up an incident may also arrive through the Microsoft 365 Unified Audit Log (`logs-o365.audit-*`) rather than the native integration data stream. In that case the M365 Defender Alerts Signal (UAL) building block rule (rule_id: 054853f3-2ce0-41f3-a6eb-4a4867f39cdc) generates correlation signals from that source and can be used alongside this promotion rule.

### Possible investigation steps

- Review `m365_defender.incident.display_name`, `m365_defender.incident.severity`, and `m365_defender.incident.tags` to understand the scope and priority of the incident.
- Pivot to the Defender portal using `m365_defender.incident.web_url.original` for the correlated attack story, evidence graph, and recommended actions.
- Examine the member alert fields under `m365_defender.incident.alert.*` (titles, MITRE techniques, detection sources, evidence) to scope the impacted entities and behaviors.
- Review `m365_defender.incident.status`, `m365_defender.incident.classification`, and `m365_defender.incident.determination` to see whether Defender has already resolved or classified the incident.
- Check `m365_defender.incident.redirect_incident_id` to confirm the incident has not been merged into another incident.


### False positive analysis

- Defender incidents are pre-correlated and tuned by Microsoft, so true false positives are uncommon. When they occur, confirm with the responsible team before excluding.
- Incidents driven entirely by known and trusted administrative tools, security assessments, or scheduled automation may be benign. Validate intent before adding an exception.
- Use `m365_defender.incident.classification` and `m365_defender.incident.determination` to filter out activity Defender itself has marked as a false positive.


### Response and remediation

- Isolate affected endpoints or disable affected accounts if malicious behavior is confirmed across the incident's member alerts.
- Use the Defender portal to action native response options (quarantine, automated investigation, account remediation) for the incident.
- Investigate how the threat entered the environment and close any exploited gaps.
- Reset credentials for compromised accounts or escalate to incident response.
- Document the findings and tune the upstream Defender policy or add an Elastic exception as appropriate.


## Rule Query

```kuery
event.kind: alert and data_stream.dataset: m365_defender.incident
```