Microsoft Defender XDR Alert External Alerts

Generates a detection alert for each Microsoft Defender XDR alert written to the configured indices. Microsoft Defender emits multiple update events for the same alert over its lifecycle, all sharing a stable alert identifier. This rule suppresses those update events so that a single, continuous Elastic alert is maintained per Defender alert rather than a new alert per update. Enabling this rule allows you to immediately begin investigating Microsoft Defender XDR alerts in the app.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/06/30"
  3integration = ["m365_defender"]
  4maturity = "production"
  5promotion = true
  6updated_date = "2026/06/30"
  7
  8[rule]
  9author = ["Elastic"]
 10description = """
 11Generates a detection alert for each Microsoft Defender XDR alert written to the configured indices. Microsoft Defender
 12emits multiple update events for the same alert over its lifecycle, all sharing a stable alert identifier. This rule
 13suppresses those update events so that a single, continuous Elastic alert is maintained per Defender alert rather than a
 14new alert per update. Enabling this rule allows you to immediately begin investigating Microsoft Defender XDR alerts in
 15the app.
 16"""
 17from = "now-2m"
 18index = ["logs-m365_defender.alert-*"]
 19interval = "1m"
 20language = "kuery"
 21license = "Elastic License v2"
 22max_signals = 1000
 23name = "Microsoft Defender XDR Alert External Alerts"
 24note = """## Triage and analysis
 25
 26### Investigating Microsoft Defender XDR Alert External Alerts
 27
 28Microsoft Defender XDR is a unified pre- and post-breach enterprise defense suite that natively coordinates detection, prevention, investigation, and response across endpoints, identities, email, and applications. The alert data stream (`logs-m365_defender.alert-*`) carries pre-correlated alerts already triaged by Defender. This rule promotes each Defender alert into an Elastic detection alert so analysts can investigate without leaving the app.
 29
 30Microsoft Defender emits several update events for the same alert as its status, classification, and evidence evolve. Every update shares the same stable Defender alert identifier (`m365_defender.alert.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.
 31
 32If you also collect Microsoft Defender alerts through the Microsoft 365 Unified Audit Log (`logs-o365.audit-*`) rather than the native integration data stream, 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.
 33
 34### Possible investigation steps
 35
 36- Review `m365_defender.alert.title`, `m365_defender.alert.category`, and `m365_defender.alert.threat_display_name` to understand what Defender detected.
 37- Pivot to the Defender portal using `m365_defender.alert.incident_web_url.original` for the full evidence graph, process tree, and remediation status.
 38- Examine the evidence fields under `m365_defender.alert.evidence.*` (host, file, process, user account, URL, sender) to scope the impacted entities.
 39- Check `m365_defender.alert.incident_id` to correlate the alert with its parent Defender incident and any sibling alerts.
 40- Review `m365_defender.alert.status` and `m365_defender.alert.classification` to see whether Defender has already resolved or classified the alert.
 41
 42### False positive analysis
 43
 44- Defender alerts are pre-correlated and tuned by Microsoft, so true false positives are uncommon. When they occur, confirm with the responsible team before excluding.
 45- Alerts involving known and trusted administrative tools, security assessments, or scheduled automation may be benign. Validate intent before adding an exception.
 46- Use `m365_defender.alert.classification` and `m365_defender.alert.determination` to filter out activity Defender itself has marked as a false positive.
 47
 48### Response and remediation
 49
 50- Isolate affected endpoints or disable affected accounts if malicious behavior is confirmed.
 51- Use the Defender portal to action native response options (quarantine, automated investigation, account remediation) for the alert.
 52- Investigate how the threat entered the environment and close any exploited gaps.
 53- Reset credentials for compromised accounts or escalate to incident response.
 54- Document the findings and tune the upstream Defender policy or add an Elastic exception as appropriate.
 55"""
 56references = ["https://docs.elastic.co/en/integrations/m365_defender"]
 57risk_score = 47
 58rule_id = "c2a0e42b-ac3d-468f-82a5-0082066e1b59"
 59rule_name_override = "m365_defender.alert.title"
 60setup = """## Setup
 61
 62### Microsoft Defender XDR Alert Integration
 63This rule is designed to capture alert events generated by the Microsoft Defender XDR integration and promote them as Elastic detection alerts.
 64
 65To capture Microsoft Defender XDR alerts, install and configure the Microsoft Defender XDR integration to ingest alert events into the `logs-m365_defender.alert-*` index pattern.
 66
 67### Alert suppression and the Defender update lifecycle
 68
 69Microsoft Defender writes multiple update events per alert during its lifecycle, all sharing the same stable identifier (`m365_defender.alert.id`, copied to `event.id`). This rule suppresses on that identifier so updates accumulate into one Elastic alert. Note the following alert suppression semantics:
 70
 71- Suppression applies going forward from when the suppressing alert is created; it does not retroactively merge alerts created before the rule was enabled.
 72- 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.
 73- The suppression window (default 1 day) is tunable. Size it to your environment's typical Defender alert lifecycle; extending it keeps a single alert open longer but delays new-alert creation for late updates.
 74
 75### Avoiding duplicate alerts
 76
 77To avoid double-counting, enable either this alert-level rule or the Microsoft Defender XDR Incident External Alerts rule (incident-level), not both: a Defender incident's child alerts appear in both data streams. Choose incident-level for the least noise (one Elastic alert per Defender incident) or alert-level for finer-grained, per-alert triage.
 78
 79### Additional notes
 80
 81For 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).
 82"""
 83severity = "medium"
 84tags = [
 85    "Data Source: Microsoft Defender XDR",
 86    "Use Case: Threat Detection",
 87    "Resources: Investigation Guide",
 88    "Promotion: External Alerts",
 89]
 90timestamp_override = "event.ingested"
 91type = "query"
 92
 93query = '''
 94event.kind: alert and data_stream.dataset: m365_defender.alert
 95'''
 96
 97
 98[[rule.risk_score_mapping]]
 99field = "event.severity"
