9.9 Automated Investigation and Response for Email

Automated Investigation and Response for Email

By the end of this subsection, you will understand how AIR automates email threat investigation, know the approval workflow, and be able to monitor AIR effectiveness.

How email AIR works

When Defender for Office 365 detects a phishing email or malware, AIR automatically:

1. Identifies the threat — classifies the email as phishing, malware, or spam
2. Scopes the campaign — finds all related emails (same sender, URL, or attachment hash)
3. Identifies affected users — which mailboxes received the campaign
4. Recommends remediation — soft delete from all affected mailboxes
5. Executes or waits — depending on your automation level, either acts immediately or waits for analyst approval

Automation levels for email

Monitoring AIR effectiveness

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

AlertInfo
| where TimeGenerated > ago(30d)
| where ServiceSource == "Microsoft Defender for Office 365"
| where Category has "Phish" or Category has "Malware"
| summarize
    TotalAlerts = count(),
    AutoRemediated = countif(InvestigationState == "Remediated"),
    PendingApproval = countif(InvestigationState == "Pending"),
    NoAction = countif(InvestigationState == "NoThreatsFound")
| extend AutoRate = round(AutoRemediated * 100.0 / TotalAlerts, 1)

Reviewing AIR investigations

When AIR completes an email investigation, review these elements before approving:

1. Scope accuracy: Did AIR identify all emails in the campaign? Compare the count against your manual Threat Explorer search. If AIR found 18 but you find 23, there are 5 emails AIR missed — remediate manually.

2. Verdict confidence: Check the confidence level of the phishing/malware classification. High confidence = approve quickly. Low confidence = review sample emails before approving.

3. Recommended actions: Is soft delete appropriate, or do some emails need hard delete (e.g., malware that users might restore from Recoverable Items)?

4. Affected users: Review the list of affected mailboxes. Any VIP users? Any service accounts? VIPs may need additional follow-up (Module 14.7 phone notification).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

// Track AIR investigation outcomes over time
AlertInfo
| where TimeGenerated > ago(30d)
| where ServiceSource == "Microsoft Defender for Office 365"
| summarize
    Investigations = count(),
    Remediated = countif(InvestigationState == "Remediated"),
    Approved = countif(InvestigationState == "PendingApproval"),
    Failed = countif(InvestigationState == "Failed")
    by bin(TimeGenerated, 7d)
| extend SuccessRate = round(Remediated * 100.0 / Investigations, 0)
| sort by TimeGenerated asc

Required role and blast radius

Required role: Security Administrator (to view and approve AIR investigations). Security Reader (to view AIR results without approval capability).

How AIR works for email threats

When a phishing email is detected (by anti-phishing, Safe Links, Safe Attachments, or user report), AIR can automatically investigate the scope and recommend remediation.

The AIR investigation sequence:

1. Trigger. An email is classified as malicious (phishing or malware). The trigger can be: an automated detection, a user-reported phishing submission, or a manual trigger from Threat Explorer.

2. Scope expansion. AIR searches for related emails: same sender, same URL, same attachment hash, similar subject. It identifies all recipients across the organisation — not just the original alert.

3. Entity analysis. AIR analyses: the sender domain (reputation, registration date, SPF/DKIM/DMARC), the URLs (reputation, redirection chain, final landing page), and the attachments (sandbox detonation results, file hash reputation).

4. Recommendation. AIR recommends remediation: soft delete, hard delete, or block sender. The recommendation includes: which emails, which mailboxes, and the confidence level.

5. Approval or auto-execution. Depending on configuration: recommendations require admin approval (default — recommended), or recommendations execute automatically (for organisations with high confidence in AIR accuracy).

Configuring AIR approval settings

Navigate to: Defender → Settings → Email & collaboration → Investigation and response → Automated investigation.

Recommended configuration: Require admin approval for all remediations. This ensures a human reviews the scope before emails are deleted. Auto-execution is available but risks false positive impact — a mis-classified campaign could delete legitimate email from hundreds of mailboxes.

The approval workflow:

1. AIR completes the investigation and creates a recommendation.
2. The Security Administrator reviews: how many emails, which mailboxes, the classification confidence, and the investigation evidence.
3. If the recommendation is correct: approve. AIR executes the remediation.
4. If the recommendation is incorrect or too broad: reject, manually investigate, and remediate with Threat Explorer.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

// Monitor AIR investigations — track volume and outcomes
AlertInfo
| where TimeGenerated > ago(30d)
| where AlertId startswith "air_"
    or Title has "Automated investigation"
| extend InvestigationStatus = tostring(parse_json(tostring(AdditionalData)).Status)
| summarize
    TotalInvestigations = count(),
    Completed = countif(InvestigationStatus == "Resolved"),
    Pending = countif(InvestigationStatus == "PendingApproval"),
    Remediated = countif(InvestigationStatus has "Remediated")
    by bin(TimeGenerated, 7d)

AIR + Sentinel integration

AIR investigation results appear in Sentinel when the M365 Defender connector is enabled (Module 8.3). Each AIR investigation creates alerts that flow into Sentinel incidents — allowing you to correlate email threats with sign-in anomalies, endpoint detections, and other signals in a unified investigation.

Operational workflow: AIR detects a phishing campaign → AIR creates alerts → alerts flow to Sentinel → Sentinel correlates with sign-in data → you see both the email threat AND any resulting compromises in a single incident. This cross-product correlation is why the Defender connector is essential (Module 8.3) — without it, email investigations and identity investigations are disconnected.

