Automated Remediation Delivery to Action Latency

Hunt Hypothesis

This hypothesis targets potential delays in Microsoft Defender for Office 365’s automated remediation of phishing messages, which could allow malicious emails to remain in user inboxes longer than intended and increase the likelihood of successful exploitation. Proactively hunting for elevated action latency helps the SOC identify configuration gaps or performance bottlenecks that adversaries might leverage to bypass automated defenses and achieve initial access via Spearphishing Attachment or Link.

KQL Query

let deliveries = EmailEvents
  | where Timestamp > ago(30d)
  | where DeliveryAction == "Delivered"
  | extend MsgKey = strcat(NetworkMessageId, "-", RecipientEmailAddress)
  | summarize FirstDelivery = min(Timestamp) by MsgKey, Threat = tostring(ThreatTypes);
let remediations = EmailPostDeliveryEvents
  | where Timestamp > ago(30d)
  | where ActionType == "Automated Remediation"
  | extend MsgKey = strcat(NetworkMessageId, "-", RecipientEmailAddress)
  | summarize FirstRemediation = min(Timestamp) by MsgKey;
deliveries
| join kind=inner remediations on MsgKey
| extend DelayMinutes = datetime_diff("minute", FirstRemediation, FirstDelivery)
| where DelayMinutes >= 0
| summarize ['Avg (min)'] = avg(DelayMinutes), ['P80 (min)'] = percentile(DelayMinutes, 80), ['P90 (min)'] = percentile(DelayMinutes, 90), ['P99 (min)'] = percentile(DelayMinutes, 99), CountEmails = count() by bin(FirstRemediation, 1d)
| render timechart

Analytic Rule Definition

id: 094266b5-c2ef-4818-8558-cfacdb267d23
name: Automated Remediation Delivery to Action Latency
description: |
  This query measures how long after delivery Microsoft Defender for Office 365 automated remediation acts on a message, reported as daily average and percentiles, using the EmailEvents and EmailPostDeliveryEvents tables.
description-detailed: |
  The delay between a threat email being delivered and automated remediation removing it is a key Security Operations metric. This query joins delivered emails to their automated remediation events and reports the daily average, P80, P90 and P99 delay in minutes, so SOC teams can track and improve time-to-remediation.
  Query is also included as part of the Defender for Office 365 solution in Sentinel: https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/part-2-build-custom-email-security-reports-and-dashboards-with-workbooks-in-micr/4411303
requiredDataConnectors:
- connectorId: MicrosoftThreatProtection
  dataTypes:
  - EmailEvents
  - EmailPostDeliveryEvents
tactics:
  - InitialAccess
relevantTechniques:
  - T1566
query: |
  let deliveries = EmailEvents
    | where Timestamp > ago(30d)
    | where DeliveryAction == "Delivered"
    | extend MsgKey = strcat(NetworkMessageId, "-", RecipientEmailAddress)
    | summarize FirstDelivery = min(Timestamp) by MsgKey, Threat = tostring(ThreatTypes);
  let remediations = EmailPostDeliveryEvents
    | where Timestamp > ago(30d)
    | where ActionType == "Automated Remediation"
    | extend MsgKey = strcat(NetworkMessageId, "-", RecipientEmailAddress)
    | summarize FirstRemediation = min(Timestamp) by MsgKey;
  deliveries
  | join kind=inner remediations on MsgKey
  | extend DelayMinutes = datetime_diff("minute", FirstRemediation, FirstDelivery)
  | where DelayMinutes >= 0
  | summarize ['Avg (min)'] = avg(DelayMinutes), ['P80 (min)'] = percentile(DelayMinutes, 80), ['P90 (min)'] = percentile(DelayMinutes, 90), ['P99 (min)'] = percentile(DelayMinutes, 99), CountEmails = count() by bin(FirstRemediation, 1d)
  | render timechart
version: 1.0.0

Required Data Sources

MITRE ATT&CK Context

• Tactic: InitialAccess
• Technique: T1566 — T1566

References

• [Source Query](https://github.com/Azure/Azure-Sentinel/blob/main/Hunting Queries/Microsoft 365 Defender/Email and Collaboration Queries/Remediation/Automated Remediation Delivery to Action Latency.yaml)

False Positive Guidance

• Scenario: A high-volume email migration or bulk import via Microsoft Exchange Online PowerShell or the Migration Assistant tool triggers automated remediation policies (e.g., “Quarantine all messages from unknown senders”) on thousands of messages simultaneously. The sheer volume causes the remediation engine to process messages in batches, creating a temporary spike in latency that appears as a false positive for “slow” remediation.
  • Filter/Exclusion: Exclude messages where EmailPostDelivery properties indicate a “Migrated” or “Imported” source, or filter out days where the total count of automated remediation actions exceeds a defined threshold (e.g., >5,000 actions/day) to account for batch processing overhead.
• Scenario: An IT administrator performs a manual test of the automated remediation pipeline by sending a test email from an external domain to an internal mailbox, then immediately triggering a remediation policy via the Defender for Office 365 portal. If the admin waits 10-15 minutes before checking the logs, the latency metric will reflect the full wait time rather than the actual processing time, skewing the daily average.
  • Filter/Exclusion: Create a custom tag or subject line convention (e.g., “TEST-REMEDIATION”) for manual verification emails and exclude messages containing this string in the MessageSubject field from the latency calculation. Alternatively, exclude events where the EmailPostDelivery timestamp is within 1 hour of a known admin login session to the Defender portal.
• Scenario: During a planned maintenance window, the Microsoft Defender for Office 365 service undergoes a backend update or region failover. Automated remediation tasks are queued and held in a backlog for 20-45 minutes before being processed. This results in a legitimate but temporary increase in action latency that is not indicative of a system failure.
  • **Filter