Investigate Incidents with Advanced Hunting

From alerts to incidents — the correlation engine

Incidents vs alerts

Incidents vs Alerts in Defender XDR

Feature	Incidents	Alerts
Definition	A correlated group of related alerts representing a single attack	An individual detection from a single Defender product
Scope	Cross-workload — spans email, identity, endpoint, cloud apps	Single workload — generated by one Defender product
Primary view	Attack story with visual graph	Alert detail page with specific evidence
Management	Assign, classify (True/False positive), set determination, resolve	Link to incident, suppress, or tune the detection rule
Contains	Multiple alerts, affected assets, evidence, investigation graph	Specific detection details, severity, category, MITRE technique

Incident management lifecycle

When Elena triages incidents at MedGuard Health, she follows a structured workflow:

1. Triage — prioritise by severity and scope

The incident queue shows all open incidents sorted by severity (High, Medium, Low, Informational). Elena filters for High severity first and checks the affected assets count — an incident touching 50 mailboxes gets attention before one affecting a single device.

2. Investigate — understand the full attack story

The Attack story tab visualises the incident as a graph:

• Root cause node — where the attack started (e.g., a phishing email)
• Progression nodes — how the attack moved (e.g., credential harvest, lateral movement)
• Impact nodes — what the attacker accessed or damaged

Elena clicks through each alert in the incident to review the evidence: email headers, process trees, sign-in logs, file hashes.

3. Classify and determine

Classification	When to Use
True positive	The incident represents a real threat that requires remediation
Informational, expected activity	The activity is legitimate but triggered an alert (e.g., a red team exercise)
False positive	The detection was incorrect — tune the rule to prevent recurrence

After classifying as true positive, Elena sets a determination — multi-stage attack, compromised account, malware, phishing, or unwanted software.

4. Respond — contain and remediate

Response actions available directly from the incident:

• Isolate a device — cut network access while keeping the Defender for Endpoint management channel alive
• Disable a user account — prevent further sign-ins while investigating
• Soft-delete emails — remove malicious messages from all recipient mailboxes
• Block a file or URL — add to the tenant block list
• Run automated investigation — trigger Defender’s AIR to expand the investigation

5. Resolve — close with documentation

Mark the incident as Resolved with the classification and determination set. This feeds into reporting and helps tune future detections.

💡 Exam tip: Who can manage incidents?

Incident management requires the Security Operator or Security Administrator role in Defender XDR. Security Readers can view incidents but cannot assign, classify, or take response actions. The exam may test this in a “least privilege” scenario — if Elena only needs to view incidents, Security Reader is sufficient. If she needs to triage and respond, she needs Security Operator at minimum.

Alert correlation across Defender products

Understanding which products generate which alerts is critical for the exam:

Defender Product	What It Detects	Example Alert
Defender for Office 365	Email-borne threats — phishing, malware, BEC	”Email messages containing phishing URL removed after delivery”
Defender for Endpoint	Endpoint threats — malware execution, suspicious processes, exploitation	”Suspicious PowerShell command line”
Defender for Identity	Identity threats — lateral movement, privilege escalation, reconnaissance	”Suspected brute-force attack (Kerberos, NTLM)“
Defender for Cloud Apps	Cloud app risks — impossible travel, mass download, OAuth abuse	”Activity from infrequent country”
Entra Identity Protection	Sign-in and user risk — leaked credentials, anonymous IPs	”User risk level changed to High”

When these alerts share common entities (same user clicked a phishing link, then ran malware on their endpoint, then authenticated to SharePoint from a new location), Defender XDR correlates them into a single incident.

Advanced hunting with KQL

Advanced hunting is the proactive investigation tool — it lets you query raw telemetry using Kusto Query Language (KQL) across all Defender workloads.

Key tables for MS-102