AIR limitations

AIR does not contain compromised accounts. If a user clicked the phishing link and entered credentials, AIR removes the email but does not revoke tokens, reset passwords, or check for inbox rules. Account containment is a separate workflow (Module 12.7).

AIR scope may be incomplete. AIR identifies related emails based on sender, URL, and content similarity. If the attacker sent Wave 2 from a different domain with a different URL (as in Module 12), AIR may not link the two waves. The analyst must manually expand the scope.

AIR requires P2. Organisations with P1 only have no automated investigation capability for email. All investigation is manual via the Real-time Detections view (limited Threat Explorer) and KQL.

AIR investigation tuning

AIR investigations can generate noise — low-severity investigations for emails that were already blocked. Tune:

Reduce alert fatigue: Configure AIR to not trigger investigations for emails that were already blocked at delivery. These emails never reached inboxes — the investigation adds no value. Focus AIR on emails that were delivered and later reclassified (the ZAP scenario).

Approval SLA: Set an internal SLA for AIR approval: 4 hours during business hours, next business day outside hours. Pending approvals represent unresolved risk — the remediation recommendation exists but has not been executed. Track pending approvals:

1
2
3
4
5
6
7
8
9

// AIR pending approvals — how long are recommendations waiting?
AlertInfo
| where TimeGenerated > ago(7d)
| where Title has "investigation"
| extend Status = tostring(parse_json(tostring(AdditionalData)).Status)
| where Status == "PendingApproval"
| extend PendingHours = datetime_diff('hour', now(), TimeGenerated)
| project TimeGenerated, Title, PendingHours
| order by PendingHours desc

Any investigation pending for more than 4 hours during business hours: review and approve or reject immediately.

Building the complete email protection dashboard

Combine the monitoring queries from subsections 9.2-9.9 into a single Sentinel workbook:

Tile 1: Anti-phishing detections by day (subsection 9.2 query). Shows: phishing volume trend and delivery rate.

Tile 2: Safe Links clicks by day (subsection 9.3 query). Shows: click volume and block rate.

Tile 3: Safe Attachments malware detections (subsection 9.4 query). Shows: malware volume trend.

Tile 4: ZAP actions by day (subsection 9.5 query). Shows: post-delivery remediation volume and gap timing.

Tile 5: DMARC failures for your domain (subsection 9.6 query). Shows: spoofing attempts or misconfigured senders.

Tile 6: Transport rule hits (subsection 9.7 query). Shows: which rules are firing.

Tile 7: AIR investigation status (this subsection query). Shows: pending approvals and investigation volume.

Tile 8: User-reported phishing (subsection 9.8 query). Shows: human sensor network activity.

Deploy this workbook as your monthly email protection health report. The 8 tiles together show: what threats are hitting your email, what is being caught, what is getting through, and how quickly you are responding. Present monthly to management: “This month: [X] phishing emails blocked, [Y] delivered (our delivery rate is [Z]%), ZAP removed [W] post-delivery, AIR investigated [V] campaigns, users reported [U] suspicious emails.”

AIR in the broader automation strategy

AIR for email is one component of the broader automation capability in M365 security. The full automation stack:

AIR for email (this subsection): Investigates and remediates email threats. Trigger: phishing or malware detection. Action: scope the campaign, recommend remediation.

AIR for identity (Module 10.6): Investigates compromised accounts triggered by sign-in anomalies. Action: recommend account containment.

Sentinel automation rules (Module 10.6): Execute playbooks in response to Sentinel incidents. Action: enrich alerts, notify analysts, execute containment.

Sentinel playbooks (Module 10.7): Logic Apps that execute automated response actions. Action: revoke tokens, disable accounts, block IPs, send notifications.

The integration point: AIR detects and remediates the email threat. If a user clicked and was compromised: the sign-in anomaly triggers an identity investigation (or a Sentinel analytics rule). The Sentinel playbook executes containment (token revocation, password reset). The full chain — from phishing email to account containment — can be automated end-to-end.

Current reality for most organisations: Full end-to-end automation requires careful tuning and testing. Start with: AIR for email in approval mode (subsection 9.9), manual containment for compromised accounts (Module 12.7), and Sentinel automation for alerting and enrichment (not containment). As confidence grows: expand automation to include containment actions — but always with appropriate guardrails (approval workflows, scope limits, rollback capability).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

// Cross-product investigation: from AIR email detection to sign-in compromise
// Step 1: AIR detected a phishing campaign
let PhishRecipients = EmailEvents
| where TimeGenerated > ago(7d)
| where ThreatTypes has "Phish"
| where DeliveryAction == "Delivered"
| distinct RecipientEmailAddress;
// Step 2: Did any recipients click?
let Clickers = UrlClickEvents
| where TimeGenerated > ago(7d)
| where ActionType == "ClickAllowed"
| where AccountUpn in (PhishRecipients)
| distinct AccountUpn;
// Step 3: Did any clickers get compromised (new IP sign-in)?
SigninLogs
| where TimeGenerated > ago(7d)
| where UserPrincipalName in (Clickers)
| where ResultType == "0"
| where IPAddress !in (_GetWatchlist('CorporateExternalIPs') | project SearchKey)
| project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName

This three-step query bridges the gap between AIR (email) and identity investigation (sign-in logs). AIR handles Step 1 automatically. Steps 2-3 are the manual investigation that determines whether the phishing succeeded — and which currently requires analyst action. Future automation can connect these steps via Sentinel playbooks.