Investigate an Endpoint Alert in Microsoft Defender

Microsoft Defender groups related alerts into an incident and provides device context, evidence, and a chronological timeline. Begin with the incident record, then validate the endpoint activity and related entities before deciding whether to escalate or request a response action.

Product features and available response actions depend on the Defender workloads licensed, device onboarding and retention, and your role-based access. Follow your organization’s incident response playbook and approval path.

Figure 1: Use the incident and device timeline to connect the detection to nearby endpoint events.

---

Step 1: Open the Incident and Preserve Its Context

01

Start from the Alert or Incident Record

Case Intake

In the Microsoft Defender portal, open Incidents & alerts → Incidents or locate the alert in the Alerts queue. Record the incident ID, alert ID and title, severity, status, detection source, first activity time, and assigned owner. Note the incident’s time zone and preserve the source link before changing its status.

Incident / alert ID:
Detection source and severity:
First activity and alert creation time:
Affected device and user:
Assigned owner and current status:

❯ View Expected Console Output

Scope: one alert on a managed test workstation.
Status: in progress; no response action taken during evidence review.

---

Step 2: Validate the Alert Evidence

02

Open the Alert Details and Entities

Evidence Validation

Read the detection description and open the supporting evidence. Record the file path, signer and hash when provided; process command line and parent/child process; user; device; network indicator; detection timestamp; and the alert’s investigation state. Distinguish telemetry observed by Defender from an automated assessment or analyst conclusion.

Observed event and source:
Process / parent / command line:
File path / signer / hash:
User and device:
Related IP, domain, or URL:
Automated investigation state and evidence links:

❯ View Expected Console Output

Facts are copied from the alert evidence before a disposition is chosen.

---

Step 3: Review the Device Timeline Around the Event

03

Build a Bounded Endpoint Timeline

Device Review

Open the device from the incident or navigate to Assets → Devices, then select its Timeline tab. Set a narrow range around the alert before widening it. Review preceding logons, process starts, file changes, network events, and subsequent alerts. Open an event’s details or process tree to validate its parent and child relationships.

Alert time: T0
Review first: T0 - 30 minutes through T0 + 30 minutes
Expand: only when related activity or known collection delay warrants it

❯ View Expected Console Output

Timeline window and device name recorded with the key events selected.

---

Step 4: Scope Related Devices, Accounts, and Indicators

04

Check Whether the Activity Is Isolated

Incident Scope

From the incident entities and related alerts, check whether the same file hash, domain, IP, process, user, or alert pattern appears on other devices. Compare with asset role, approved software, maintenance windows, and recent change records. Record the query or portal filters and exact time range so another analyst can repeat the scope check.

Device(s) with matching evidence:
Users and sign-ins in the same time window:
Same hash / domain / IP in related alerts:
Expected software or approved change checked:
Collection gaps and retention limits:

❯ View Expected Console Output

Scope statement separates confirmed matches from items not yet checked.

---

Step 5: Decide Whether to Escalate or Request Containment

05

Use the Approved Response Path

Response Decision

If evidence supports suspicious activity, escalate with the incident summary, evidence, affected assets, confidence, and recommended next step. Device isolation can disrupt user work and business services; request it only when the incident playbook and authorized responder approve it. Confirm business impact, device criticality, network dependencies, and who will restore connectivity before action. Do not run remediation commands or quarantine files just to see what happens.

Evidence supporting action:
Affected device owner / business role:
Approval and authorized operator:
Action requested and expected impact:
Rollback / restore owner and validation:

❯ View Expected Console Output

No isolation is performed without an approved response decision.

---

Step 6: Update the Case and Handoff Clearly

06

Record Findings and Next Actions

Case Handoff

Update the incident with what was observed, what was ruled out, and what remains uncertain. Include source event times, time zone, device timeline range, evidence links, scope result, action approvals, and the person who owns the next step. Change classification and status only under your SOC procedure.

Summary and confidence:
Validated evidence and event references:
Affected assets / users:
Actions taken, approved by, and time:
Open questions and next owner:
Disposition rationale:

❯ View Expected Console Output

The next analyst can continue without repeating the initial evidence review.

References

Investigate incidents in Microsoft Defender · Investigate devices and the device timeline · Investigate alerts in Microsoft Defender XDR · Automated investigation and response