Table	Data Source	Use Case
EmailEvents	Defender for Office 365	Search email deliveries, sender analysis, subject line patterns
EmailAttachmentInfo	Defender for Office 365	Find emails with specific attachment types or hashes
EmailUrlInfo	Defender for Office 365	Track URL clicks and phishing link analysis
IdentityLogonEvents	Defender for Identity	Investigate sign-in patterns, failed logon attempts
DeviceProcessEvents	Defender for Endpoint	Hunt for suspicious process execution
CloudAppEvents	Defender for Cloud Apps	Audit cloud app activity, file downloads, sharing
AlertEvidence	All Defender products	Query evidence collected across all alerts

Essential KQL patterns

Elena uses these query patterns daily at MedGuard:

Find phishing emails delivered in the last 24 hours:

EmailEvents
| where Timestamp > ago(1d)
| where ThreatTypes has "Phish"
| where DeliveryAction == "Delivered"
| project Timestamp, SenderFromAddress, RecipientEmailAddress, Subject, ThreatTypes
| order by Timestamp desc

Identify users who clicked a specific malicious URL:

EmailUrlInfo
| where Url contains "malicious-domain.com"
| join kind=inner EmailEvents on NetworkMessageId
| project Timestamp, RecipientEmailAddress, Url, Subject

Hunt for suspicious PowerShell on endpoints (post-phishing compromise):

DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName == "powershell.exe"
| where ProcessCommandLine has_any ("Invoke-WebRequest", "DownloadString", "EncodedCommand")
| project Timestamp, DeviceName, AccountName, ProcessCommandLine
| order by Timestamp desc

ℹ️ Deep dive: KQL operators you need to know

The exam won’t ask you to write complex KQL from scratch, but you need to recognise what queries do:

• where — filters rows based on a condition
• project — selects specific columns (like SQL SELECT)
• order by — sorts results
• summarize — aggregates data (count, sum, avg)
• join — combines two tables on a common column
• has — case-insensitive substring match (faster than contains for single words)
• has_any — matches any value in a list
• ago() — time function for relative time ranges (ago(1d), ago(7d), ago(1h))
• extend — adds a calculated column to the result set

Read queries from top to bottom — each pipe operator transforms the result of the previous line.

Custom detection rules

You can save a hunting query as a custom detection rule that runs on a configurable schedule (from every 5 minutes to every 14 days). When the query returns results, Defender XDR automatically creates alerts — turning a one-time hunt into continuous monitoring.

Elena creates a custom detection for “any MedGuard user who clicks a URL in an email from an external sender and then runs PowerShell within 10 minutes” — a pattern that matches phishing-to-compromise chains specific to healthcare targeting.

💡 Exam tip: Hunting permissions and quotas

Advanced hunting requires the Security Operator or Security Administrator role. Queries have a 30-day lookback limit for most tables and a 100,000-row result limit per query. The exam may ask about these constraints in capacity-planning scenarios.

Scenario: Elena investigates a phishing incident

A nurse at MedGuard Health reports a suspicious email. Elena traces the attack through the incident:

1. Alert 1 (Defender for Office 365) — “Phishing email delivered” — an email with a credential-harvesting link was delivered to 12 staff members
2. Alert 2 (Defender for Endpoint) — “Suspicious browser activity” — 3 users clicked the link, and the browser launched a fake login page
3. Alert 3 (Entra Identity Protection) — “Anomalous token” — one user’s session token shows unusual properties, suggesting token theft
4. Alert 4 (Defender for Cloud Apps) — “Mass file download” — the compromised account downloaded 200 patient files from SharePoint

Defender XDR correlates all four alerts into Incident #4821. The attack story shows the full chain: phishing > credential harvest > token theft > data exfiltration.

Elena’s response:

• Soft-delete the phishing email from all 12 mailboxes
• Revoke sessions for the compromised user account
• Force password change and MFA re-registration
• Isolate the device that showed suspicious browser activity
• Run advanced hunting to check if any other users clicked similar links in the past 7 days
• Report the incident to MedGuard’s compliance team (HIPAA breach notification may be required)

