Automated Remediation Manual versus Automatic Approval

Hunt Hypothesis

This hypothesis targets adversaries leveraging phishing campaigns (T1566) to establish initial access, where the distinction between automatic and manual remediation approval reveals whether malicious emails were neutralized in real-time or delayed by human intervention. Proactively hunting for this behavior in Azure Sentinel allows the SOC to identify gaps in automated defense workflows, ensuring that high-risk messages are not left in user inboxes long enough for an attacker to interact with them before an administrator can review and approve the remediation action.

KQL Query

EmailPostDeliveryEvents
| where Timestamp > ago(30d)
| extend Key = strcat(NetworkMessageId, '-', RecipientEmailAddress)
| summarize arg_max(Timestamp, *) by Key
| where ActionType == "Automated Remediation"
| summarize count() by ActionTrigger
| render piechart

Analytic Rule Definition

id: 6782a329-feee-4dbc-bbca-d31cb12e1437
name: Automated Remediation Manual versus Automatic Approval
description: |
  This query shows whether Microsoft Defender for Office 365 automated remediation actions were taken automatically or required manual admin approval, using the EmailPostDeliveryEvents table.
description-detailed: |
  Automated Investigation and Response actions can be fully automatic or held for manual approval. This query breaks down automated remediation events by their trigger (automatic versus manual approval), deduplicated to the latest event per message and recipient, so teams can understand how much of their remediation is hands-off versus analyst-gated.
  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:
  - EmailPostDeliveryEvents
tactics:
  - InitialAccess
relevantTechniques:
  - T1566
query: |
  EmailPostDeliveryEvents
  | where Timestamp > ago(30d)
  | extend Key = strcat(NetworkMessageId, '-', RecipientEmailAddress)
  | summarize arg_max(Timestamp, *) by Key
  | where ActionType == "Automated Remediation"
  | summarize count() by ActionTrigger
  | render piechart
version: 1.0.0

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 Manual versus Automatic Approval.yaml)

False Positive Guidance

• Scenario: A security administrator manually approves a high-priority email that was flagged by a custom rule with AutomatedAction: Manual during an incident response drill or a specific phishing campaign takedown.
  • Filter/Exclusion: Exclude events where the MessageId or InternetMessageId is associated with a known incident ticket ID (e.g., via a custom tag in the Tags field) or where the Action is Approved and the TimeGenerated falls within a specific maintenance window defined in a dynamic list.
• Scenario: An IT department uses a scheduled PowerShell script or API call to bulk-approve or reject emails for a specific department (e.g., Finance) that are consistently flagged by a legacy rule set, generating multiple EmailPostDeliveryEvents with AutomatedAction: Manual but initiated by a service account.
  • Filter/Exclusion: Exclude events where the UserPrincipalName (or the admin performing the action, if available in the log context) matches a known service account (e.g., svc-office365-admin@domain.com) or where the Action is Approved/Rejected and the TimeGenerated aligns with the scheduled job execution time (e.g., every hour at :15).
• Scenario: A new email rule is deployed with AutomatedAction: Manual for a pilot group (e.g., 5 users in the C-Suite) to test sensitivity before switching to automatic, resulting in manual approvals that are expected and not indicative of a misconfiguration.
  • Filter/Exclusion: Exclude events where the Sender or Recipient is part of a defined “Pilot Group” dynamic distribution list (e.g., DL-C-Suite-Pilot) or where the RuleId matches a specific known pilot rule ID (e