100operator = "equals"
101value = ""
102
103[[rule.severity_mapping]]
104field = "m365_defender.alert.severity"
105operator = "equals"
106severity = "low"
107value = "informational"
108
109[[rule.severity_mapping]]
110field = "m365_defender.alert.severity"
111operator = "equals"
112severity = "low"
113value = "low"
114
115[[rule.severity_mapping]]
116field = "m365_defender.alert.severity"
117operator = "equals"
118severity = "medium"
119value = "medium"
120
121[[rule.severity_mapping]]
122field = "m365_defender.alert.severity"
123operator = "equals"
124severity = "high"
125value = "high"
126
127[rule.alert_suppression]
128group_by = ["m365_defender.alert.id", "m365_defender.alert.tenant_id"]
129missing_fields_strategy = "doNotSuppress"
130
131[rule.alert_suppression.duration]
132unit = "h"
133value = 24

Triage and analysis

Investigating Microsoft Defender XDR Alert External Alerts

Microsoft Defender XDR is a unified pre- and post-breach enterprise defense suite that natively coordinates detection, prevention, investigation, and response across endpoints, identities, email, and applications. The alert data stream (logs-m365_defender.alert-*) carries pre-correlated alerts already triaged by Defender. This rule promotes each Defender alert into an Elastic detection alert so analysts can investigate without leaving the app.

Microsoft Defender emits several update events for the same alert as its status, classification, and evidence evolve. Every update shares the same stable Defender alert identifier (m365_defender.alert.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.

If you also collect Microsoft Defender alerts through the Microsoft 365 Unified Audit Log (logs-o365.audit-*) rather than the native integration data stream, 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.alert.title, m365_defender.alert.category, and m365_defender.alert.threat_display_name to understand what Defender detected.
  • Pivot to the Defender portal using m365_defender.alert.incident_web_url.original for the full evidence graph, process tree, and remediation status.
  • Examine the evidence fields under m365_defender.alert.evidence.* (host, file, process, user account, URL, sender) to scope the impacted entities.
  • Check m365_defender.alert.incident_id to correlate the alert with its parent Defender incident and any sibling alerts.
  • Review m365_defender.alert.status and m365_defender.alert.classification to see whether Defender has already resolved or classified the alert.

False positive analysis

  • Defender alerts are pre-correlated and tuned by Microsoft, so true false positives are uncommon. When they occur, confirm with the responsible team before excluding.
  • Alerts involving known and trusted administrative tools, security assessments, or scheduled automation may be benign. Validate intent before adding an exception.
  • Use m365_defender.alert.classification and m365_defender.alert.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.
  • Use the Defender portal to action native response options (quarantine, automated investigation, account remediation) for the alert.
  • 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.

References

Related rules

to-top