Key concepts to remember

Question

What is the difference between an incident and an alert in Defender XDR?

Click or press Enter to reveal answer

Answer

An alert is a single detection from one Defender product (e.g., 'phishing email detected' from Defender for Office 365). An incident is an automatically correlated group of related alerts that together represent a single attack. One incident can contain alerts from multiple Defender products, linked by shared entities (users, devices, IPs) and temporal proximity.

Click to flip back

Question

What are the three incident classifications in Defender XDR?

Click or press Enter to reveal answer

Answer

1) True positive — a real security threat requiring remediation. 2) Informational, expected activity — legitimate activity that triggered an alert (e.g., pen test). 3) False positive — incorrect detection that should be tuned. After classifying a true positive, you also set a determination (multi-stage attack, compromised account, malware, phishing, etc.).

Click to flip back

Question

Name three response actions you can take directly from an incident in Defender XDR.

Click or press Enter to reveal answer

Answer

1) Isolate a device — cuts network access while maintaining the Defender for Endpoint management channel. 2) Disable a user account — prevents further sign-ins. 3) Soft-delete emails — removes malicious messages from all recipient mailboxes. Other actions include blocking files/URLs, running automated investigation, and revoking user sessions.

Click to flip back

Question

What does the ago() function do in a KQL hunting query?

Click or press Enter to reveal answer

Answer

ago() creates a relative time reference. ago(1d) means 1 day ago, ago(7d) means 7 days ago, ago(1h) means 1 hour ago. It is used in where clauses to filter telemetry to a specific lookback window — for example: where Timestamp > ago(24h) returns events from the last 24 hours.

Click to flip back

Question

What is the maximum lookback period for advanced hunting queries in Defender XDR?

Click or press Enter to reveal answer

Answer

30 days for most tables. Results are limited to 100,000 rows per query. Custom detection rules can run on a configurable schedule (from every 5 minutes to every 14 days) to provide continuous monitoring within this window.

Click to flip back

Knowledge check

Knowledge Check

Elena sees an incident in Defender XDR containing alerts from Defender for Office 365 (phishing email), Defender for Endpoint (suspicious process), and Entra Identity Protection (risky sign-in). All three alerts reference the same user. Elena determines this is a legitimate red team exercise conducted by MedGuard's security consultant. How should she classify this incident?

ATrue positive — because the alerts are technically accurate detectionsBFalse positive — because the activity was authorisedCInformational, expected activity — because the activity is legitimate but correctly detectedDShe should delete the incident to avoid skewing metrics

Check Answer

Knowledge Check

Priya needs to find all emails delivered to GlobalReach users in the past 48 hours that contained URLs to a specific phishing domain. Which KQL approach is correct?

ASearch the EmailEvents table using 'where Subject contains phishing-domain.com'BQuery EmailUrlInfo filtered by the domain, then join to EmailEvents for delivery detailsCUse the DeviceProcessEvents table to find browser activity to the domainDQuery the IdentityLogonEvents table for sign-ins from the phishing domain's IP

Check Answer

Knowledge Check

Marcus at Oakwood Financial wants to create a custom detection rule that automatically alerts when any user downloads more than 100 files from SharePoint within 30 minutes. Which table should the hunting query target, and what is a key limitation he should know?

AEmailAttachmentInfo — it tracks all file downloads including SharePoint, limited to 7-day lookbackBCloudAppEvents — it tracks cloud app activity including file downloads, limited to 30-day lookback and 100,000-row resultsCDeviceFileEvents — it tracks file operations on managed devices, no limitations on query scopeDAlertEvidence — it already aggregates download patterns, limited to resolved incidents only

Check Answer

🎬 Video coming soon

---

Next up: Defender for Office 365: Threat Policies — where Priya implements Safe Attachments, Safe Links, and anti-phishing policies to protect GlobalReach’s 20,000 users.